Ahh sorry dude. That is what used to happen to me before I tried the stuff
I listed. The only other thing I can thing of is maybe playing around with
MTU. I found my best performance at 4000, but I'm not sure that will help.
On Thu, Jul 26, 2018 at 11:30 AM, Андрій Хома <anik12...@gmail.com> wrote:
> Have you changed your cpu governor to performance?
>>
> yes
>
> Have you tuned your network interface profile with ethtool -g?
>>
> When I work with a usrp x310 - yes
>
> I found that maxing out that buffer size helped lots.
>>
> i playing with it
>
>
>> You may also have to manually schedule your threads if using
>> isolcpus/numactl/taskset. I noticed that the linux scheduler did a poor job
>> of distributing threads to different processors.
>>
> I allocated usrps for a completely separate processor (the motherboard
> supports two)
>
> All of the above really helps and works! But when you just run, for
> example, leafpad... "OOO" 😂
> Nobody ever met this?
>
> чт, 26 июл. 2018 г. в 20:17, Keith k <keithko...@gmail.com>:
>
>> Have you changed your cpu governor to performance? Have you tuned your
>> network interface profile with ethtool -g? I found that maxing out that
>> buffer size helped lots. You may also have to manually schedule your
>> threads if using isolcpus/numactl/taskset. I noticed that the linux
>> scheduler did a poor job of distributing threads to different processors.
>>
>> On Thu, Jul 26, 2018 at 10:35 AM, Андрій Хома <anik12...@gmail.com>
>> wrote:
>>
>>> Yes, thank you, I've tried this before: I allocated 10 or more cores
>>> purely for the USRPs. Overflows are generally less, but when starting
>>> any application, one or two "O" are guaranteed to be printed.
>>> Therefore, I suggested that maybe it's a case of cache or something else.
>>>
>>> I was playing with num_recv_frames, but the problem is that I do not
>>> know how to determine the correct value for it. Now it's
>>> num_recv_frames = 150, and recv_frame_size = 8000.
>>>
>>> In general, while running my application, a lot of start / kill
>>> processes, which are causes overflows. If you do not touch anything, do
>>> not run anything - everything is fine, even without the allocation of cores
>>> by isolcpus and numactl :)
>>>
>>> чт, 26 июл. 2018 г. в 19:07, Marcus D. Leech <mle...@ripnet.com>:
>>>
>>>> Make sure that you’re increasing the num_recv_frames in the device args
>>>> as well
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jul 26, 2018, at 11:10 AM, Keith k via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>> How many CPU cores do you have? I've also found this a problem with
>>>> multiusrp and high data rates. The solution for me was to isolate cpu cores
>>>> and then use taskset to run my program on the isolated cores. This
>>>> drastically reduced the number of overflows to almost none. This however
>>>> will probably require you to use an 8 core or higher computer. UHD spawns 2
>>>> threads for every USRP you have, so you can only schedule so many threads
>>>> on an isolated core before they starve each other.
>>>>
>>>> On Thu, Jul 26, 2018 at 1:56 PM, Андрій Хома via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Perhaps a dumb question: what is more critical in order to avoid
>>>>> buffer overflows ("O")? Frequency, cache size, or something else?
>>>>> I dealt with two processors
>>>>> 1: 2.2GHz, 25MB cache
>>>>> 2: 3.5GHz, 15MB cache
>>>>> In both cases, I observed overflows
>>>>>
>>>>> 4х usrp b205mini, through usb3.0
>>>>>
>>>>> Thank you, Andrei.
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -Keith Kotyk
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>
>>
>> --
>> -Keith Kotyk
>>
>
--
-Keith Kotyk
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
