Hi all, I'm still trying to figure out what the causes these problems.
I tried different B210s on multiple computers now. It works with 2x2 up to 24.4MSps. And breaks with 24.5MSps. However, 2x TX+RX @30.72MSps does not work. Also, 2x RX @30.72MSps and 2x TX @15.36MSps works.I'm sure things use USB3. UHD reports it and the "working rates" are beyond USB2.
I tried 3 different computers with 3 different B210s. I tried UHD3.15-LTS, UHD4.1, and UHD4.2. All seem to show the same behavior. Also, I tried Ubuntu 20.04 as well. I was under the impression that 2x2 @30.72MSps should be possible.
One of those computers has a 10Gig Ethernet card and I'm able to run an N310 with 2x2 61.44MSps and more. Also, `htop` shows benchmark_rate at a maximum CPU load below 60%.
My application runs continuously with 2RX streams at 30.72MSps. However, it only transmits occasionally. I use burst transmissions in GR with length tags. The aggregate rate would be below 15.36MSps. This configuration works on all devices except for the computer with Ubuntu 22.04 and UHD4.2. Moreover, in this case I can see an "O" reported whenever the application transmits. Thus, I assume after a burst is transmitted, smth fails.
Cheers Johannes On 09.09.22 11:55, Johannes Demel wrote:
Hi all,there's smth else going on. I tried the UHD-4.1 and UHD-4.1.0.6 branches and all cause these errors. I will investigate this further.I need to switch USRPs and hosts and see how the errors appear/disappear. Cheers Johannes On 07.09.22 19:29, per...@o2.pl wrote:Johannes Demel wrote: Hi all, thanks for your suggestions. A few more details: * Ryzen 5900X CPU * UHD reports USB 3. With USB2 it would probably fail above ~8MSps. * Ubuntu 22.04 with GCC 11.2, Python3.10 I tried 2TX streams alone at 30.72MSps. works. check. I tried 2RX streams alone at 30.72MSps. works. check. I tried configurations with * num_recv_frames=num_send_frames=256 * num_recv_frames=num_send_frames=512 Doesn't help. The error pattern looks like this: UUUUUUUUO[D00:00:07.60063828] Detected Rx sequence error. I tried * send_frame_size=recv_frame_size=8000 also in conjuntion with the num_xxx_frames configurations. But that didn't help either. I will try to use UHD 4.1 on that machine. If that works, I'll justswitch back. Otherwise, I'd get suspicious of Ubuntu and the hardware.Cheers Johannes On 07.09.22 17:17, McKnight, Ryan wrote: I have found after much trial and error that adding the arguments “recv_frame_size=8000,num_recv_frames=512” to the device string allows for me to sample at the full 56 Msps rate on the B series devices without any overruns (tested using UHD 4.2.0.1 on both Debian 11 and Arch Linux on various computers). I haven’t tried transmitting at all though so not sure if there are better arguments for that. One additional thing to double check for is that your device is actually connecting using USB 3.0, I have found a surprising amount of bad USB3 cables that would only link up at USB2 speeds (check using “sudo lsusb -tv” after running uhd_usrp_probe to load firmware onto the device, should show speed of 5000M). /From:/ per...@o2.pl per...@o2.pl <mailto:per...@o2.pl> /Sent:/ Wednesday, September 7, 2022 10:31 AM /To:/ usrp-users@lists.ettus.com /Subject:/ [External] [USRP-users] Re: B210 reporting U/O on Ubuntu 22.04 /Use caution with links and attachments./ per...@o2.pl mailto:per...@o2.pl <mailto:per...@o2.pl> wrote: |per...@o2.pl <mailto:per...@o2.pl> wrote: Hi, I can only confirm that I see the same result: 24MHz is working, starting from about 24.5MHz there’s a lot of underruns. My CPU: AMD Ryzen Threadripper 2990WX, 128GB RAM, motherboard Asus X399. … and the system is Ubuntu 20.04 with UHD 4.2.0.1.| But with UHD 4.1.0.6 there situation is exactly the same (not working for >= 24.5M), so if you’ve got it somewhere working it would be worth sharing: * your exact UHD revision, * specs of your PC.If you could capture situation where it worked and stopped working on the same machine that would get you much closer to solving the issue.You could write a test and use it for automatic git bisect (git bisect run): https://lwn.net/Articles/317154/If it’s UHD fault this can show you first commit that worsened maximum transfer rate.Best Regards, Piotr Krysik _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
