I’ve noticed latency issues with one of the applications I’m working on.
Latencies of up to tens of seconds
have been observed, which I tried to combat by specifying
recv_buff_size in the parameter list.
Right now, I’m running with 4096 bytes, which at 400Ksps, gives me a
roughly 1 second latency between
input and output (where output is both an audio sink, and a couple of
different file sinks as well as a
scopesink2, and an FFT sink). But increasing it beyond 4096 bytes
causes the latency to go up very
quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If
you do the math, however, 4096 bytes is
nowhere near 1 second worth of buffer. One second is 1.6Mbytes
(400Ksps x 4bytes per sample).
How is downstream buffer allocation policy affected by settings of
recv_buff_size in UHD::SingleUsrp?
This is probably the same can of worms I was talking about a few weeks
ago, with trying to understand
latency issues, and where they’d “bite” you for various classes of
applications. For purposes of data recording,
my current application can’t really tolerate several seconds of
latency–since events recorded will potentially need
to be cross-correlated with other receivers (although not
phase-synchronous, just event correlation down to one or
two seconds of accuracy).
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote:
causes the latency to go up very
quickly, and if I drop it to 1024 bytes, I start seeing over-runs. If
you do the math, however, 4096 bytes is
nowhere near 1 second worth of buffer. One second is 1.6Mbytes
(400Ksps x 4bytes per sample).
Since you’ve got a usrp* source and an audio_sink, what you’re seeing
could be related to the two different clocks in the flow graph. Do
you see the problem if the audio_sink is NOT in the graph?
Eric
Hard to get objective numbers, but it seems like there’s no difference
whether I have the audio sub-graph enabled or
disabled.
The absolute minimum latency I can observe is about 1 second or so, with
an input recv_buff_size=2500.
I know that there’s buffering in the USRP2, but not that much–32K?
Less? More? Even so, at my sample rate, 32K is
only about 20ms of latency.
I’m happy that I’ve gotten it down to ~1sec. At that latency,
cross-site event correlation will be possible. At 10s of seconds, it
would be more of a challenge.
But this really does reinforce my notion that some kind of “latency
policy” machinery needs to be implemented, and I’m quite happy to
toss ideas around. I totally understand the need for big buffers to
amortize scheduling/function-call/whatever costs, but I’m thinking
that things need to be tunable in a way that is exposed to the
(perhaps more sophisticated) applications developer.
Interestingly enough, I did some tests on my app to see how filter
parameters affected latency. They didn’t appear to noticably affect it,
at least in “subjective” tests. My pre-detector filter can have a
user-tunable bandwidth anywhere from 5KHz to 250KHz, with an input
sample rate of 400Ksps. That results in a fairly-large range of
filter lengths, which I assume would get factored into buffer
calculations,
but clearly, there’s enough quantizing in buffer calculations going on
that it doesn’t matter a hoot. Filter lengths vary from 38 taps to
1850 taps, depending on pre-detector bandwidth.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
only about 20ms of latency.
The host cannot back-pressure the USRP2, and the buffering in the USRP2
itself if negligible. So, all of the backing-up that is going to happen
occurs in the host when you dont read data out fast enough.
The UHD-USRP2 receive path has two buffers that fill when calls to
recv() dont keep up. One is the socket buffer in the kernel, and the
other is a UHD allocated buffer that hangs onto frames from the
socket->receive() call. Both of those drop when filled, so any further
buffering/latency you are seeing is happening in gnuradio.
You can manipulate the socket buffer size and the number of frames:
http://www.ettus.com/uhd_docs/manual/html/transport.html#transport-parameters
-Josh