discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Brower
Subject: Re: [Discuss-gnuradio] MAC layer development and USRP2
Date: Tue, 6 Apr 2010 16:35:28 -0500 (CDT)
User-agent: SquirrelMail/1.4.2-1

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]