On 07/26/2018 01:30 PM, Андрій Хома 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?
Yes. This is due to the subtleties of scheduling and interrupt handling
in general-purpose operating systems. When you're streaming at
high rates, it doesn't take much in the way of "not paying attention
to that I/O while I do this other thing" to cause you to fill up buffers
very quickly.
How much physical memory do you have?
чт, 26 июл. 2018 г. в 20:17, Keith k <keithko...@gmail.com
<mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
