Re: [Discuss-gnuradio] Running Ubuntu 11.04 AMD64; Getting crazy latency results, about 20ms

[Colby Boyer]

On Wed, Jul 27, 2011 at 4:16 PM, Thomas Tsou <address@hidden> wrote:

On Wed, Jul 27, 2011 at 1:23 PM, Colby Boyer <address@hidden> wrote:
> Hi all,
> I'm running a duplex system on the USRP1; using UHD drivers (about 1 month
> old). For the sample rates, I have 640KHz to the USRP and 1MHz from the
> USRP. The turn around time for a simple amplitude detected signal is approx
> 20ms, which is crazy high. Btw, I'm measuring the latency (approx) by
> observing the nitems_written() method for the block that produces samples
> for the sync.
> I'm running UHD and gnuradio with real time threading enabled and giving the
> gnuradio app a nice of -20. Since this happens before any math occurs, I
> assume the kernel is lagging on this. Could switching to a modified kernel
> with realtime improvement patches help?

The short answer is that using the RT patch series won't perform any
magic and bring across the board reductions in measured latencies. The
longer answer is, of course, more complicated. If you want
straightforward solutions, try removing other peripherals from the USB
bus and disabling all power management (preferably from the kernel).
The latter can be particularly sinister when it comes to tracking down
latency bugs.

Once upon a time, I wrote a kernel module to handle a hard interrupt
off of a parallel port and trigger responses from within kernel space
(out another pin) and userspace (submitting transfers to libusrp). An
external scope was was used for timing measurement. Response times
were on average in the single and 10's of microseconds respectively,
but differed drastically based on many factors. The main ones were CPU
load, power management, and other devices on the USB bus.

When it comes to RT patches, you need to consider that the objective
is typically containing maximum latencies and not necessarily minimal
or average times. In certain cases, average latencies using RT code
may be even be higher than the mainline version.

When I ran the tests, differences between mainline (somewhere around
2.6.31) and RT series kernels were initially limited, but became
apparent when running at near 100% CPU load. In contrived cases, the
maximum latency on the normal kernel could increase without bound,
which would be more limited on the RT kernel.

To sum it up, RT changes to the kernel will have an effect, but it
probably won't be immediately obvious. I would start from more obvious
areas - for example by seeing what power management is up to.

 Thomas

Thanks for the detailed reply Thomas!

I'll give the power management changes (from the kernel and from BIOS) a shot, then will try the ubuntu linux-rt kernel from their ubuntu studio repo. 

Are there any particular power options to change on the Kernel?