On Fri, Jun 21, 2013 at 10:04 AM, Henning Rogge <[email protected]> wrote: > The main problem with RTT and buffers is that you will not get "really > bad RTTs" until the link is saturated.
Sigh. Humans have a tendency to think of bandwidth as some number taken from samples over a second, or many seconds. At the timescales that networks operate at, saturation can occur on timescales much less than that. At the lowest timescale possible on a given link you are either at capacity 1 or 0. There are multiple examples of this in my talks of late. For example, DASH traffic (what netflix basically does) starts a new transaction every 10 seconds, ramps up rapidly (because they are co-located usually in the same data center as the ISP) until a 6mbit stream is delivered, then it goes quiet until the next 10 seconds of video need to be delivered. The last few moments of this induce dozens of ms of latency on the cable modem link I looked at when I had time. A simpler example of this fallacy is to flood ping a network for 1 second every 10 seconds. If you take an average, you might see 30% utilization and think everything is fine, but for 3 seconds it's unusable unless "something is done" to fq other packets inbetween. One place where this really gets to me is in looking at mrtg statistics, which use a 5 minute average. I know full well that the network is periodically saturated based on the drop statistics, but the averages are consistently well below the provided rate due to the bursty nature of traffic in general. I need to get around to monitoring packet drops better via mrtg in particular and add some more instrumentation to the kernel as to when and why they happen... And I keep wondering about what traffic on wifi "really" looks like in relation to this wonderful, old, paper, that has embedded itself in many a conciousness... https://plus.google.com/u/0/107942175615993706558/posts/BPd4TpA2Ssg -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
