Forum: GNU Radio Re: Latency related results

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Michael Buettner (Guest)
on 2009-05-04 21:42
(Received via mailing list)
> 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 
<> 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),
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
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.

This topic is locked and can not be replied to.