Re: [Discuss-gnuradio] reducing the latency in tunnel.py
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 I will be uploading the RFID reader code to CGRAN in the next week or so, and will post to this list when that happens. The GNU Radio subsystem and scheduler modifications for reducing latency will be included. More work would need to be done to show that it is the always the right approach for all applications before trying to push it into the trunk. -michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] 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. - George 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. It would still eat up a chunk of your 4 ms slot, but might be low enough overhead for your application. -michael ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
On Thu, Oct 8, 2009 at 1:50 PM, Jane Chen janechen_1...@yahoo.com 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. 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!! 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
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 Nychis gnyc...@cmu.edu 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reducing the latency in tunnel.py
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 Geiger doug.gei...@bioradiation.net wrote: From: Douglas Geiger doug.gei...@bioradiation.net Subject: Re: [Discuss-gnuradio] reducing the latency in tunnel.py To: George Nychis gnyc...@cmu.edu Cc: Jane Chen janechen_1...@yahoo.com, discuss-gnuradio@gnu.org 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 Nychis gnyc...@cmu.edu 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
