[USRP-users] Latency Issues

Josh Blum josh at ettus.com
Wed Oct 17 22:21:53 EDT 2012


> 
> At the moment I preload an output buffer and have a DMA 'start' command
> waiting on a thread, roughly 300 us after receiving the packet baseband the
> packet is demodulated, identified and the start command is issued -
> measuring the timing this equates to between 400 us and 600 us between the
> clear packet ending and my packet starting. This gives me 900 us is tx time,
> leaving at least 500 us padding.
> 
>


I think the requirements given are quite reasonable to achieve. GigE
latency is about 100us, so that should leave the rest for the host.

> 
> How does this transpose into the USRP2 world using gigabit Ethernet? I have
> played with the example code a bit, I rigged up a thread to handle the data
> input then did a simple power on channel calculation to change the TX buffer
> from a 'empty' buffer to a meaningful one - but am finding reaction times
> approaching 250 ms.
> 

So an outside observer of your system would see a 250 ms delay between
the USRP receiving the signal and transmitting a reply? 250 ms is
extremely massive.

>  
> 
> As a guess there is some FIFO buffering getting in the way. I will dig
> through more documentation tomorrow but wanted to see if there is anyone
> with some useful pointers. 
> 
>  

Perhaps you are just measuring the time it takes the transmit buffering
to drain. What sample rate are you using? The buffering on USRP2 TX can
hold about 250k samples.

Are you always transmitting? What you probably want to do is make a
decision about what time the reply TX samples should be sent based on
the time of the RX samples.

Is this a bursty type of application, or do you need to be transmitting
some signal within the void between bursts of useful information (in
other words, do you have to always transmit)?

> 
> Can I (for the sake of an actual question being asked) preload a TX buffer
> for 'quick' playback?
> 

You can schedule when a transmission occurs. But there is ultimately
only one FIFO in the stock FPGA image. Be careful how full that FIFO
becomes.

> Would moving to Linux help (yes - but performance wise)?
> 
>  

Yes, to some degree the linux network stack is "lighter weight". But I
think for your purposes, the issue at hand may be related to buffering.
Windows or linux, it should be just fine.

-josh



More information about the USRP-users mailing list