| |||||||||||||
The CHOKe packet schedulerThe CHOKe packet schedulerPosted Jan 14, 2011 9:54 UTC (Fri) by paulj (subscriber, #341)In reply to: The CHOKe packet scheduler by marcH Parent article: The CHOKe packet scheduler
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.
(Log in to post comments)
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.
|
|||||||||||||