Slashdot Mirror
Is Your Internet Connection Free From Bufferbloat? (blogspot.com)
Bufferbloat is that "undesirable latency that comes from a router or other network equipment buffering too much data," according to the site for
an ongoing project trying to address it. Now long-time Slashdot reader mtaht writes:Inside the lede-project, two core new bufferbloat-fighting techniques are poised to enter the linux mainline kernel and thousands of routers -- the first being a fq-codel'd and airtime fair scheduler for wifi, and the second, the new "cake" qdisc, which outperforms fq_codel across the board for shaping inbound and outbound connections.
His submission ends with a question for Slashdot readers. "It's been nearly six years since the start of the bufferbloat project. Have you or has your ISP fixed your bufferbloat yet?"
His submission ends with a question for Slashdot readers. "It's been nearly six years since the start of the bufferbloat project. Have you or has your ISP fixed your bufferbloat yet?"
Say, I wasn't born yesterday. I know very well that if I just disconnect the cables and put the router in the microwave for 45 seconds at 50% power it'll do the same thing.
You are welcome on my lawn.
...is what slows my connection speed down. Fuck, I could have a gigabit connection and would spend 80% of my time waiting for the next version of ad.doubleclick.net, etc. Really? Bufferbloat? I wish!
DSL is unfortuantely the best internet connection in the small town I live in. The upload rate of these connections is really slow, and for large uploads, can saturate the connection. What this translates to in the real world is constant complaints from people about how their internet connection has just died for no good reason. What's happening in 99% of these cases is that some iPad in their house is backing up to iCloud, and bufferbloat from this upload is temporarily wiping out download speeds.
What I did was install the OpenWRT firmware on my TP-Link router, and install the SQM (Smart Queue Management) QoS application on it. This shapes uploads so that bufferbloat is greatly reduced. I tested all of this on DSLReport's Bufferbloat page, and it works great.
If you are referring to the cake article, the baseline latency of the path is ~11ms. It grows to about 250ms under pressure from a tcp transfer with a "normal" cable modem, and to only 16ms or so with cake. See the bar graph... wifi could get much much worse. but we fixed it in the upcoming linux 3.10 release. Not that anybody seems to understand....
It is entirely probable we've been inside our own filter bubble so long (6 years) we cannot properly communicate with first time readers! some folk explaining the problem... the ietf video shows the benefit from fixing it. https://www.bufferbloat.net/pr... showing the extent: http://www.dslreports.com/spee... you have this entirely backwards: "Buffering can reduce latency, especially under heavy load, by better bandwidth utilization, and allowing faster retransmission of dropped packets. If it is slowing things down, then you should fix the buffering rather than eliminating it." You want enough buffering to absorb bursts, but any more just adds latency. Van Jacobson and kathie nichols calls this distinction good queue and bad queue: https://tools.ietf.org/html/dr... Less buffering (and fair queuing) allows for faster retransmission in particular.
With dislreports and other aggregation tests, the bloat for download and upload may not be symmetric. So the resulting score might not be as good as it looks.
Paying for a commercial connection? Test for this kind of performance daily and scream as soon as it drops. Otherwise why bother to pay so much?
In the United States and other jurisdictions a home 'customer' user is not expected to run a "server" on their paid for Internet connection. Downloads may be finely tuned to low bloat. But upload may have significant bufferbloat, caps and gradual dropout. For financial reasons, of course.
This upload problem may get to be much worse in the future. More and more services push data from "client" devices in the home or office. Camera phone videos, twitch streams, shared google docs and your home automation spyware upend the upload/download assumptions of last-hop telcos. P2P is impacted now. The highly asymmetric buffering of uploads is detectable using protocols like bittorrent that don't have client-server separation.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
Badly managed buffers are a massive problem for latency. Just look at this graph from the article. You see the four ping time measurements on the right? You see how one of them is 100-250ms and the rest are more like 20ms? That's exactly the same link in all cases, but the first measurement has a giant pile of latency introduced purely by poor buffer management.
I'm not going to dismiss the problem you described, because I agree it's a problem. But it makes no sense to worry about 100ms on cross-Atlantic links and yet completely dismiss 200ms right on the first hop.