Hi Marcus, The LLL errors happened in host when it talks to N321.N321 is
connected to the host through two 10GigE SFP cables directly; these is no other
device in the middle. N321 has one extra RJ45 1GigE cable for management. This
cable is connected to a switch; host is also connected to this switch.
If N321 receives unsupported protocols on the management port (RJ45) and then
generated Rx drop, it is reasonable. But on SFP ports, I don't know what
protocol they receive apart from broadcast from host when running
uhd_find_device and the configuration commands.
Does UHD use IRQ or polling method to retrieve data from NIC?
For the ULLL error in host, I doubt on two things:- tx buffer size: because of
the high sampling rate, the tx buffer needs to be bigger to tolerate
fluctuation and interruption during processing. What command can be used to
check tx buffer size?- cpu core allocation, NIC binding. There are 8 cores in
host; I use separate cores for Tx and Rx. In my program, there are four threads
which use 3 cores, but in htop, I can see 8 threads in my process. Are the
extra threads created by UHD?
On Tuesday, 7 September 2021, 22:47:44 BST, Marcus D. Leech
<[email protected]> wrote:
On 2021-09-07 3:59 p.m., zhou wrote:
Thanks a lot, Marcus. The kernel version I am using in host is 5.4.0-81, but
there is no packet drop. It is still strange that packet drop happened in USRP.
In my test, sometimes there are ULLLL errors. I am wondering if there is
something wrong with network buffer. L means "late packet', which means that
the thing that's producing packets isn't "keeping up" with the required
cadence of samples being consumed by the radio.
Do you get this when talking to the N321 from your host, or when using the
N321 in embedded mode (using the
Linux OS running on the N321).
How are your N321 and host computer connected? Are they connected via a
switch or direct connected?
It's not clear to me how the "RX drops" is triggered for the "unsupported
protocols" case--whether that's just unsupported
*ETHERNET* protocols, or any protocol packet for which there isn't a service
registered on the system--in this case your
N321. If it's the latter, then it may just be the case that your host PC is
sending perhaps broadcast or other packets for
which there are no services registered on your N321 system to process them,
so it drops them, and just logs it. Unless
your host PC is doing a LOT of this, it's of no consequence.
On Tuesday, 7 September 2021, 14:39:54 BST, Marcus D. Leech
<[email protected]> wrote:
On 2021-09-07 7:54 a.m., zhou wrote:
Thanks Marcus. What is the reason for Rx packet drop in N321? I have
configured the same MTU on both ends of the connection. Interestingly, there is
no Tx packet loss but Rx. Hmmm, so, just found this:
Beginning with kernel 2.6.37, it has been changed the meaning of dropped packet
count. Before, dropped packets was most likely due to an error. Now, the
rx_dropped counter shows statistics for dropped frames because of:
- Softnet backlog full
- Bad / Unintended VLAN tags
- Unknown / Unregistered protocols
- IPv6 frames when the server is not configured for IPv6
[...]
If the rx_dropped counter stops incrementing while tcpdump is running; then it
is more than likely showing drops because of the reasons listed earlier.
IN other words, mostly harmless. At some point, the semantics of "dropped
packets" changed, and I didn't even notice.
On Tuesday, 7 September 2021, 00:05:57 BST, Marcus D. Leech
<[email protected]> wrote:
On 2021-09-06 6:59 p.m., zhou wrote:
Hi Marcus,
Could you please help on this? I find some confusing information on MTU
configuration in different ettus web pages:
https://files.ettus.com/manual/page_transport.html : MTU=8000 for 10GigE
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks : MTU=9000
for 10GigE
Which one is correct? :
Thanks. They're both valid, in that a larger MTU tends to improve bulk
performance at high sample rates.
The caveat is that BOTH SIDES of the connection have to "agree" on the MTU,
and some host controllers
will happily accept a large MTU, but be unable to actually support it,
although that situation is NOT one
that I have seen in 10GiGe controllers--they inherently want to support
"jumbo frames".
On Monday, 6 September 2021, 22:33:35 BST, zhou via USRP-users
<[email protected]> wrote:
Hi,
I have a problem with the N321 USRP. I find packet dropped in USRP but not in
host. In host, I am running Ubuntu 18.04.
Below is the ifconfig result in N321:
root@ni-n3xx-320CAAB:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:80:2F:32:36:BA
inet addr:192.168.10.165 Bcast:192.168.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:618374 errors:0 dropped:11485 overruns:0 frame:0
TX packets:193714 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39776733 (37.9 MiB) TX bytes:14546432 (13.8 MiB)
Interrupt:27 Base address:0xb000
int0 Link encap:Ethernet HWaddr AE:CD:BA:E1:CF:96
inet addr:169.254.0.1 Bcast:169.254.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:456 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:37392 (36.5 KiB) TX bytes:2770 (2.7 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:89 errors:0 dropped:0 overruns:0 frame:0
TX packets:89 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:7480 (7.3 KiB) TX bytes:7480 (7.3 KiB)
sfp0 Link encap:Ethernet HWaddr 00:80:2F:32:36:BB
inet addr:192.168.12.2 Bcast:192.168.12.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:6239 errors:0 dropped:804 overruns:0 frame:0
TX packets:5669 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18466697 (17.6 MiB) TX bytes:18417536 (17.5 MiB)
sfp1 Link encap:Ethernet HWaddr 00:80:2F:32:36:BC
inet addr:192.168.13.2 Bcast:192.168.13.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1
RX packets:24868 errors:0 dropped:796 overruns:0 frame:0
TX packets:24613 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20486915 (19.5 MiB) TX bytes:19611643 (18.7 MiB)
Below is ifconfig result in host:
user@USRP-SERVER:~$ ifconfig
eno1:flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.10.143 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::b27b:25ff:fe1d:9e4e prefixlen 64 scopeid 0x20<link>
ether b0:7b:25:1d:9e:4e txqueuelen 1000 (Ethernet)
RX packets 5604 bytes 416435 (416.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 404 bytes 68556 (68.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xd2100000-d2120000
enp1s0f0:flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.12.1 netmask 255.255.255.0 broadcast 192.168.12.255
inet6 fe80::faf2:1eff:fe42:dddc prefixlen 64 scopeid 0x20<link>
ether f8:f2:1e:42:dd:dc txqueuelen 1000 (Ethernet)
RX packets 294 bytes 35184 (35.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 395 bytes 37148 (37.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp1s0f1:flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 9000
inet 192.168.13.1 netmask 255.255.255.0 broadcast 192.168.13.255
inet6 fe80::faf2:1eff:fe42:dddd prefixlen 64 scopeid 0x20<link>
ether f8:f2:1e:42:dd:dd txqueuelen 1000 (Ethernet)
RX packets 9 bytes 2228 (2.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 72 bytes 7983 (7.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo:flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 21071 bytes 1497110 (1.4 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21071 bytes 1497110 (1.4 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Could you please let me know what is the possible reason for packet drop in
USRP? How to fix it?
Thanks for any inputs.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
