hi guys so ive been looking into my dropped packets as i found out thru ifconfig that my eth2 (wan) was dropping packets on rx. now idk if increasing buffer sizes helps but i seen thru ethtool -G that my rx and tx buffer sizes were already set at the max which is 1024. what i am trying to do is prevent from packets being dropped and i am already running sqm cake. im assuming that if i modify the txqueue len from default 1000 to 2000, 3000, etc... it might help prevent dropping packets. But then again, that is just an assumption. if anyone has any advice or knowledge i can gain from, id greatly appreciate it. For more info i am running the nanopi r6s with kmod-r8125 NIC with openwrt RC4 i believe. my connection speed is 2000mb down with 350mb up
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/dhcp
cat /etc/config/firewall
ifconfig wan
cat /proc/net/softnet_stat
Also add result link from https://www.waveform.com/tools/bufferbloat
I will post the information once I’m home. But I did increase the txqueue to 2000 for my wan and it wasn’t dropping packets anymore. But I will follow up tonight and see if anything has changed over night.
It is dropping RX packets, txqueue plays no role, it is net.core.netdev_max_backlog that needs doubling
I believe the default for mine on that is like a 1000
What would you recommend doubling it too. Currently my set up is eth2 (wan). Eth1 (can be a wan or lan port but it is my lan) currently hosts my access point which provides WiFi for about 20 devices and then eth0 which has my pc hardwired to it.
Any benefit to modifying txqueuelen values?
That is a job best left to BQL, byte queue limits...
Is that a qdisc? I’ve been experimenting a lot behind the scenes of lan ports. Such as buffer sizes and such. I’ve lowered buffer sizes for my eth0 so that my packets are sent faster for gaming but again I’ve been testing on and off. Stumbled upon my packets being dropped and increasing the txqueuelen did help. All in all for UDP packets I don’t want them being in a queue long enough since it’s critical for fps shooters. I will try increasing the back log but I am open to any and all info. As of now I have no knowledge of bql. New to openwrt for about a year and a half now.
Provide softnet_stat and ifconfig first?
Saying 10 rx drops in million can be as well bad checksums dropped.
Sure will. At work right now. Will afterwards
No, it is part of the kernel for many (but not all ethernet divers)
Yeah, do not do this manually... BQL if supported is a much better solution.
try to use ethtool to get statistics from the interface:
(opkg update ; opkg install ethtool-full)
then run ethtool -S YOURINTERFACE
here is an example from my wan interface eth2:
root@turris:~# ethtool -S eth2
NIC statistics:
good_octets_received: 2186245158573
good_frames_received: 1748587958
bad_octets_received: 0
bad_frames_received: 0
broadcast_frames_received: 1
multicast_frames_received: 8640
unrec_mac_control_received: 0
good_fc_received: 24412
bad_fc_received: 0
undersize_received: 0
fragments_received: 0
oversize_received: 0
jabber_received: 0
mac_receive_error: 0
bad_crc_event: 0
collision: 0
late_collision: 0
rx_discard: 24414
rx_overrun: 0
frames_64_octets: 178700
frames_65_to_127_octets: 743818367
frames_128_to_255_octets: 276757425
frames_256_to_511_octets: 60799658
frames_512_to_1023_octets: 40633363
frames_1024_to_max_octets: 1544240015
good_octets_sent: 156363166335
good_frames_sent: 924652436
excessive_collision: 0
multicast_frames_sent: 364837
broadcast_frames_sent: 115147
fc_sent: 0
internal_mac_transmit_err: 0
eee_wakeup_errors: 0
skb_alloc_errors: 0
refill_errors: 0
rx_xdp_redirect: 0
rx_xdp_pass: 0
rx_xdp_drop: 0
rx_xdp_tx: 0
rx_xdp_tx_errors: 0
tx_xdp_xmit: 0
tx_xdp_xmit_errors: 0
this should tell us a bit more about potential errors...
Well the problem are over sized and under managed queues... so if you use a traffic shaper and a proper AQM you do not need to play games with interface queues.
I see. As of now I do have pfifo_fast running as my interfaces and I will consider to switch back to cake for wan and fq_codel for others. Def will need to try BQL. I’m not sure why my packets are being dropped but I do have a lot of devices under my network 24:7.
Again, I will post more info of my network device once I close my shop up for the day. I’m pacific time so it’ll be in about 5hrs
Need all config files, discart might be justified like network noise falling outside rx filter (incl vlan)
So, typically OpenWrt will default to BQL if the driver supports it. To test it here is a rather crude way:
log into your rputer and keep executing:
cat /sys/class/net/eth2*/queues/tx-0/byte_queue_limits/*
while running a speedtest. It a) should report numbers and b) some of the numbers should change during the speedtest.
Might well be, I really would start with ethtool statistics first and then take it from there...
I am not trying to debug my link, thanks. I just posted this as reference how this would look.
I believe my driver which is kmod-r8125 doesn’t support BQL.
Even single queue can be regulated with all software qdisc.