I have only succeeded in running a B210 on a Raspberry Pi at lower data rates (closer to 12MS) so your experience is consistent with mine.
On Tue, 3 Nov 2020 at 17:20, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 11/03/2020 10:49 AM, Alvaro Pendas Recondo via USRP-users wrote: > > Hello, > > > > I am using a USRP B200mini with a sampling rate of 40MS that works > > perfectly fine connected to a laptop with USB 3. However, when I > > connect it to a Raspberry Pi 4 (which has two USB 3 ports) and I run > > the example benchmark_rate with the same sampling rate I get the > > output that I copy below. It seems that even if it is also operating > > over USB 3, this connection cannot meet the expected performance > > anymore. If I reduce the sampling rate (down to 12 MS approx) > > everything works fine. Any ideas about what might be causing this > problem? > > > > > > By the way, I already followed all the instructions explained at > > > https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:~:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits > > < > https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#:%7E:text=Thread%20Priority%20Scheduling,-When%20UHD%20spawns&text=To%20address%20this%20issue%2C%20non,%2Fetc%2Fsecurity%2Flimits>. > > > > > > > > > ./benchmark_rate --rx_rate 40e6 --tx_rate 40e6 > > > > [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106700; > > UHD_3.15.0.HEAD-0-gaea0e2de > > [INFO] [B200] Loading firmware image: > > /usr/local/share/uhd/images/usrp_b200_fw.hex... > > [00:00:00.000044] Creating the usrp device with: ... > > [INFO] [B200] Detected Device: B200mini > > [INFO] [B200] Loading FPGA image: > > /usr/local/share/uhd/images/usrp_b200mini_fpga.bin... > > [INFO] [B200] Operating over USB 3. > > [INFO] [B200] Initialize CODEC control... > > [INFO] [B200] Initialize Radio control... > > [INFO] [B200] Performing register loopback test... > > [INFO] [B200] Register loopback test passed > > [INFO] [B200] Setting master clock rate selection to 'automatic'. > > [INFO] [B200] Asking for clock rate 16.000000 MHz... > > [INFO] [B200] Actually got clock rate 16.000000 MHz. > > Using Device: Single USRP: > > Device: B-Series Device > > Mboard 0: B200mini > > RX Channel: 0 > > RX DSP: 0 > > RX Dboard: A > > RX Subdev: FE-RX1 > > TX Channel: 0 > > TX DSP: 0 > > TX Dboard: A > > TX Subdev: FE-TX1 > > > > [00:00:11.448560] Setting device timestamp to 0... > > [INFO] [B200] Asking for clock rate 40.000000 MHz... > > [INFO] [B200] Actually got clock rate 40.000000 MHz. > > [WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1 > > channels) exceeds the maximum capacity of the connection (overflows > > (O) MSps). > > This can cause 22.7428. > > [00:00:11.766752] Testing receive rate 40.000000 Msps on 1 channels > > [WARNING] [MULTI_USRP] The total sum of rates (40.000000 MSps on 1 > > channels) exceeds the maximum capacity of the connection (underruns > > (U) MSps). > > This can cause 22.7428. > > [00:00:11.790580] Testing transmit rate 40.000000 Msps on 1 channels > > [00:00:11.891995] Tx timeouts: 1 > > UUUUUUUUUUUUUUUO[00:00:12.078147] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUUUUO[00:00:12.092404] Timestamp after overrun > > recovery ahead of error timestamp! Unable to calculate number of > > dropped samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUO[00:00:12.108355] Timestamp after overrun recovery ahead > > of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUUUUUUUUU[OU00:00:12.123737] Timestamp after overrun > > recovery ahead of error timestamp! Unable to calculate number of > > dropped samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUUUUOU[00:00:12.132437] Timestamp after overrun > > recovery ahead of error timestamp! Unable to calculate number of > > dropped samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUUUUUUOU[00:00:12.142422] Timestamp after overrun > > recovery ahead of error timestamp! Unable to calculate number of > > dropped samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUO[00:00:12.155257] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUO[00:00:12.168528] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUU[O00:00:12.178400] Timestamp after overrun recovery ahead > > of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUU[00:00:12.193251] Timestamp after overrun recovery ahead of > > error timestamp! Unable to calculate number of dropped samples.(Delta: > > -3170 ticks) > > OUUUUUUUUUUUUUUUUUO[00:00:12.204356] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUO[00:00:12.224770] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUO[00:00:12.235145] Timestamp after overrun recovery > > ahead of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUU[O00:00:12.247517] Timestamp after overrun recovery ahead > > of error timestamp! Unable to calculate number of dropped > > samples.(Delta: -3170 ticks) > > UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU[00:00:12.475571] Receiver error: > > ERROR_CODE_TIMEOUT, continuing... > > [00:00:12.575910] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > [00:00:12.676171] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > [00:00:12.776414] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > [00:00:12.876663] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > [00:00:12.976968] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > [00:00:13.077257] Receiver error: ERROR_CODE_TIMEOUT, continuing... > > terminate called after throwing an instance of 'uhd::io_error' > > what(): EnvironmentError: IOError: usb tx2 transfer status: > > LIBUSB_TRANSFER_NO_DEVICE[ > > 00:00:13.083166] Caught an IO exception. > > EnvironmentError: IOError: usb rx6 transfer status: > > LIBUSB_TRANSFER_NO_DEVICE > > > Well, the main reason is that your typical laptop compute environment, > based on x86 processor technology, is going to be more powerful > than the ARM on a Raspberry Pi4. > > Now, you *may* be able to improve things slightly by adjusting the USB > transport parameters, as described here: > > https://files.ettus.com/manual/page_transport.html#transport_usb > > But once you actually start "doing stuff" on the Raspberry Pi, you'll > find that it can't process as many samples per second as on an x86 > system--whether a laptop or desktop machine. There's a reason that a > Raspberry Pi is $50, and a typical low-end laptop is 10 times that. > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
