|Subject:||[Discuss-gnuradio] UHD transmit issues solved|
|Date:||Tue, 21 Sep 2010 11:30:44 -0500|
Recently, I've started two threads involving problems using UHD.
It turns out they were both on the transmit side and I stumbled onto a solution for both: way smaller send_buff_size. Like 50,000 bytes instead of 500,000,000 bytes.
The behavior with large buffers is strange. I altered my flowgraph to write one second's worth of data to a file instead of displaying on a scope sink and looked at it MATLAB. It turns out the transmit dropouts didn't happen at all until after about 20ms and then they were frequent. Suspecting something buffer-related, I started experimenting to see if the length of the period w/o dropouts was related to the buffer size. Strangely, the glitch-free time didn't seem to be affected much by cutting the size in 1/2 or 1/10, but if the buffer is small enough, the problem goes away entirely.
Also, when the buffer is large, my simple flowgraph pegs one of the CPUs, but when small, all the CPUs fluctuate nicely below 50%. I suspect some sort of scheduling priority issue combined with contention for a lock.
It turns out that I'm not the first to suspect this. I went looking for the default send buffer size and found this in udp_zero_copy_asio.cpp:
//Large buffers cause more underflow at high rates.
//Perhaps this is due to the kernel scheduling,
//but may change with host-based flow control.
static const size_t MIN_SEND_SOCK_BUFF_SIZE = size_t(10e3);
I think the advice Josh gave for the receive buffer in another thread is good: Stick with the default buffer sizes.
|[Prev in Thread]||Current Thread||[Next in Thread]|