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

[Jeff Brower]

George-

> 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/

Did you see my previous post about the accelerator PCIe card?  To some extent 
the Microsoft approach is what we're
doing.  But we want to stay compatible with USRP2 hardware so we connect GbE to 
the accelerator card; non MAC-related
dataflow is PCIe from there.  Buffering required to stay compatible with USRP2 
software and high, sustained transfer
rates moves "right", to the accelerator card (which has a lot of memory).

The real trick is software.  Our approach is that MAC-related code still 
appears in GNU radio source, but is marked
with pragmas (first something specific to our project, then OpenCL, then 
OpenMP) so that code actually runs on the
accelerator card (the TI multicore CPUs on the acclerator card run arbitrary 
C/C++ code so they're not limited like an
Nvidia or other GPU).  We plan to use our GNU radio interface to test results 
of a server acceleration project we're
doing for DoE.

That's the long story... right now our short-term objective is the GbE-to-GbE 
USRP2 connection.

BTW, that's a Virtex 5 on the Sora board, that's not going to be cheap.

-Jeff

> 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