Re: Re: reducing the latency in tunnel.py

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.

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.

It gives another overview of where latency comes from, and shows how you
can
get around some of it.
We were able to get turnaround times for our application below 300 us by
making a few simple modifications to the GNU Radio C++ code.
It would still eat up a chunk of your 4 ms slot, but might be low enough
overhead for your application.

-michael

Another study you could look at is
ftp://ftp.cs.washington.edu/tr/2009/10/UW-CSE-09-10-02.PDF

It gives another overview of where latency comes from, and shows how you can
get around some of it.
We were able to get turnaround times for our application below 300 us by
making a few simple modifications to the GNU Radio C++ code.

Nice work! Have these modifications been accepted upstream? It would
be great if your RFID reader was a standard part of GNU Radio – I
suspect that a lot more experimenters would start messing with RFID.
And it would be even better if every interactive GNU Radio application
could benefit from the latency improvements you made.

John