| |||||||||||||
The CoDel queue management algorithmThe CoDel queue management algorithmPosted May 10, 2012 12:28 UTC (Thu) by cesarb (subscriber, #6266)Parent article: The CoDel queue management algorithm
> Wireless networking adds some interesting challenges of its own, with its quickly varying link speeds
> The use of time values (rather than packet or byte counts) makes the algorithm function independently of the speed of the links it is managing, so there is no real need to adjust them.
If it works well independent of link speed, surely even variations in wireless link speed will not be a problem?
(Log in to post comments)
The CoDel queue management algorithm Posted May 10, 2012 12:51 UTC (Thu) by Fowl (subscriber, #65667) [Link] Possibly not for maximum throughput though. (TCP slow start and all that)
The CoDel queue management algorithm Posted May 11, 2012 0:29 UTC (Fri) by mtaht (✭ supporter ✭, #11087) [Link]
Most wireless drivers are already horribly overbuffered, and over-retry. this affects codel's estimates enormously. Codel does do a pretty good job, when it gets control of the queue, but it is sub-optimal. Substantial rework of the wireless subsystem appears required, at least at present.
The CoDel queue management algorithm Posted May 13, 2012 21:29 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
An algorithm may work well with a wide variety of link speeds, as long as the link speed remains relatively stable over time.
but when the link speed changes too drastically in too short a time the queue size that was right for the old size is going to be too large (or too small) for the new rate.
The CoDel queue management algorithm Posted May 19, 2012 7:23 UTC (Sat) by Tobu (subscriber, #24111) [Link] Looking at figure 7 in the ACM queue article, showing a wireless simulation with varying bandwidth, a 50Mb/s->1Mb/s transition takes about 20s to get the delays back under 200ms. If there's an intermediate bandwidth stepping, resorbing the queue is quicker.
|
|||||||||||||