Re: [Discuss-gnuradio] MAC layer development and USRP2

[George Nychis]

Jeff, I definitely agree that buffering also adds significant 
latency.  How much of the MAC can you get around?  I just think that, there are a number of people who want the flexibility of the SDR, but want to do MAC research, and current common SDR architecture is just not good enough.  We need lower latency between the hardware and the host.

Microsoft Research recently built up a new SDR which uses PCI-E to address the latency issue:
http://research.microsoft.com/en-us/projects/sora/

Their whitepaper is here:
http://research.microsoft.com/apps/pubs/default.aspx?id=79927

I had a paper in the same conference which used several techniques to split common MAC functionality between the USRP and the host to reduce the latency of time-critical functions (e.g., carrier sense):
http://www.andrew.cmu.edu/user/gnychis/nychis_nsdi09.pdf

I of course believe in my own work, but I also believe that it is not sufficient to cover all MAC implementations and future novel MACs ;)  PS. it also has architectural latency measurements (e.g., host -> kernel, kernel -> USRP, USRP -> kernel, etc.)... and I posted the code for these measurements on CGRAN, for those interested.  This is why you have the problems you have Veljko, the turnaround time is extremely high.  We came up with the approach of "fast-ACKs" which are generated from the USRP itself.  

This all said... I really think we need a better interface to reduce latency.  Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board.  Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P

- George