[Cerowrt-devel] [aqm] [Bloat] the side effects of 330ms lag in the real world
dave.taht at gmail.com
Tue Apr 29 23:21:59 EDT 2014
On Tue, Apr 29, 2014 at 10:01 AM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
> Jim Gettys <jg at freedesktop.org> writes:
>> Now, if someone gives me real fiber to the home, with a real switch fabric
>> upstream, rather than gpon life might be somewhat better (if the switches aren't
>> themselves overbuffered.... But so far, it isn't.
> As a data point for this, I have fibre to my apartment building and
> ethernet into the apartment. I get .5 ms to my upstream gateway and
> about 6 ms to Google. Still measured up to ~20 ms of bufferbloat while
> running at 100 Mbps...
I need to note that what this wonderfully flat CDF for the measurement
stream shows is that short flows under fq_codel leap to the head of
the queue ever better as you get more and more bandwidth available.
The background load flows not shown on this graph are experiencing
5-20ms worth of latency in each direction as per codel's algorithm.
A better test (in progress) would measure typical voip behaviors....
> However, as that graph shows, it is quite possible to completely avoid
> bufferbloat by deploying the right shaping.
It does not "completely avoid bufferbloat", the fq_codel "fast queue"
merely eliminates queuing delay for sparse flows, things like arp, syn,
syn/ack, dns, ntp, etc, as well as the first packet of any flow that
has not built up a queue yet.
(which is, admittedly, quite a lot of bufferbloat reduction)
The rest of the magic comes from codel.
> And in that case fibre
> *does* have a significant latency advantage. The best latency I've seen
> to the upstream gateway on DSL has been ~12 ms.
And reduced RTT = money.
this piece states observed average RTTs at peak times were 17ms for fiber,
28ms for cable, and 44ms for DSL.
I don't know if the underlying report measures baseline unloaded last mile RTT.
> aqm mailing list
> aqm at ietf.org
More information about the Cerowrt-devel