On Sun, Jun 14, 2015 at 4:10 PM, Simon Barber <[email protected]> wrote: > Indeed - I believe that Codel will drop too much to allow maximum bandwidth > utilization, when there are very few flows, and RTT is significantly greater > than target. The theory is - with a Reno based CC the cwind gets cut in half > on a drop. If the drop in cwind is greater than the number of packets in the > queue, then the queue will empty out, and the link will then be idle for a > while. If you want data to keep the data flowing uninterrupted, then you > must have a full unloaded RTT's worth of data in the queue at that point. A > drop will happen, the cwind will be halved (assuming a Reno TCP), and the > sender will stop sending until one (unloaded) RTT's worth of data has been > received. At that point the queue will just hit empty as the sender starts > sending again. > > Simon > > > > On 6/9/2015 10:30 AM, Jonathan Morton wrote: >> >> >> Wouldn't that be a sign of dropping too much, in contrast to your previous >> post suggesting it wouldn't drop enough? >> >> In practice, statistical multiplexing works just fine with fq_codel, and >> you do in fact get more throughput with multiple flows in those cases where >> a single flow fails to each adequate utilisation. >> >> Additionally, utilisation below 100% is really characteristic of Reno on >> any worthwhile AQM queue and significant RTT. Other TCPs, particularly CUBIC >> and Westwood+, do rather better. >> >> - Jonathan Morton >> > > _______________________________________________ > aqm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/aqm
-- Dave Täht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
