Re: [Discuss-gnuradio] Latency related results

[Michael Buettner]

> Dear All,

> I would like to share the following results in case someone is interested.
> It is related to USB latency, linux latency and whatever. It is an attempt
> to "emulate" a TDMA system. 

> I have connected a square-wave to one of the pins of the J101 connector of
> two USRPs each equipped with an RFX1800. The two USRPs are polling the pins
> for a change of polarity. When this happens one of them starts to transmit a
> frame (a frame consists of 40 USRP buffers)  from the USRP and the other is
> receiving the data. In fact, the direction is changed in every burst.  The
> length of the useful part of the burst and is 4.4ms and the square-wave has
> a period of 6*2=12ms (i.e. each polarity lasts for 6ms). 

> The figure http://www.ee.kth.se/~perz/usrp/fig1.eps shows a histogram of the
> position of the useful burst in the received frame. The variation is about
> 0.5ms. 

> Does anyone know the cause of the variation ? Or any means of reducing it ?

> BR/
> Per

One source of variation is the USB Request Block size (fusb_block_size), along 
with the sample rate. For example, a 2048 byte block size at 8 Msps holds 64 us 
worth of signal. The edge of your pulse could be the first sample in the block,
or the last. If you are i/o bound and processing blocks as soon as they are ready, 
if it is the first sample it will be delayed 64 us while you wait for the rest of 
the block to fill. By default, GNU Radio is going  to pull in ~16k worth of samples 
so you would expect variation of about 512 us. 

It is worth noting that changing the fusb block sizes won't really fix this problem. 
At least for the single thread case, and assuming I understand it correctly, the 
default buffer size  between blocks is 16k. usrp_source will block until it can satisfy
the request of the downstream block, which generally will be asking for a full buffer worth 
of samples. If you can use very low sample rates, you can support smaller requests/block
sizes and the jitter will be reduced accordingly. 

  michael