On 08/29/2020 03:35 AM, Nando Pellegrini wrote:
Marcus,
Attached you can find the results of the benchmark test.
I have been also compared the behavior with 2 different CPU and
different USB type 3.0 for the older tower PC, USB 3.1 on the laptop,
very strange the case of the older CPU generating an overflow every
minute.
The conditions were exactly the same in all test with no other visible
activity on the machines.
Release 14.0 seems a bit better with the benchmark but,sadly, the 2
UHD release are not comparable because the 14.0 as soon as generates
an overflow indication drops in the timeout with no recovery but final
consideration is that fast sample rate became unusable for long signal
recording regardless to software release and PC.
I really hope for a solution.
nando
I played a bit with a B210 on a Fedora 31 system today, and was unable
to achieve greater than 37MSPS without overruns.
I constructed a "degenerate-case" Gnu Radio flow graph that was just:
uhd-source-->null-sink
That's roughly equivalent to what benchmark_rate does, and I was forced
to do that since F31 doesn't appear to package tools
like benchmark_rate and some of the other UHD examples.
This was with UHD 3.14.0.1
The system was an AMD Phenom II X6 1090T.
What i noticed was that above 38Msps, you'd get continuous over-runs,
and at 38Msps, you'd get a burst of overruns whenever you switched to
a new window. This is CLEARLY a system effect, unrelated to UHD at
all. Likely contention for memory access, interrupt latency, or PCI-e
transaction contention. The CPU consumption for the gr-uhd thread
that was servicing the USB interface never rose above 38% CPU.
Now the UHD transport code is single-threaded. It's tempting to
suggest "why not make it multi-threaded?". That was tried, several times,
a few years back, and performance was *worse* with UHD transport
spread over multiple threads. Probably due to resource contention
at the kernel interface.
I'll note that no matter whether I specified sc8, sc12, or sc16 sample
sizes I saw the same behavior. This indicates to me that it isn't
USB *bandwidth* so much as USB (and by implication PCIe) offered
*TRANSACTION* load. It is likely the case that different USB3 controllers
make this better/worse, depending on their interrupt behavior, how
they do DMA, etc, etc. I did have to use num_recv_frames > 200 to
achieve even this.
I'll make a general comment that achieving loss-free, "real time",
high-bandwidth streaming using a general-purpose operating system is
always going to require a lot of tuning, and not a small amount of
good luck. Other applications of high-speed streaming are somewhat
tolerant if one end does a "hey stop sending for a bit" -- like disk
drives and network interfaces, etc. But when you're trying to sample
the "real world", you cannot reasonably put it "on hold" while you
"catch up". Which is why throwing more buffering at this problem generally
doesn't work that well. If the offered load exceeds long-term
capacity, even by a tiny bit, you will end up "losing". It is clear
that "capacity"
is only loosely-coupled to CPU performance, and much-better
represented by overall *system* performance.
Over the years, folks have pointed at UHD, hoping that some kind of
performance-tuning exercise within UHD will get them the performance
their application requires. UHD has been, over the years (roughly 10
years at this point) optimized quite a bit. But UHD lives within an overall
*system* and it can only do as well as that *system* can provide.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
