| |||||||||||||
PhysicsPhysicsPosted Dec 9, 2011 22:10 UTC (Fri) by marcH (subscriber, #57642)In reply to: Bufferbloat: Dark Buffers in the Internet (ACM Queue) by jmm82 Parent article: Bufferbloat: Dark Buffers in the Internet (ACM Queue)
> hence the reason a magic number for the whole internet will not work.
The 10-100ms range is anything but magic numbers. These two numbers are fundamental requirements coming straight from physics and biology (and a tiny bit of maths).
100ms (give or take) is the amount of buffering required at every potential bottleneck to maximize the throughput of Van Jacobson's congestion control algorithm across a continent. This number does not come from some hairy research but straight from the speed of light and the average size of a continent; not exactly an arbitrary number. Buffer more than 100ms on any link and you will harm latency even more for NO throughput benefit.
10ms is a threshold in human perception - think VoIP and gaming. Again, no magic here: just biology. Less than 10ms buffering harms your throughput (even more) for no perceptible benefit.
It is a funny cosmic coincidence that playing Counter-Strike across an ocean sucks while it's OK on the same continent (well, maybe not between Alaska and Chili but you get the point).
Now these two numbers are orders of magnitude rounded for convenience. If you think the ideal range is rather 15ms-150ms I have absolutely no problem with that. What I have a problem with is:
> I work with cellular internet and 1 to 3 second ping times are far to common.
Researchers always focus on the complicated stuff (here: optimizing between 10 and 100ms). Simply because trivial requirements do not get papers published. Do NOT let researchers distract you from simple facts like: 1 second ping time is just a plain bug/a joke. Reduce buffering to 100ms (or 150ms if you prefer) on every link and you will make most of your customers happier and upset practically NONE.
(Log in to post comments)
mtr and job done Posted Dec 10, 2011 14:23 UTC (Sat) by marcH (subscriber, #57642) [Link]
In a similar fashion, do not let yourself distracted by any impressive monitoring frameworks or charts researchers may be using. Matt's traceroute ("mtr") is almost always good enough to very accurately pinpoint any bufferbloat currently destroying your latency. Sometimes iperf/netperf is not even required; downloading some DVD image is enough. The main problem is not technical but going through first level and second level support. Support stories seldom make it to the ACM/IEEE though.
Science is useful and makes great reads for rainy weekends but, when push comes to shove use simpler engineering to do the job.
Physics Posted Dec 12, 2011 11:49 UTC (Mon) by jlokier (guest, #52227) [Link] 1 second ping time is just a plain bug/a joke. I often use cellular internet with a marginal signal that is oversubscribed, and 5 second ping times are quite common. Even 20 seconds at some times. As these are ping times to the cellular network access point, from an otherwise idle handset, it's quite possible this time cannot be improved by simply dropping packets early at any stage. In other words, it may not be a bufferbloat problem - and it may not be a bug either, if the RF link is simply too marginal and oversubscribed. As far as I can tell, these timings depend greatly on the strength of RF signal, and on the time of day. In this case the way forward looks like newer cellular technology. We all look hopefully at 4G/LTE, and (would be nice) better cross-carrier RF diversity. Even so, it's not clear that "speed of light" is an achievable latency on fully-subscribed large area wireless networks with large numbers of moving devices.
Physics Posted Dec 12, 2011 12:19 UTC (Mon) by marcH (subscriber, #57642) [Link]
> I often use cellular internet with a marginal signal that is oversubscribed, and 5 second ping times are quite common. Even 20 seconds at some times.
> [...] > In other words, it may not be a bufferbloat problem
Whenever you experience ping times over 1 second, something somewhere is buffering your ping (or pong) packet for more than 1 second. Even if this buffer is not "bloated" strictly speaking, holding on any packet for that long is WRONG and is definitely a BUG.
As an example, any link retransmission technique with timeouts over 1 second is simply not compatible with TCP/IP. Making that link technology compatible with TCP/IP is as simple as making it timeout (and drop packets) much, much sooner. It is really that simple.
Now again, finding the *optimal* timeout value is a very difficult problem. However, reducing a multi-seconds timeout to a reasonable 100-150 milliseconds value is NOT difficult at all and will make every user happier, while upsetting none.
Here is a supermarket analogy (for a change). You know that queues always become too long at peak time. Customers complain about it. You have money for two extra tills. But you do not proceed because it is oooh so hard to find the optimal number of tills.
> In this case the way forward looks like newer cellular technology.
This is throwing out the baby with the bath water. And the newer technology might make the same mistake again. And in any case it will not displace 2.5G/3G everywhere overnight.
> Even so, it's not clear that "speed of light" is an achievable latency
Of course it's not; you need some reasonable amount of buffering for a number of reasons.
Physics Posted Dec 12, 2011 12:47 UTC (Mon) by ekj (guest, #1524) [Link]
That's a bug. A packet is always either in-transit, being processed by a device, or being stored in a buffer for later processing and/or later sending.
The only way you can get 1+ seconds on local short-distance links, is by having the packet spend the huge majority of that time stored in some buffer. Which is a bug.
You want a sufficient bug that short term spikyness of packet-arrival does not needlessly cause lost packets when transmission a few milliseconds later would be preferable.
But 5 seconds, or even 1 second, worth of buffering is *way* too much, sure we can debate if you want 25ms or 250ms worth of buffering, and the answer is surely "it depends", but there's just no way 5 *seconds* worth of buffering can avoid causing an order of magnitude more problems than it solves.
|
|||||||||||||