[Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote: 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). 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
On Mon, Oct 18, 2010 at 08:37:33PM -0400, Marcus D. Leech wrote: 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 Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD:SingleUSRP and buffer allocation policy
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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
