discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] UHD transmit issues solved


From: Marc Epard
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.

<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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]