[opensuse] Re: Is 40 dropped packets out of 300,000 high? This is wired cat5 LAN
Is your interface "exposed" to outside internet? FWIW, I see about 8351 errors on one of my interfaces:
netstat -in Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg br0 9000 0 181542006 0 0 0 183787495 0 0 0 BMRU eth0 9000 0 42171614 0 0 0 18706929 0 0 0 BMRU eth2 1500 0 1286349301 0 8351 0 1974909214 0 0 0 BMRU eth5 9000 0 249990679 0 0 0 199901144 0 0 0 BMRU
Is the interface you are having problems on exposed to the internet? tc shows over 65K packets that were requeued on xmit (so it's a busy dev)... qdisc mq 0: dev eth2 root backlog 0b 0p requeues 29532 backlog 0b 0p requeues 2286 backlog 0b 0p requeues 2477 backlog 0b 0p requeues 3461 backlog 0b 0p requeues 4437 backlog 0b 0p requeues 2822 backlog 0b 0p requeues 2942 backlog 0b 0p requeues 4378 backlog 0b 0p requeues 6729 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, May 31, 2017 at 6:29 PM, L A Walsh
Is your interface "exposed" to outside internet?
It's NAT'ed behind a firewall. But I can browse and get security patches. No inbound connectivity from the Internet at all.
FWIW, I see about 8351 errors on one of my interfaces:
netstat -in
Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg br0 9000 0 181542006 0 0 0 183787495 0 0 0 BMRU eth0 9000 0 42171614 0 0 0 18706929 0 0 0 BMRU eth2 1500 0 1286349301 0 8351 0 1974909214 0 0 0 BMRU eth5 9000 0 249990679 0 0 0 199901144 0 0 0 BMRU
That's 8300 out of 1.286 billion. Well below 0.1%.
Is the interface you are having problems on exposed to the internet?
tc shows over 65K packets that were requeued on xmit (so it's a busy dev)...
I don't use tc much. Is this helpful:
sudo tc -s qdisc ls dev eth0 qdisc mq 0: root Sent 122904229458 bytes 90249084 pkt (dropped 0, overlimits 0 requeues 1584046) backlog 0b 0p requeues 1584046 qdisc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 122904054398 bytes 90246915 pkt (dropped 0, overlimits 0 requeues 1584046) backlog 0b 0p requeues 1584046 qdisc pfifo_fast 0: parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 175060 bytes 2169 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0
So on transmit for eth0 (I believe) there were 90 million packets sent and about 1.6 million (~1.6%) of them had to be requeued. That continues to seem high. I haven't changed out any cables, etc. yet. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2017 03:47 PM, Greg Freemyer wrote:
I haven't changed out any cables, etc. yet.
Greg
Maybe just reseat them a few times. Stuff oxidizes. Swap router ports. Cable failure/faulting is so rare in my experience that unless the cable is subject to foot traffic or stress, its unlikely to be a failed cable. You'd never achieve a gigibit link light if even one lead was broken. So it must be something really intermittent. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote: [linda stats]
That's 8300 out of 1.286 billion. Well below 0.1%.
sudo tc -s qdisc ls dev eth0 qdisc mq 0: root Sent 122904229458 bytes 90249084 pkt backlog 0b 0p requeues 1584046 Sent 122904054398 bytes 90246915 pkt backlog 0b 0p requeues 1584046 Sent 175060 bytes 2169 pkt backlog 0b 0p requeues 0
So on transmit for eth0 (I believe) there were 90 million packets sent and about 1.6 million (~1.6%) of them had to be requeued.
That continues to seem high.
--- I would agree, but I don't know what's acceptable. requeues are ways to "slow" down traffic at a particular level because that "level", priority or class of traffic has been too busy.
I haven't changed out any cables, etc. yet.
They deteriorate over time, "sorta", If you have a spare cable and adapter, might provide useful data to try. That said, dropped packets can come from things other than HW probs -- like timing probs (a burst came in when computer was busy). Do you know how your kernel's preemption model is set? (zgrep -i preempt /proc/config.gz). Mostly looking at PREEMPT model: None - no forced preemption (server) voluntary kernel preemption (desktop) preemptible kernel (low-latency desktop) I wouldn't agree that servers should use 'none', depends on what you are serving. You don't want a disk-backup causing stutters when you are streaming video from the server. But if you had a slowish disk or one that was dying and needing retries, it might be possible it was blocking handling bytes. Not real likely, but possible... Anyway... do you know what you have? I didn't see in the prev discussion -- there was alot of text to wade through, . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/31/2017 06:29 PM, L A Walsh wrote:
br0 9000 0 181542006 0 0 0 183787495 0 0 0 BMRU eth0 9000 0 42171614 0 0 0 18706929 0 0 0 BMRU eth2 1500 0 1286349301 0 8351 0 1974909214 0 0 0 BMRU eth5 9000 0 249990679 0 0 0 199901144 0 0 0 BMRU
Looks like someone's running jumbo frames. https://en.wikipedia.org/wiki/Jumbo_frame -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 05/31/2017 06:29 PM, L A Walsh wrote:
Iface MTU
br0 9000 eth0 9000 eth2 1500 eth5 9000
Looks like someone's running jumbo frames. https://en.wikipedia.org/wiki/Jumbo_frame
Yep -- for about 15 years maybe? For some reason it seems to involve maybe ~1/6th the normal packet overhead.... ;-) eth0+eth5 use the bridge (internal house net), while eth2 is an outward facing Iface. It will likely be a while before my outward facing Iface needs the same efficiencies I strive for on my internal net. Good eye! -linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-06-01 05:01, L A Walsh wrote:
James Knott wrote:
On 05/31/2017 06:29 PM, L A Walsh wrote:
Iface MTU
br0 9000 eth0 9000 eth2 1500 eth5 9000
Looks like someone's running jumbo frames. https://en.wikipedia.org/wiki/Jumbo_frame
Yep -- for about 15 years maybe? For some reason it seems to involve maybe ~1/6th the normal packet overhead.... ;-)
Except if a retry is needed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 06/01/2017 03:59 AM, Carlos E. R. wrote:
On 2017-06-01 05:01, L A Walsh wrote:
James Knott wrote:
On 05/31/2017 06:29 PM, L A Walsh wrote:
Iface MTU
br0 9000 eth0 9000 eth2 1500 eth5 9000 Looks like someone's running jumbo frames. https://en.wikipedia.org/wiki/Jumbo_frame
Yep -- for about 15 years maybe? For some reason it seems to involve maybe ~1/6th the normal packet overhead.... ;-) Except if a retry is needed.
Well, that depends on how many retries are needed. If a low number then you're ahead with large frames. The history of this sort of thing is interesting. Ethernet went with smaller frames than token ring, due to packet loss caused by collisions. But token ring didn't have collisions, as only one device, the one holding the token, could transmit at a time. Token ring could have frames over 4K bytes, IIRC. Same thing with IP. Back in the dark ages, the trunks travelled over the mostly analog phone network, which had higher noise levels than digital. So, originally dial up used 576 bytes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/01/2017 03:59 AM, Carlos E. R. wrote:
Except if a retry is needed.
Well, that depends on how many retries are needed. If a low number then you're ahead with large frames. The history of this sort of thing is interesting. Ethernet went with smaller frames than token ring, due to packet loss caused by collisions. ...
Which is non-existent on switched networks these days, so I wonder why they don't increase those frames on the internet. Seems like it would really benefit streaming media and downloads -- the big traffic users on the net. My internet is still running @ 1500 MTU's. My local networks could probably benefit with, at least 128K-256K sizes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2017 08:02 AM, L A Walsh wrote:
Which is non-existent on switched networks these days, so I wonder why they don't increase those frames on the internet. Seems like it would really benefit streaming media and downloads -- the big traffic users on the net. My internet is still running @ 1500 MTU's. My local networks could probably benefit with, at least 128K-256K sizes.
That would be a big job, as much equipment doesn't support jumbo frames. First, you'd have to enable jumbo frames on the ISPs network and trunks, then get everyone else to move to it. As long as there are routers between networks, that's not a big problem, but all devices on a network have to be able to support it. I do know many of the research networks support jumbo frames. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
On 06/01/2017 08:02 AM, L A Walsh wrote:
Which is non-existent on switched networks these days, so I wonder why they don't increase those frames on the internet. Seems like it would really benefit streaming media and downloads -- the big traffic users on the net. My internet is still running @ 1500 MTU's. My local networks could probably benefit with, at least 128K-256K sizes.
That would be a big job, as much equipment doesn't support jumbo frames. First, you'd have to enable jumbo frames on the ISPs network and trunks, then get everyone else to move to it. As long as there are routers between networks, that's not a big problem, but all devices on a network have to be able to support it. I do know many of the research networks support jumbo frames.
Perhaps more importantly - consumer level network interfaces. -- Per Jessen, Zürich (24.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/01/2017 09:11 AM, Per Jessen wrote:
That would be a big job, as much equipment doesn't support jumbo
frames. First, you'd have to enable jumbo frames on the ISPs network and trunks, then get everyone else to move to it. As long as there are routers between networks, that's not a big problem, but all devices on a network have to be able to support it. I do know many of the research networks support jumbo frames. Perhaps more importantly - consumer level network interfaces.
Yep, NICs, switches and routers. Also, I don't think we'll ever see full 9000 byte frames on WiFi, as it maxes out around 1800, IIRC. BTW, back in the late '90s, when I worked at IBM, I set my MTU to about 4K, IIRC, on the token ring network. Of course the other end might be set lower. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Greg Freemyer -
James Knott -
John Andersen -
L A Walsh -
Per Jessen