Recently, I’ve started two threads involving problems using UHD.
http://www.ruby-forum.com/topic/217106
http://www.ruby-forum.com/topic/216320
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.
-Marc