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: Veljko Pejovic
Subject: Re: [Discuss-gnuradio] MAC layer development and USRP2
Date: Tue, 6 Apr 2010 13:42:26 -0700

Hi George,

2010/4/6 George Nychis <address@hidden>:
> 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.
>

What I got from your paper is that the matched filter approach for
fast packet detection would not work in an OFDM setting. What about
fast ACK generation? Would it require an IFFT implementation on the
USRP? Would it help much?


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

Is there anything that would prevent GNUradio developers to push the
MAC layer functionality on the USRP?


> - George
>

cheers,


Veljko




reply via email to

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