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]> <mailto:[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
<https://files.ettus.com/manual/page_transport.html> : MTU=8000 for
10GigE
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
<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]> <mailto:[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]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
USRP-users mailing list -- [email protected]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
