On 2021-11-03 03:04, Anabel Almodovar wrote:
Thank you for your explanation. So is there any kind of solution for
my problem with GNU Radio?
Thanks in advance.
Regards,
Anabel
I have suggested this in the past--look into using DPDK if you're
running at high sample rates over 10GiGe:
https://files.ettus.com/manual/page_dpdk.html
https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD
El mié, 27 oct 2021 a las 17:48, Marcus D. Leech
(<[email protected]>) escribió:
On 2021-10-27 11:37, Anabel Almodovar wrote:
Hello,
When I run a benchmark_rate example it indicates that there are
no sample losses even with 30s of acquisition.
/*
*/
/*rack_2021@rack-HP-Z4-G4-Workstation:~/workarea-uhd/uhd/host/examples/build$
sudo ./benchmark_rate
--args="addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000"
--channels="0,1" --rx_rate 200e6 --duration 30 --rx_subdev="A:0 B:0"
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
UHD_4.1.0.HEAD-0-gd21735d5
[00:00:00.000677] Creating the usrp device with:
addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000...
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
RX Channel: 1
RX DSP: 1
RX Dboard: B
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: UBX TX
[00:00:02.923799498] Setting device timestamp to 0...
[INFO] [MULTI_USRP] 1) catch time transition at pps edge
[INFO] [MULTI_USRP] 2) set times next pps (synchronously)
[WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping.
[WARNING] [0/Radio#1] Attempting to set tick rate to 0. Skipping.
[00:00:04.262875535] Testing receive rate 200.000000 Msps on 2
channels
[00:00:34.313774651] Benchmark complete.
Benchmark rate summary:
Num received samples: 12000000380
Num dropped samples: 0
Num overruns detected: 0
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
Done!*/
However, when I run rx_samples_to_file I get overflows from 8 sec
for a single receiving channel.
/*sudo ./rx_samples_to_file
--file="/home/rack_2021/Escritorio/pruebas_codigos_agosto/usrp_samples.dat"
--duration 8
--args="addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000"
--channel="0" --subdev="A:0" --rate 200e6 --bw 200e6 --gain 5
--freq 800e6
Creating the usrp device with:
addr=192.168.40.2,second_addr=192.168.30.2,recv_buff_size=900000000...
[INFO] [UHD] linux; GNU C++ version 9.3.0; Boost_107100;
UHD_4.1.0.HEAD-0-gd21735d5
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Maximum frame size: 8000 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
Using Device: Single USRP:
Device: X-Series Device
Mboard 0: X310
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: UBX RX
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: UBX TX
TX Channel: 1
TX DSP: 1
TX Dboard: B
TX Subdev: UBX TX
Setting RX Rate: 200.000000 Msps...
Actual RX Rate: 200.000000 Msps...
Setting RX Freq: 800.000000 MHz...
Setting RX LO Offset: 0.000000 MHz...
Actual RX Freq: 800.000000 MHz...
Setting RX Gain: 5.000000 dB...
Actual RX Gain: 5.000000 dB...
Setting RX Bandwidth: 200.000000 MHz...
Actual RX Bandwidth: 200.000000 MHz...
Waiting for "lo_locked": ++++++++++ locked.
Press Ctrl + C to stop streaming...
O
Done!*/
I am using a native Ubuntu, not a VM and I have the CPU governor
set to "performance".
I have managed to patch the code that worked for me before
updating the system to the new versions of Ubuntu and UHD, so I
ask for more samples than I want since I have observed that the
recv () reception buffer is not always constant and it does not
always acquire the maximum number of samples as I request (1996
samples), at least not at the beginning. But I would like to know
the cause of this so that I can fix it and why GNU Radio keeps
giving me the same error.
Thanks in advance.
Regards,
Anabel
The recv() call doesn't necessarily guarantee that you'll get all
the samples you asked for in that call, as far as I know. It isn't
surprising that there would be slight differences
in behavior across different versions of UHD and OS versions in
this regard. You always have to be prepared to receive fewer
samples than you asked for.
If Gnu Radio applications are producing overruns, that is firmly
in the territory of Gnu Radio, and NOT UHD. Clearly, on your
machine, UHD is able to sustain 200e6 SPS.
But as you add layers of application processing, the system is
more heavily loaded. Gnu Radio actually "does things" with the
samples, which means the
instructions-per-sample is MUCH higher than your simple
rx_samples_to_file test.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
