usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsRe: RFNoC: strange behavior of FFT block
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7 (installed from source). With the newer version the FFT block now correctly displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the size higher than 256 (Error “samples per package must not be smaller than atomic item size”). As far as I understood, the size should be able to go as high as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-
MTU on my interface is set to 9000 -
Parameter spp of RFNoC RX Radio is set to 2048 -
Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
Von: Marcus D. Leech patchvonbraun@gmail.com
Gesendet: Montag, 4. September 2023 17:09
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de; usrp-users@lists.ettus.com
Cc: Nieland, Michael michael.nieland@iis.fraunhofer.de
Betreff: Re: AW: AW: [USRP-users] Re: RFNoC: strange behavior of FFT block
On 04/09/2023 04:32, Bachmaier, Luca wrote:
Hello Marcus,
I’m currently using a USRP N310. Could you please explain what you wrote a little more? Where can I set the “fft_scaling” parameter, directly in GNU Radio, over the Python API, …? How do I set it there?
Thank you and regards
Luca
In "Block Args" you would specify:
"fft_scaling=<number>"
Where <number> is a decimal constant corresponding to the desired scaling schedule as described in the document
I referred to from Xilinx.
That's about as much as I know. You should probably spend some time with that Xilinx document.
Von: Marcus D. Leech patchvonbraun@gmail.commailto:patchvonbraun@gmail.com
Gesendet: Mittwoch, 23. August 2023 17:10
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.demailto:luca.bachmaier@iis.fraunhofer.de; usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Betreff: Re: AW: [USRP-users] Re: RFNoC: strange behavior of FFT block
On 23/08/2023 08:47, Bachmaier, Luca wrote:
Are you talking about the gain of the “RFNoC Rx Radio” block or a software gain block before the FFT? Even with the highest possible hardware gain it doesn’t seem to work.
So, the "fft_scaling" parameter is actually a kind of bit-mapped value, described here:
https://support.xilinx.com/s/article/1160838?language=en_US
Von: Marcus D. Leech patchvonbraun@gmail.commailto:patchvonbraun@gmail.com
Gesendet: Montag, 21. August 2023 16:49
An: usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
Betreff: [USRP-users] Re: RFNoC: strange behavior of FFT block
On 21/08/2023 09:04, Bachmaier, Luca wrote:
Hello everyone,
I’m currently running into issues while trying to use the RFNoC FFT block in GNU Radio. A picture of my GNU Radio flowgraph and its QT GUI Vector Sink output are attached.
The configuration of UHD / my USRP should be correct as there are no problems when I stream the RFNoC RX Radio Data to my host and calculate the FFT on the host. However, when I try calculating the FFT on the FPGA, the output seems to make no sense. I can’t see a noise floor or any proper signals. There’s just a randomly appearing and disappearing DC spike. Other than that, the spectrum is just a flat line (see vector_sink.png).
I think that this problem comes from some faulty configuration of the RFNoC FFT block. Unfortuantely, I haven’t been able to find any helpful and up-to-date information about its usage online. I would be very glad to get some help from this mailing list.
Thank you and regards
Luca
USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
You could try increasing the gain--it may be that due to the integer implementation of the FFT, the signal levels are dropping below
the minimum quantization.
On 05/09/2023 04:38, Bachmaier, Luca wrote:
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem
now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
(installed from source). With the newer version the FFT block now
correctly displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the
size higher than 256 (Error “samples per package must not be smaller
than atomic item size”). As far as I understood, the size should be
able to go as high as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-MTU on my interface is set to 9000
-Parameter spp of RFNoC RX Radio is set to 2048
-Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq
state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast
qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
I think in the "RFNOC Graph" block, you can specify the SPP in the
"Device Args" parameter.
Hi Luca,
A couple of things. The largest FFT size might be limited to 1024 - even
with MTU=9000. I think that the maximum packet length is often 2000 or
2048 such that when you add a few header bytes, you can no longer achieve
an FFT packet of 2048.
Additionally, if you look in fft_block_control.cpp, you will see that there
is a constant that limits the max size to 1024. This also matches the
parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
Xilinx IP file that is implemented. You can change these in order to build
different sizes, but these are the defaults.
If you search the mailing archive, you may find discussion of this topic
and the need to divorce the concepts of 'fft length' and 'packet length' in
order to achieve FFT lengths greater than 1024.
Rob
On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 05/09/2023 04:38, Bachmaier, Luca wrote:
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem
now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
(installed from source). With the newer version the FFT block now correctly
displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the size
higher than 256 (Error “samples per package must not be smaller than atomic
item size”). As far as I understood, the size should be able to go as high
as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-
MTU on my interface is set to 9000 -
Parameter spp of RFNoC RX Radio is set to 2048 -
Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
pfifo_fast qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
Args" parameter.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Rob,
thanks for your reply. What I originally wanted to bring across with my message was that I cannot run the flowgraph with fft_sizes larger than 256, no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set the fft_size to just 512, I also get the error about the atomic item size mentioned below. I keep wondering why that is.
Regards
Luca
Von: Rob Kossler rkossler@nd.edu
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech patchvonbraun@gmail.com
Cc: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de; usrp-users@lists.ettus.com; Nieland, Michael michael.nieland@iis.fraunhofer.de
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
Hi Luca,
A couple of things. The largest FFT size might be limited to 1024 - even with MTU=9000. I think that the maximum packet length is often 2000 or 2048 such that when you add a few header bytes, you can no longer achieve an FFT packet of 2048.
Additionally, if you look in fft_block_control.cpp, you will see that there is a constant that limits the max size to 1024. This also matches the parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the Xilinx IP file that is implemented. You can change these in order to build different sizes, but these are the defaults.
If you search the mailing archive, you may find discussion of this topic and the need to divorce the concepts of 'fft length' and 'packet length' in order to achieve FFT lengths greater than 1024.
Rob
On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech <patchvonbraun@gmail.commailto:patchvonbraun@gmail.com> wrote:
On 05/09/2023 04:38, Bachmaier, Luca wrote:
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7 (installed from source). With the newer version the FFT block now correctly displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the size higher than 256 (Error “samples per package must not be smaller than atomic item size”). As far as I understood, the size should be able to go as high as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-
MTU on my interface is set to 9000 -
Parameter spp of RFNoC RX Radio is set to 2048 -
Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24http://192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24http://192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
I think in the "RFNOC Graph" block, you can specify the SPP in the "Device Args" parameter.
USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
Hi Luca,
I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2
is the latest that I have used), but I have successfully used FFT lengths
up to 4096. In order to do this, I had to create my own Xilinx FFT IP and
I also had to separate the concepts of streaming packet length from the FFT
length. If you want to do this, I can provide additional info. However,
using the "stock" FFT block provided by Ettus, I believe that you should be
able to stream with FFT length up to 1024 using the N310.
You mentioned in a previous post that your SPP is 2048. I think that this
is an invalid SPP for the radio because of the need for the radio to insert
"packet header" bytes which reduces the max num samples per packet to
<=2000 (or about that). So, my suggestion is to use SPP=1024.
Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which
will allow you to specify an arbitrary block - in this case the FFT block -
to create an RFNoC graph that looks like "rx_radio => DDC => FFT =>
rx_streamer". This eliminates gnuradio from the equation. This example
will capture samples to a file that you can then plot to see the results.
You could run this example initially without the FFT block (rx_radio => DDC
=> rx_streamer) and make sure it is working as you expect. Then you could
try again with the FFT block inserted.
Rob
On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <
luca.bachmaier@iis.fraunhofer.de> wrote:
Hi Rob,
thanks for your reply. What I originally wanted to bring across with my
message was that I cannot run the flowgraph with fft_sizes larger than 256,
no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set
the fft_size to just 512, I also get the error about the atomic item size
mentioned below. I keep wondering why that is.
Regards
Luca
Von: Rob Kossler rkossler@nd.edu
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech patchvonbraun@gmail.com
Cc: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de;
usrp-users@lists.ettus.com; Nieland, Michael <
michael.nieland@iis.fraunhofer.de>
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
Hi Luca,
A couple of things. The largest FFT size might be limited to 1024 - even
with MTU=9000. I think that the maximum packet length is often 2000 or
2048 such that when you add a few header bytes, you can no longer achieve
an FFT packet of 2048.
Additionally, if you look in fft_block_control.cpp, you will see that
there is a constant that limits the max size to 1024. This also matches the
parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the
Xilinx IP file that is implemented. You can change these in order to build
different sizes, but these are the defaults.
If you search the mailing archive, you may find discussion of this topic
and the need to divorce the concepts of 'fft length' and 'packet length' in
order to achieve FFT lengths greater than 1024.
Rob
On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech patchvonbraun@gmail.com
wrote:
On 05/09/2023 04:38, Bachmaier, Luca wrote:
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem
now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7
(installed from source). With the newer version the FFT block now correctly
displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the size
higher than 256 (Error “samples per package must not be smaller than atomic
item size”). As far as I understood, the size should be able to go as high
as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-
MTU on my interface is set to 9000 -
Parameter spp of RFNoC RX Radio is set to 2048 -
Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000
qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
pfifo_fast qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
I think in the "RFNOC Graph" block, you can specify the SPP in the "Device
Args" parameter.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi all,
I just set up a system with X410 USRP. Tried to run a benchmark rate test and saw a lot of errors. Please suggest what could be the reason for the test failure. Host is R740 (16 CPU cores) and Linux is Ubuntu 22.04 with low-latency kernel.100G Mellanox ConnectX-6 NIC cards
$ sudo /usr/local/lib/uhd/examples/benchmark_rate --args "type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6" --priority "high" --multi_streamer --duration 60 --channels "0" --rx_rate 10e6 --rx_subdev "A:0" --tx_rate 10e6 --tx_subdev "A:0"[sudo] password for user:
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; UHD_4.4.0.HEAD-0-g5fac246b[00:00:00.000566] Creating the usrp device with: type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6...[INFO] [MPMD] Initializing 1 device(s) in parallel with args: mgmt_addr=192.168.88.2,type=x4xx,product=x410,serial=3289B23,name=ni-x4xx-3289B23,fpga=CG_400,claimed=False,addr=192.168.20.2,master_clock_rate=500e6[WARNING] [MPM.RPCServer] A timeout event occured![INFO] [MPM.PeriphManager] init() called with device args `fpga=CG_400,master_clock_rate=500e6,mgmt_addr=192.168.88.2,name=ni-x4xx-3289B23,product=x410,clock_source=internal,time_source=internal'.Using Device: Single USRP: Device: X400-Series Device Mboard 0: x410 RX Channel: 0 RX DSP: n/a RX Dboard: A RX Subdev: 0 TX Channel: 0 TX DSP: n/a TX Dboard: A TX Subdev: 0
[00:00:05.797505591] Setting device timestamp to 0...[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10 MHz. Actual rate is: 500 MHz.[WARNING] [MULTI_USRP] Could not set RX rate to 10.000 MHz. Actual rate is 500.000 MHz[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10 MHz. Actual rate is: 500 MHz.[WARNING] [MULTI_USRP] Could not set TX rate to 10.000 MHz. Actual rate is 500.000 MHzSetting TX spb to 1984[00:00:05.799789467] Testing receive rate 500.000000 Msps on 1 channels[00:00:05.801875415] Testing transmit rate 500.000000 Msps on 1 channelsUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUD[U00:00:06.33502762] Detected Rx sequence error.UU[D00:00:06.33952517] Detected Rx sequence error.UUUU[D00:00:06.34387503] Detected Rx sequence error.U[D00:00:06.34802030] Detected Rx sequence error.UUUUU[D00:00:06.35212894] Detected Rx sequence error.U[D00:00:06.35640910] Detected Rx sequence error.
Benchmark rate summary: Num received samples: 0 Num dropped samples: 0 Num overruns detected: 596 Num transmitted samples: 10046501824 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 819855 Num late commands: 0 Num timeouts (Tx): 0 Num timeouts (Rx): 0
Done!
$ ifconfigenp59s0f0np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255 inet6 fe80::ba3f:d2ff:fe57:b77a prefixlen 64 scopeid 0x20<link> ether b8:3f:d2:57:b7:7a txqueuelen 1000 (Ethernet) RX packets 15144837 bytes 101888797100 (101.8 GB) RX errors 0 dropped 2423 overruns 0 frame 0 TX packets 12311297 bytes 87947193629 (87.9 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp59s0f1np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::ba3f:d2ff:fe57:b77b prefixlen 64 scopeid 0x20<link> ether b8:3f:d2:57:b7:7b txqueuelen 1000 (Ethernet) RX packets 406107 bytes 2296309836 (2.2 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 502690 bytes 3421432091 (3.4 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kind regards,Hongwei
On 11/09/2023 12:09, zhou via USRP-users wrote:
Hi all,
I just set up a system with X410 USRP. Tried to run a benchmark rate
test and saw a lot of errors. Please suggest what could be the reason
for the test failure.
Host is R740 (16 CPU cores) and Linux is Ubuntu 22.04 with low-latency
kernel.
100G Mellanox ConnectX-6 NIC cards
$ sudo /usr/local/lib/uhd/examples/benchmark_rate
--args
"type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6"
--priority "high"
--multi_streamer
--duration 60
--channels "0"
--rx_rate 10e6
--rx_subdev "A:0"
--tx_rate 10e6
--tx_subdev "A:0"
[sudo] password for user:
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11;
UHD_4.4.0.HEAD-0-g5fac246b
[00:00:00.000566] Creating the usrp device with:
type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.88.2,type=x4xx,product=x410,serial=3289B23,name=ni-x4xx-3289B23,fpga=CG_400,claimed=False,addr=192.168.20.2,master_clock_rate=500e6
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [MPM.PeriphManager] init() called with device args
`fpga=CG_400,master_clock_rate=500e6,mgmt_addr=192.168.88.2,name=ni-x4xx-3289B23,product=x410,clock_source=internal,time_source=internal'.
Using Device: Single USRP:
Device: X400-Series Device
Mboard 0: x410
RX Channel: 0
RX DSP: n/a
RX Dboard: A
RX Subdev: 0
TX Channel: 0
TX DSP: n/a
TX Dboard: A
TX Subdev: 0
[00:00:05.797505591] Setting device timestamp to 0...
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set RX rate to 10.000 MHz. Actual
rate is 500.000 MHz
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set TX rate to 10.000 MHz. Actual
rate is 500.000 MHz
Setting TX spb to 1984
[00:00:05.799789467] Testing receive rate 500.000000 Msps on 1 channels
[00:00:05.801875415] Testing transmit rate 500.000000 Msps on 1 channels
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUD[U00:00:06.33502762]
Detected Rx sequence error.
UU[D00:00:06.33952517] Detected Rx sequence error.
UUUU[D00:00:06.34387503] Detected Rx sequence error.
U[D00:00:06.34802030] Detected Rx sequence error.
UUUUU[D00:00:06.35212894] Detected Rx sequence error.
U[D00:00:06.35640910] Detected Rx sequence error.
Benchmark rate summary:
Num received samples: 0
Num dropped samples: 0
Num overruns detected: 596
Num transmitted samples: 10046501824
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 819855
Num late commands: 0
Num timeouts (Tx): 0
Num timeouts (Rx): 0
Done!
$ ifconfig
enp59s0f0np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255
inet6 fe80::ba3f:d2ff:fe57:b77a prefixlen 64 scopeid 0x20<link>
ether b8:3f:d2:57:b7:7a txqueuelen 1000 (Ethernet)
RX packets 15144837 bytes 101888797100 (101.8 GB)
/RX errors 0 dropped 2423 overruns 0 frame 0/
TX packets 12311297 bytes 87947193629 (87.9 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp59s0f1np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::ba3f:d2ff:fe57:b77b prefixlen 64 scopeid 0x20<link>
ether b8:3f:d2:57:b7:7b txqueuelen 1000 (Ethernet)
RX packets 406107 bytes 2296309836 (2.2 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 502690 bytes 3421432091 (3.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kind regards,
Hongwei
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
The fact that the actual IP interface is seeing dropped frames indicates
that likely the ringbuf pool on that NIC is too small.
Check out the support that ethtool has for this:
https://www.24x7serversupport.com/blog/how-to-tuneup-tx-and-rx-buffers-on-network-interface/
Hi Marcus,
Thanks for your reply.The original ring buffer is 1024 for Tx and Rx. Now I have changed them to 4096. Still see overruns and underruns.Ring parameters for enp59s0f0np0:Pre-set maximums:RX: 8192RX Mini: n/aRX Jumbo: n/aTX: 8192Current hardware settings:RX: 4096RX Mini: n/aRX Jumbo: n/aTX: 4096
Ring parameters for enp59s0f1np1:Pre-set maximums:RX: 8192RX Mini: n/aRX Jumbo: n/aTX: 8192Current hardware settings:RX: 4096RX Mini: n/aRX Jumbo: n/aTX: 4096
Benchmark rate summary: Num received samples: 12617833512 Num dropped samples: 17321163392 Num overruns detected: 112 Num transmitted samples: 9159225280 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 856834 Num late commands: 0 Num timeouts (Tx): 0 Num timeouts (Rx): 0
I think my computer is not fast enough for 500MHz sampling rate. The computer I am using is Dell PowerEdge R740, CPU is Intel(R) Xeon(R) Bronze 3106 CPU @ 1.70GHz
What is the recommended computer HW configuration?
Another question is UHD4.5. I tried UHD4.5, but there was MPM issueThe MPM software on your device is older than the FPGA you're trying to
use. Because you're using master, they haven't published updated
filesystems with the new MPM yet, but there will be a release candidate
very soon for UHD 4.5 you could try.
So, I have to use UHD4.4 now.
Kind regards,Hongwei
On Monday, 11 September 2023 at 22:15:21 BST, Marcus D. Leech <patchvonbraun@gmail.com> wrote:
On 11/09/2023 12:09, zhou via USRP-users wrote:
Hi all,
I just set up a system with X410 USRP. Tried to run a benchmark rate test and saw a lot of errors. Please suggest what could be the reason for the test failure. Host is R740 (16 CPU cores) and Linux is Ubuntu 22.04 with low-latency kernel. 100G Mellanox ConnectX-6 NIC cards
$ sudo /usr/local/lib/uhd/examples/benchmark_rate \ --args"type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6" \ --priority "high" \ --multi_streamer \ --duration 60 \ --channels "0" \ --rx_rate 10e6 \ --rx_subdev "A:0" \ --tx_rate 10e6 \ --tx_subdev "A:0" [sudo] password for user:
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11; UHD_4.4.0.HEAD-0-g5fac246b [00:00:00.000566] Creating the usrp device with:type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6... [INFO] [MPMD] Initializing 1 device(s) in parallel with args:mgmt_addr=192.168.88.2,type=x4xx,product=x410,serial=3289B23,name=ni-x4xx-3289B23,fpga=CG_400,claimed=False,addr=192.168.20.2,master_clock_rate=500e6 [WARNING] [MPM.RPCServer] A timeout event occured! [INFO] [MPM.PeriphManager] init() called with device args`fpga=CG_400,master_clock_rate=500e6,mgmt_addr=192.168.88.2,name=ni-x4xx-3289B23,product=x410,clock_source=internal,time_source=internal'. Using Device: Single USRP: Device: X400-Series Device Mboard 0: x410 RX Channel: 0 RX DSP: n/a RX Dboard: A RX Subdev: 0 TX Channel: 0 TX DSP: n/a TX Dboard: A TX Subdev: 0
[00:00:05.797505591] Setting device timestamp to 0... [WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10 MHz. Actual rate is: 500 MHz. [WARNING] [MULTI_USRP] Could not set RX rate to 10.000 MHz. Actual rate is 500.000 MHz [WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10 MHz. Actual rate is: 500 MHz. [WARNING] [MULTI_USRP] Could not set TX rate to 10.000 MHz. Actual rate is 500.000 MHz Setting TX spb to 1984 [00:00:05.799789467] Testing receive rate 500.000000 Msps on 1 channels [00:00:05.801875415] Testing transmit rate 500.000000 Msps on 1 channels UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUD[U00:00:06.33502762] Detected Rx sequence error. UU[D00:00:06.33952517] Detected Rx sequence error. UUUU[D00:00:06.34387503] Detected Rx sequence error. U[D00:00:06.34802030] Detected Rx sequence error. UUUUU[D00:00:06.35212894] Detected Rx sequence error. U[D00:00:06.35640910] Detected Rx sequence error.
Benchmark rate summary: Num received samples: 0 Num dropped samples: 0 Num overruns detected: 596 Num transmitted samples: 10046501824 Num sequence errors (Tx): 0 Num sequence errors (Rx): 0 Num underruns detected: 819855 Num late commands: 0 Num timeouts (Tx): 0 Num timeouts (Rx): 0
Done!
$ ifconfig enp59s0f0np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255 inet6 fe80::ba3f:d2ff:fe57:b77a prefixlen 64 scopeid 0x20<link> ether b8:3f:d2:57:b7:7a txqueuelen 1000 (Ethernet) RX packets 15144837 bytes 101888797100 (101.8 GB) RX errors 0 dropped 2423 overruns 0 frame 0 TX packets 12311297 bytes 87947193629 (87.9 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp59s0f1np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000 inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255 inet6 fe80::ba3f:d2ff:fe57:b77b prefixlen 64 scopeid 0x20<link> ether b8:3f:d2:57:b7:7b txqueuelen 1000 (Ethernet) RX packets 406107 bytes 2296309836 (2.2 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 502690 bytes 3421432091 (3.4 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kind regards, Hongwei
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
The fact that the actual IP interface is seeing dropped frames indicates that likely the ringbuf pool on that NIC is too small.
Check out the support that ethtool has for this:
https://www.24x7serversupport.com/blog/how-to-tuneup-tx-and-rx-buffers-on-network-interface/
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Rob,
your tip about “rfnox_rx_to_file” is great, I’ve been searching for examples for the UHD Python/C++ API for a while now anyway. Unfortunately it seems like the error is not due to GNU Radio. Even when trying to create a simple “Radio -> FFT -> RX Streamer” chain by calling ./rfnoc_rx_to_file --spp=1024 --block-id FFT --block-props length=512 the flowgraph can’t even start, I get the same error about the atomic item size. Looking at the output, everything should be set correctly:
[…] Requesting samples per packet of: 1024
Actual samples per packet = 1024
[…] Setting block properties to: length=512
Error: ValueError: samples per package must not be smaller than atomic item size
Additionally, I’m very much interesting in how you created your own FFT IP in Xilinx and separated the parameters. I would be happy to get some information from you.
Von: Rob Kossler rkossler@nd.edu
Gesendet: Montag, 11. September 2023 16:54
An: Bachmaier, Luca luca.bachmaier@iis.fraunhofer.de
Cc: Marcus D. Leech patchvonbraun@gmail.com; usrp-users@lists.ettus.com; Nieland, Michael michael.nieland@iis.fraunhofer.de
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
Hi Luca,
I haven't used a recent UHD version with an FFT RFNoC block (probably 4.2 is the latest that I have used), but I have successfully used FFT lengths up to 4096. In order to do this, I had to create my own Xilinx FFT IP and I also had to separate the concepts of streaming packet length from the FFT length. If you want to do this, I can provide additional info. However, using the "stock" FFT block provided by Ettus, I believe that you should be able to stream with FFT length up to 1024 using the N310.
You mentioned in a previous post that your SPP is 2048. I think that this is an invalid SPP for the radio because of the need for the radio to insert "packet header" bytes which reduces the max num samples per packet to <=2000 (or about that). So, my suggestion is to use SPP=1024.
Another suggestion is to try the Ettus example "rfnoc_rx_to_file" which will allow you to specify an arbitrary block - in this case the FFT block - to create an RFNoC graph that looks like "rx_radio => DDC => FFT => rx_streamer". This eliminates gnuradio from the equation. This example will capture samples to a file that you can then plot to see the results. You could run this example initially without the FFT block (rx_radio => DDC => rx_streamer) and make sure it is working as you expect. Then you could try again with the FFT block inserted.
Rob
On Mon, Sep 11, 2023 at 5:30 AM Bachmaier, Luca <luca.bachmaier@iis.fraunhofer.demailto:luca.bachmaier@iis.fraunhofer.de> wrote:
Hi Rob,
thanks for your reply. What I originally wanted to bring across with my message was that I cannot run the flowgraph with fft_sizes larger than 256, no matter whether the maximum possible limit is 1024 or 2048. E.g. if I set the fft_size to just 512, I also get the error about the atomic item size mentioned below. I keep wondering why that is.
Regards
Luca
Von: Rob Kossler <rkossler@nd.edumailto:rkossler@nd.edu>
Gesendet: Mittwoch, 6. September 2023 21:29
An: Marcus D. Leech <patchvonbraun@gmail.commailto:patchvonbraun@gmail.com>
Cc: Bachmaier, Luca <luca.bachmaier@iis.fraunhofer.demailto:luca.bachmaier@iis.fraunhofer.de>; usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com; Nieland, Michael <michael.nieland@iis.fraunhofer.demailto:michael.nieland@iis.fraunhofer.de>
Betreff: Re: [USRP-users] Re: RFNoC: strange behavior of FFT block
Hi Luca,
A couple of things. The largest FFT size might be limited to 1024 - even with MTU=9000. I think that the maximum packet length is often 2000 or 2048 such that when you add a few header bytes, you can no longer achieve an FFT packet of 2048.
Additionally, if you look in fft_block_control.cpp, you will see that there is a constant that limits the max size to 1024. This also matches the parameter "C_NFFT_MAX=10" which you will find in "axi_fft.xci" which is the Xilinx IP file that is implemented. You can change these in order to build different sizes, but these are the defaults.
If you search the mailing archive, you may find discussion of this topic and the need to divorce the concepts of 'fft length' and 'packet length' in order to achieve FFT lengths greater than 1024.
Rob
On Tue, Sep 5, 2023 at 10:06 AM Marcus D. Leech <patchvonbraun@gmail.commailto:patchvonbraun@gmail.com> wrote:
On 05/09/2023 04:38, Bachmaier, Luca wrote:
Hello Marcus,
Thank you for your detailed explanation. I was able to fix the problem now: I updated GNU Radio from 3.10.5 (installed over apt) to 3.10.7 (installed from source). With the newer version the FFT block now correctly displays a noise floor.
So far so good, the FFT resolution is still low as I cannot set the size higher than 256 (Error “samples per package must not be smaller than atomic item size”). As far as I understood, the size should be able to go as high as 2048 when using 10Gbit streaming.
My current configuration should enable that:
-
MTU on my interface is set to 9000 -
Parameter spp of RFNoC RX Radio is set to 2048 -
Current FPGA image is of XG type
In case it’s helpful, here’s the relevant output of ip a of my devices:
Host:
4: enp9s0f1np1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 9c:6b:00:16:8e:96 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.3/24http://192.168.10.3/24 scope global enp9s0f1np1
valid_lft forever preferred_lft forever
USRP:
3: sfp0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast qlen 1000
link/ether 00:80:2f:31:28:42 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.2/24http://192.168.10.2/24 brd 192.168.10.255 scope global sfp0
valid_lft forever preferred_lft forever
I think in the "RFNOC Graph" block, you can specify the SPP in the "Device Args" parameter.
USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
On 12/09/2023 06:52, zhou wrote:
Hi Marcus,
Thanks for your reply.
The original ring buffer is 1024 for Tx and Rx. Now I have changed
them to 4096. Still see overruns and underruns.
Ring parameters for enp59s0f0np0:
Pre-set maximums:
RX: 8192
RX Mini: n/a
RX Jumbo: n/a
TX: 8192
Current hardware settings:
RX: 4096
RX Mini: n/a
RX Jumbo: n/a
TX: 4096
Ring parameters for enp59s0f1np1:
Pre-set maximums:
RX: 8192
RX Mini: n/a
RX Jumbo: n/a
TX: 8192
Current hardware settings:
RX: 4096
RX Mini: n/a
RX Jumbo: n/a
TX: 4096
Benchmark rate summary:
Num received samples: 12617833512
Num dropped samples: 17321163392
Num overruns detected: 112
Num transmitted samples: 9159225280
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 856834
Num late commands: 0
Num timeouts (Tx): 0
Num timeouts (Rx): 0
I think my computer is not fast enough for 500MHz sampling rate. The
computer I am using is Dell PowerEdge R740, CPU is Intel(R) Xeon(R)
Bronze 3106 CPU @ 1.70GHz
What is the recommended computer HW configuration?
Another question is UHD4.5. I tried UHD4.5, but there was MPM issue
The MPM software on your device is older than the FPGA you're trying to
use. Because you're using master, they haven't published updated
filesystems with the new MPM yet, but there will be a release candidate
very soon for UHD 4.5 you could try.
So, I have to use UHD4.4 now.
Kind regards,
Hongwei
A single-core speed of 1.7GHz is very likely insufficient to support
those very-high sample rates.
In general, you want very high single-core clock speed, and the fastest
memory you can put into the system.
I have no specific recommendations for hardware, but newer high-end
CPUs are betterthan older ones--the 3106
is 6 years old now.
On Monday, 11 September 2023 at 22:15:21 BST, Marcus D. Leech
patchvonbraun@gmail.com wrote:
On 11/09/2023 12:09, zhou via USRP-users wrote:
Hi all,
I just set up a system with X410 USRP. Tried to run a benchmark rate
test and saw a lot of errors. Please suggest what could be the reason
for the test failure.
Host is R740 (16 CPU cores) and Linux is Ubuntu 22.04 with low-latency
kernel.
100G Mellanox ConnectX-6 NIC cards
$ sudo /usr/local/lib/uhd/examples/benchmark_rate
--args
"type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6"
--priority "high"
--multi_streamer
--duration 60
--channels "0"
--rx_rate 10e6
--rx_subdev "A:0"
--tx_rate 10e6
--tx_subdev "A:0"
[sudo] password for user:
[INFO] [UHD] linux; GNU C++ version 11.4.0; Boost_107400; DPDK_21.11;
UHD_4.4.0.HEAD-0-g5fac246b
[00:00:00.000566] Creating the usrp device with:
type=x4xx,mgmt_addr=192.168.88.2,addr=192.168.20.2,master_clock_rate=500e6...
[INFO] [MPMD] Initializing 1 device(s) in parallel with args:
mgmt_addr=192.168.88.2,type=x4xx,product=x410,serial=3289B23,name=ni-x4xx-3289B23,fpga=CG_400,claimed=False,addr=192.168.20.2,master_clock_rate=500e6
[WARNING] [MPM.RPCServer] A timeout event occured!
[INFO] [MPM.PeriphManager] init() called with device args
`fpga=CG_400,master_clock_rate=500e6,mgmt_addr=192.168.88.2,name=ni-x4xx-3289B23,product=x410,clock_source=internal,time_source=internal'.
Using Device: Single USRP:
Device: X400-Series Device
Mboard 0: x410
RX Channel: 0
RX DSP: n/a
RX Dboard: A
RX Subdev: 0
TX Channel: 0
TX DSP: n/a
TX Dboard: A
TX Subdev: 0
[00:00:05.797505591] Setting device timestamp to 0...
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set RX rate to 10.000 MHz. Actual
rate is 500.000 MHz
[WARNING] [0/Radio#0] Requesting invalid sampling rate from device: 10
MHz. Actual rate is: 500 MHz.
[WARNING] [MULTI_USRP] Could not set TX rate to 10.000 MHz. Actual
rate is 500.000 MHz
Setting TX spb to 1984
[00:00:05.799789467] Testing receive rate 500.000000 Msps on 1 channels
[00:00:05.801875415] Testing transmit rate 500.000000 Msps on 1 channels
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUD[U00:00:06.33502762]
Detected Rx sequence error.
UU[D00:00:06.33952517] Detected Rx sequence error.
UUUU[D00:00:06.34387503] Detected Rx sequence error.
U[D00:00:06.34802030] Detected Rx sequence error.
UUUUU[D00:00:06.35212894] Detected Rx sequence error.
U[D00:00:06.35640910] Detected Rx sequence error.
Benchmark rate summary:
Num received samples: 0
Num dropped samples: 0
Num overruns detected: 596
Num transmitted samples: 10046501824
Num sequence errors (Tx): 0
Num sequence errors (Rx): 0
Num underruns detected: 819855
Num late commands: 0
Num timeouts (Tx): 0
Num timeouts (Rx): 0
Done!
$ ifconfig
enp59s0f0np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.20.1 netmask 255.255.255.0 broadcast 192.168.20.255
inet6 fe80::ba3f:d2ff:fe57:b77a prefixlen 64 scopeid 0x20<link>
ether b8:3f:d2:57:b7:7a txqueuelen 1000 (Ethernet)
RX packets 15144837 bytes 101888797100 (101.8 GB)
/RX errors 0 dropped 2423 overruns 0 frame 0/
TX packets 12311297 bytes 87947193629 (87.9 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp59s0f1np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.10.1 netmask 255.255.255.0 broadcast 192.168.10.255
inet6 fe80::ba3f:d2ff:fe57:b77b prefixlen 64 scopeid 0x20<link>
ether b8:3f:d2:57:b7:7b txqueuelen 1000 (Ethernet)
RX packets 406107 bytes 2296309836 (2.2 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 502690 bytes 3421432091 (3.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kind regards,
Hongwei
USRP-users mailing list --usrp-users@lists.ettus.com mailto:usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com mailto:usrp-users-leave@lists.ettus.com
The fact that the actual IP interface is seeing dropped frames
indicates that likely the ringbuf pool on that NIC is too small.
Check out the support that ethtool has for this:
https://www.24x7serversupport.com/blog/how-to-tuneup-tx-and-rx-buffers-on-network-interface/
https://www.24x7serversupport.com/blog/how-to-tuneup-tx-and-rx-buffers-on-network-interface/
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com