Philip- > On 04/06/2010 04:19 PM, George Nychis wrote: >> 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/ > > Is Sora active? The forum seems really quiet. Also they say there is a > strict non-commercial use use license. Also, it seems like they are > using the RF front ends from WARP, a look at the Warp site suggests the > radio board is 2K. Also, they estimate the board price at "several K$", > so it is not quite WARP prices, but looks to be closing in on it > rapidly. [1]
I think you're touching on an underlying, basic point: Matt et. al. have spent years developing an RF + server architecture that both works and is inexpensive. Those two things are very difficult to integrate. Many tradeoffs and compromises must be made carefully, with a lot of painstaking trial and error. Matt's followers recognized this some time ago, more recently NI has recognized this. The Sora team may find it difficult -- and likely expensive -- to reliably move very high rate ADC data over some distance, external to the PC. PCIe-over-cable is one way, but again, not cheap. -Jeff > [1] > http://social.microsoft.com/Forums/en-US/sora/thread/2701a49b-2ea1-4df6-a85c-d5d01b4ea77c > > >> >> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio