Reducing the latency in tunnel.py

GNU Radio
#1

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.
Â
OS: 2.6.29.6-217.2.7.fc11.i586
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!!

Best.
Jane

#2

On Thu, Oct 8, 2009 at 1:50 PM, Jane C. [email protected]
wrote:

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:
http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf

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
#3

George,
You were talking about using m-blocks, along with doing more processing
on
the USRP (matched filter + dependent packet generator) in the FPGA,
correct?
The basic functionality of m-blocks is to be integrated into the main
API
as I understand (in a modified form perhaps?), and they do still exist
in
the current release, but are deprecated - and aren’t terribly useful as
they
don’t work with the rest of the gnuradio API.
Either way, looking at using the in-band signaling code is I think the
correct direction to be looking.

Doug

#4

Hi Douglas,

Thank you for your reply. I try to find examples for in-band signaling.
However, I don’t see examples in the gnuradio-3.2.2. It seems that theÂ
in-band signaling is on going work. I try to use the existing gnuradio
code to achieve what I want. I have tried everything I can do to speed
up the system and have not succeeded.

Thank you,
Jane

— On Thu, 10/8/09, Douglas G. [email protected]
wrote:

From: Douglas G. [email protected]
Subject: Re: [Discuss-gnuradio] reducing the latency in tunnel.py
To: “George N.” [email protected]
Cc: “Jane C.” [email protected], [email protected]
Date: Thursday, October 8, 2009, 8:03 PM

George,
 You were talking about using m-blocks, along with doing more processing
on the USRP (matched filter + dependent packet generator) in the FPGA,
correct?
 The basic functionality of m-blocks is to be integrated into the main
API as I understand (in a modified form perhaps?), and they do still
exist in the current release, but are deprecated - and aren’t terribly
useful as they don’t work with the rest of the gnuradio API.

 Either way, looking at using the in-band signaling code is I think the
correct direction to be looking.

 Doug

On Thu, Oct 8, 2009 at 2:47 PM, George N. [email protected] wrote:

Hi Jane,

I published a paper on this issue:

http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf

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

Discuss-gnuradio mailing list

[email protected]

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio