| |||||||||||||
The CHOKe packet schedulerThe CHOKe packet schedulerPosted Jan 14, 2011 9:28 UTC (Fri) by marcH (subscriber, #57642)In reply to: The CHOKe packet scheduler by paulj Parent article: The CHOKe packet scheduler
I think "in the middle of it" is misleading.
A queue size matters only when it becomes a bottleneck. When a queue is empty its maximum size obviously does not matter.
If your traffic goes first to a gigabit wire, and then through wifi, the queue size of your gigabit wire will never matter. Because the wifi queue will bottleneck first, fill up and drop the packets first.
It does not hurt to fine tune the queue size of every link just in case. But if you only want a quick fix you just need to look at your usual bottlenecks.
By the way, is the TX ring size in Linux finally adjusted according to the link speed? This should be a very basic thing to implement...
(Log in to post comments)
The CHOKe packet scheduler Posted Jan 14, 2011 9:54 UTC (Fri) by paulj (subscriber, #341) [Link]
Over-sized buffers matter greatly, *especially* when they back on to a much slower link. Your GigE NIC will *NOT* respond to congestion at the wifi link, it'll keep blasting out packets (at least, it will seem so from the POV of a much slower wifi link). Which will just make the congestion on your wifi link even worse, particularly so given 802.11's malfeature of trying to implement reliability in a low-level link-layer - which just amplifies congestion problems.
There's no way for Linux to know just from your local link-speed what the correct size is. Ethernets in the past tended to be relatively homogeneous wrt segments, but these days they can be extraordinarily mismatched - with GigE segments often bridged together with 802.11 links whose reliability, latency and bandwidth make you yearn fondly for the thinnet of 20+ years ago.
The CHOKe packet scheduler Posted Jan 14, 2011 10:50 UTC (Fri) by marcH (subscriber, #57642) [Link]
> Your GigE NIC will *NOT* respond to congestion at the wifi link, it'll keep blasting out packets
For sure the NIC *alone* would, but TCP (or DCCP) do NOT.
TCP is ACK-clocked on the bottleneck. Just try it! The name of this feature is "congestion avoidance", google it.
> There's no way for Linux to know just from your local link-speed what the correct size is.
ethtool eth0
> Ethernets in the past tended to be relatively homogeneous wrt segments, but these days they can be extraordinarily mismatched
It does not matter: every link needs to adjust according to its *own* speed.
The CHOKe packet scheduler Posted Jan 14, 2011 15:31 UTC (Fri) by njs (guest, #40338) [Link]
> By the way, is the TX ring size in Linux finally adjusted according to the link speed? This should be a very basic thing to implement...
Nope. (And it's "ring sizes", not "ring size"; every driver has its own TX queue handling code, plus there's the TX queue in the network layer itself.) I do have some patches to auto-tune the iwlwifi driver's queues, but haven't had a chance to benchmark them properly...
|
|||||||||||||