[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] reducing the latency in tunnel.py

From: George Nychis
Subject: Re: [Discuss-gnuradio] reducing the latency in tunnel.py
Date: Thu, 8 Oct 2009 14:47:04 -0400

On Thu, Oct 8, 2009 at 1:50 PM, Jane Chen <address@hidden> wrote:
Hi all,

I would like to send a MAC layer control packet every 4 ms from computer A to computer B to tell B when to send data using USRP and GNU Radio.  It is like TDMA and a frame is 4 ms. I am trying to do this work by modifying tunnel.py in the gnuradio-example folder. I removed the carry sensing part and added the control packet in the tunnel.py.

I enabled the real-time scheduling. I set nice= -18, fusb_block_size = 512, fusb_nblocks  = 2, modulation=gmsk, and bitrate =1Mb/sec.
CPU: 2.8 GHz
Gnuradio: (latest development code 3.2.X)

I used two computers and ran the modified tunnel.py on each computer. For the test, in the main_loop (main loop for MAC) of tunnel.py I generated one byte payload ( I sent the one byte payload chr(0x00) for 10 times)  to print the tx time on one computer and rx time on anther computer. I used software to make two computers have the same system time. The tx time (at computer A) – rx time (at computer B) of the payload is about 5ms. I am wondering why it takes so long to send one byte payload and to decode the one byte payload.  Through the test, I think I cannot implement a TDMA that a frame is 4 ms. I have tried what I can do to reduce the (tx time – rx time) value. However, no luck. Could anyone please give me some hints? Should I just give up this way and try to use the in-band singalling? Any suggestions will be greatly appreciated!!

Hi Jane,

I published a paper on this issue:

If you read it, you will understand all of the latencies involved and why your turnaround time is so high.  We propose mechanisms to overcome these challenges in the GNU Radio / USRP architecture, and built code to support it, but it was decided that the new blocks that our code uses are no longer going to be supported by GNU Radio.  So, our code in summary does not work with GNU Radio now.  But, maybe you can apply some of the techniques we mention to achieve what you want.

- George

reply via email to

[Prev in Thread] Current Thread [Next in Thread]