On 07/27/2018 12:02 AM, RizThon wrote:
I've tried with 3.12.0.0, on both Windows and Linux.
On Ubuntu 18.04, I can set num_recv_frames to what seems like any
number without getting error. I tried 128, 256, even 512 and 1024.
I do get better results than on Windows, but I'm still getting lots of
overflows.
I did try 3.13.0.0 on Windows just when it was out, but I got worst
result (2850 overruns at 28MS/s in SC16 instead of just a few). So for
now I reverted back to 3.12.
So you confirm SC12 is supposed to work on a B210 (and I guess also on
any B2x0)? That may allow me to reach 56MS/s
If that's the case, what can be the problem?
The SC12 support apparently broke at some point. I know that Michael
West (Ettus R&D team) has been working to get it working again,
but won't be ready for a little bit.
I use SC12 myself in my lab, but I don't recall which UHD version I'm
using in the lab, and won't be there until tomorrow evening. If possible
try to revert to 3.10.
Thing is, there's no way anyone can guarantee any particular sample rate
is possible on your system, because of significant differences from
system to system, and significant differences from workload to
workload. Anything that involves recording samples to disk at high input
rates is very tricky to make work, for example. Anything that
involves a lot of processing of the samples is going to have a higher
compute
load, and be more likely to cause overruns.
Thanks a lot.
On Fri, Jul 27, 2018 at 12:14 AM Marcus D. Leech <mle...@ripnet.com
<mailto:mle...@ripnet.com>> wrote:
What version of UHD? I’ve used SC12 myself without issue.
Sent from my iPhone
On Jul 26, 2018, at 1:28 AM, RizThon <rizt...@gmail.com
<mailto:rizt...@gmail.com>> wrote:
SC12 actually gives me an error as soon as it starts streaming
(with or without specifying num_recv_frames=44). Using the
--continue option, I get tons of such errors:
[ERROR] [STREAMER] The receive packet handler caught a value
exception.
ValueError: bad vrt header or packet fragment
Error: Receiver error: ERROR_CODE_BAD_PACKET
Is this specific to my issues with USB, meaning on Linux it works
well, or is the B210 (and B2x0 generally) not handling sc12?
(https://files.ettus.com/manual/structuhd_1_1stream__args__t.htmlmentions/Only
some devices/for SC12).
Thanks again.
On Thu, Jul 26, 2018 at 10:25 AM Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 07/25/2018 10:18 PM, RizThon wrote:
I already tried smaller values, but not small enough. It
seems the highest I can go is num_recv_frames=44. Anything
higher gives me errors.
At 40MS/s, without that parameter, I get 160 to 180
overflows over 20 seconds, while with num_recv_frames=44 I
only get 20 to 30.
This actually allows me to stream at 55MS/s in *sc8* for 20s
without any overflow! With sc16 though, I don't seem much
difference and still get more than 5000 overflows.
Is it possible to use sc12 with the B2x0? The ADC having a
12 bits resolution, we wouldn't lose any data.
Concerning num_recv_frames, is this a problem with the
Windows USB driver, meaning I wouldn't get better results on
another Windows computer? I tried other drivers, using
Zadig. Only the "WinUSB" driver works, but it doesn't work
better than the original Ettus driver.
Do you advise people to use Linux rather than Windows for
USB performance reasons? Should using 256 or 128 fix my
streaming problems?
Thanks.
On Thu, Jul 26, 2018 at 2:00 AM Marcus D. Leech
<mle...@ripnet.com <mailto:mle...@ripnet.com>> wrote:
On 07/25/2018 01:08 PM, RizThon wrote:
Use a 5-6V supply capable of 2 or 3 amps.
Thanks, it's actually working fine, the led properly
turned green after the firmware and gateware were uploaded.
Trying .\benchmark_rate.exe --rx_rate 40e6 I get
Benchmark rate summary:
Num received samples: 201778444
Num dropped samples: 2800
Num overruns detected: 2800
Num transmitted samples: 0
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 0
Num late commands: 0
Num timeouts (Tx): 0
Num timeouts (Rx): 0
It seems I still can't stream faster than around
28MS/s. I still get similar results with
.\rx_samples_to_file.exe (using --null to not store to
file).
Should I try to run some tests from
http://files.ettus.com/manual/page_rdtesting.html ?
Concerning the error "[ERROR] [USB]
libusb_session_impl::libusb_event_handler_task:
LIBUSB_ERROR_CODE -1" that I get when specifying
num_recv_frames, what could I do? Should I try a
different driver? Has anyone already experienced that
error?
Thanks.
Try with a smaller number? The Windows LIBUSB behaves
differently than the Linux version. On Linux, I can
usually ask for 256 without
any issue. Try 64.
The SC12 format should work just fine.
The particular values available for num_recv_frames seem to
be libusb implementation specific, and to a certain extent
controller specific as well.
Windows is known to have somewhat poorer performance (at
least with LibUSB type schemes) that Linux, TBH.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
