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