[USRP-users] Underflows problem but limited CPU usage

Michael West michael.west at ettus.com
Wed Dec 10 05:27:33 EST 2014


Yes, 50MB is the default size for N200.

I do not believe you will see any benefit by increasing the
recv_frame_size, but you increasing the num_recv_frames and recv_buff_size
may help.

I really think the problem you are having is that all interrupts are being
handled by a single core.  If that is the case, enabling Receive Side
Scaling will probably make the biggest difference.  Keep in mind that
Receive Side Scaling needs to be enabled in the OS, the NIC needs to
support it, and it needs to be enabled on the NIC.

Regards,
Michael

On Wed, Dec 10, 2014 at 1:10 AM, Damien Serant <damien.serant at gmail.com>
wrote:

> Many thanks for the quick response.
> Which value do you suggest me for the recv_buff_size ? I read that the
> default value was 50Mo, do you confirm ?
> Is there an interest to change also with the recv_frame_size value ?
>
> Thanks
>
> Damien
>
> 2014-12-10 1:20 GMT+01:00 Michael West <michael.west at ettus.com>:
>
>> That sounds like an OS issue to me.  A few things to try:
>>
>> - Enable Receive Side Scaling (if not already enabled)
>> - Increase the size of the receive socket buffer
>> - Disable all power management (may be throttling CPU cores)
>> - Use a single Ethernet connection (reduce the number of network
>> interrupts)
>>
>> Hardware interrupts trump all software, so changing priority will not
>> matter if there are more hardware interrupts to process than can be
>> processed (i.e. from the NIC and mouse).  A good test is to see how much
>> kernel activity there is on each core when shaking the console window and
>> running UHD.  If there is a concentrated kernel load on a single core, that
>> is a good indication that all interrupts are being handled by a single core
>> and that is why packet processing is being delayed.  Enabling Receive Side
>> Scaling will spread the network interrupts among the cores and increasing
>> the socket buffer will give more time to process the interrupts.
>>
>> Regards,
>> Michael E. West
>>
>> On Tue, Dec 9, 2014 at 2:59 PM, Damien Serant via USRP-users <
>> usrp-users at lists.ettus.com> wrote:
>>
>>> Hi list,
>>>
>>> I'm trying to push the USRPN200 to the limit in throughput and I
>>> experienced a quite strange underflow behavior.
>>> Here is my configuration :
>>>
>>>    - 2USRPN200 with Mimo cable, 25MHz and 8 bit on each with 2 Ethernet
>>>    to avoid saturation of the link
>>>    - Intel Xeon processor with 6 core (12 Threads)
>>>    - Windows 7 Pro 64 bit
>>>
>>> My UHD program is only reading samples without any processing (not even
>>> disk writing). If i do nothing else on the PC, the program work without any
>>> packet loss with a very limited CPU charge of about 5% (about 20% on two
>>> cores) according to the task manager and for at least 30 minutes (the
>>> longest test that i made). As soon as i start soliciting a bit the CPU
>>> (e.g. opening another application, or simply by moving the scroll bar of
>>> the console up and down or shaking the console window) underflows and
>>> packet losses arise. I tried to play with the process priority but the
>>> result is the same.
>>>
>>> The underflows are apparently due to an increased CPU charge but with
>>> only 5% of CPU usage for my UHD program i should not expect that, no ?
>>> Does anyone already experienced that ?
>>> Is there some tricks in the OS configuration or in UHD configuration to
>>> avoid that ?
>>>
>>> Thanks in advance,
>>>
>>> Damien
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141210/d924527c/attachment-0002.html>


More information about the USRP-users mailing list