Is Your Internet Connection Free From Bufferbloat? (blogspot.com) 147
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?"
Nagle algorithm? (Score:1)
Disable Nagle's Algorithm?
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
And how would that improve things?
It wouldn't. Nagle's algorithm doesn't cause congestion, it reduces it.
"Solving" a problem by going back to a probably worse one isn't really "solving it"
The first step in "solving" a problem is verifying that it is actually a problem. I am not convinced that "bufferbloat" (whatever that means) is a problem. 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.
... and yes, I read TFA. It is a bunch of
Re:Nagle algorithm? (Score:5, Informative)
Re: (Score:2)
Re: (Score:3)
Buffering can reduce latency, especially under heavy load, by better bandwidth utilization
You have no idea what you're talking about. Buffering is one of the main causes of latency. Ever see a 1,000ms ping? That's not because the speed of light is too slow, that's because there is a backlog of packets in the buffer. With the speed of light through fiber, no one should ever see a ping above 300ms to anywhere in the world. The highest ping I see from Midwest USA to Australia, India, or China is about 220ms.
Buffers are not inherently bad, but "bufferbloat" is because buffers are too large. Too la
GEO is 0.24 s round trip (Score:2)
With the speed of light through fiber, no one should ever see a ping above 300ms to anywhere in the world.
Even to places where there's no fiber connection? In a lot of places, the only route to the Internet with a throughput greater than the 0.15 Mbps of IDSL is through a satellite in geostationary Earth orbit, 36,000 km up. An ICMP ECHO request from a subscriber to a satellite ISP, such as Exede, needs to go up to the satellite and down to the destination network, and its response needs to come out of the network and then go up to the satellite and back down to the subscriber. That's 0.12 light seconds for eac
Re: (Score:2)
In a lot of places
At some point in your life, you should realize that "no one" mean very very rarely. Absolutes are never absolute. I question if my last statement makes any sense.
Re: Nagle algorithm? (Score:2, Insightful)
It doesn't matter how big or small the buffer is, what matters is why it's filling up to start with.
If you're buffering because of a transient traffic spike or network load, then the buffer helps. If it's constantly filling up and evicting then there's a deeper problem that won't be solved either by using, eliminating, or changing the buffering strategy.
Re: (Score:2)
If it's constantly filling up and evicting
This is actually normal for any congestion control algorithm that uses only packetloss to signal congestion. TCP? It keeps sending data until the buffer fill and drops "a packet", but we really know FIFO taildrop buffers drop bunches of packets. Then TCP backs off. But wait, there's more! You have many TCP flows going over the connection, so they are all fluctuation, keeping the buffer either in a state of steady full, which causes high latency and lots of dropped packets, or wildly swinging between empty a
Re: (Score:3)
The article talks about shaping download, which isn't possible at the endpoint. The traffic is already there and you have to deal with it. Dropping it will create retransmits for TCP and make the problem worse.
Wrong. Dropped packets signal congestion. If you don't signal congestion, the congestion will only get worse. You eventually have to drop a packet. The sooner you drop the packet after congestion has started, the less the congestion will be. The flip side is if you signal too early, you lose effective bandwidth. I shape my download and it has caused my average to go up because it stabilizes the flows.
With normal fifo buffers, once the buffer is full, you get a burst of lost packets. This is much worst tha
Re: (Score:2)
How can I tell? (Score:2)
Re: How can I tell? (Score:2)
Why is bufferbloat bad?
Re: (Score:2)
Well, your sig was, anyway.
Re: (Score:2)
Re: (Score:1)
causes high latencies (very bad for gaming)
Re: (Score:2)
I took the test and got an A in buffer bloat. Is that good or bad?
Re: (Score:2)
bad you should immediately turn off you internet fo for 30 days to "reset" it....
Re:How can I tell? (Score:5, Funny)
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.
Re: (Score:2)
OMG man, disconnect the cables!!!! NEVER, Skynet will detect that and launch! Joshua already had 8 of the launch codes! you need to make him play tic tac toe, enter zero players!
Re: (Score:2)
Re: (Score:2)
The tangible problem is if you need low latency, or want to maintain the latency you have, when your upstream connection is saturated. At least I think that is what it means.
Re: Cute name, no tangible problem (Score:2, Interesting)
Buffers are not a problem for latency, the growing internet is. Back in the early 2000s from a particular place in Europe to the west coast in US we averaged over 220ms RTT because it was going up to a satellite, landing in Newark and then traveling over 4 hops to the west coast. Around 2003 when we switched to fiber we got down to about 110ms, with the fiber going via two landing stations on the north shore of Africa, then via France via the Atlantic Ocean to Maine (or dalaware) then over land to the west
Re: Cute name, no tangible problem (Score:5, Insightful)
Badly managed buffers are a massive problem for latency. Just look at this graph [blogspot.com] 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.
Re: (Score:3, Interesting)
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
Re: (Score:2)
Re: (Score:2)
The only real way to solve this is to timestamp packets as they enter a buffer and drop the ones that are too old.
You don't have to timestamp them to get the same effect. Codel and RED both effectively use time without timestamping. But yes, the "tracking time" is pretty much the only way.
Bufferbloat? Yes. But... (Score:1)
While bufferbloat was patched out, my router is still under the control of a cargo ship, which claims to actually be an aircraft carrier. What is to be done about blufferboat?
Go measure (Score:2)
Re:Go measure (Score:5, Interesting)
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 [gizmodo.com] 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 [businessinsider.com], of course.
This upload problem may get to be much worse in the future. [ieee.org] 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 [bgr.com] 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.
Re: (Score:3)
And I totally agree that the trendline is to ever more devices doing ever more stuff randomly when you least desire it. We need to have edge routers AND ISPs ready for this change in traffic patterns.
The article you cited was quite good, although it missed completely the outputs of the ietf aqm working group, of which both I and fred baker are members.
https://tools.ietf.org/wg/aqm/ [ietf.org]
Re: (Score:2)
Re: (Score:2)
I see the effects of bufferbloat everyday. As a manager at a small MSP, we have many clients who have large scheduled 'cloud' backups that can saturate the upstream connection. Especially on DSL. Significant reduction of bufferbloat would mean that we could us
Re: (Score:2)
"Dave, I think most of the /. readership is on the eggnog all the time. However, this is the type of thing a few of us still come to this site for. Thanks for your work on this"
I second this.
After the first couple of pages I almost gave up reading because of the eggnog comments.
For the record, queue management in OpenWrt has done a lot to lower bufferbloat on the systems I use.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Forget BB, the plethora of ad-serving sites... (Score:5, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You know, I'd love to use your program and do a comparison between it and a few other ones I use, but I do have a few questions.
Rather than clutter up this forum, drop me a line, let's talk, geek to geek
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Yeah, you'd think the folks at Alphabet (DoubleClick's parent company) would know a thing or two about how to optimize for the Internet.
On the other hand, now DoubleClick knows everything you did on other Alphabet sites, like Google, YouTube, etc.
Re: (Score:2)
I highly recommend DNS based blocking in your router. All smartphones and tablets using your network will also be rid of 99% of all that crap.
There's a package in OpenWRT (not in the main repository, though) that updates blocklists on a schedule (the scripts are very straightforward and DIYable, but it's nice to have a click and go solution):
https://github.com/openwrt/pac... [github.com]
The only downside is that making (temporary) exceptions is not really an option.
Re: (Score:2)
...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!
Two different problems. I don't randomly get ads in the middle of time sensitive UDP packets while video chatting or playing games.
There are two problems we can solve here.
Re: (Score:2)
You really think it's just ads ?
Here is the Bufferbloat demo from 2013:
https://www.youtube.com/watch?... [youtube.com]
More data? (Score:1)
Re:More data? (Score:5, Informative)
Re: (Score:2)
Thank you for such excellent contributions to Linux kernel :-)
Re: (Score:3)
Re: (Score:3)
Re: (Score:1)
You're coming across as rather rude and condescending in your various posts.
As it happens I do kinda understand the problem having run one of the first live commercial IP connections in the UK since it was possible, and for example had to have a word with a small startup called something weird like 'Google' that more connections doesn't equal lower latency either when you are bandwidth constrained (which everyone on the UK was by orders of magnitude more than the US to the bafflement of G's engineers).
So ba
Re: (Score:2)
Re: (Score:2)
That's gracious of you.
I've gone and read a bunch of your work, including blogs, and it is very interesting and definitely a public good if you pull it off, thank you.
I like smart distributed algorithms.
I am still baffled from an afternoon's reading round the subject if to be effective your anti-BB magic has to happen at (nearly) every edge device, or (nearly) every lossy (or speed-mismatched) network gap, or if BB can be fixed by judicious ISP infrastructure deployment, or would cumulatively benefit if mul
Re: (Score:2)
I'm sorry, I tuned out of slashdot after a day.
"I am still baffled from an afternoon's reading round the subject if to be effecitive your anti-BB magic has to happen at (nearly) every edge device, or (nearly) every lossy (or speed-mismatched) network gap, or if BB can be fixed by judicious ISP infrastructure deployment, or would cumulatively benefit if multiple of those happened."
Better queue management everywhere would be good. Your second thought is closest to correct:
"(nearly) ever
Re: More data? (Score:1)
Re: (Score:2)
(and yes, voip is frequently unusable when your ISP link is under stress from something else without out these queue management techniques in place there)
I tried to stress in the lwn article that first eliminating bloa
Re: (Score:3)
Re: More data? (Score:1)
Re: (Score:2)
Re: (Score:3)
You're right, of course. The trouble is, the latency increases aren't reasonable for common consumer networks under load.
Two speedtests I just did on my lightly-loaded hardwired home network (30Mbsp cable from Time Warner):
With QoS [dslreports.com]
Without QoS [dslreports.com]
Throughput is less (rather surprisingly less -- I may want to check some things) with my QoS rules that group connections into individually-throttled categories, but bufferbloat is sane-ish (a brief peak at 250ms was observed, but otherwise under 100ms).
Without QoS, bu
Re: (Score:3)
Re: (Score:2)
I'll need to see your CCNA before I can accept your retort.
Re: (Score:2)
I would like to benchmark more stuff like tomato's qos against cake, the equivalent (single!) command line for outbound would be:
tc qdisc add dev your_device root cake bandwidth 2mbit nat
which automatically applies per host fairness, qos, and queue length management.
inbound requires a slightly more complex setup b
Re: Not magic (Score:2)
I have a spare Asus RT-N16.
Where do I get started with Cake?
Re: (Score:1)
Buffer bloat can't happen without congestion. Congestion is the real problem and talk of buffer bloat is a bit off-point. Sure, if you combat congestion with very large buffers (and hence significant queuing), you get increased latency due to the queuing. Reasonable increase in latency (say 20%) is not a huge hit on performance. Remember that you're trading that extra latency for lower probability of dropped packets.
You're correct that bufferbloat "only happens" when there's traffic. But I don't think you appreciate the current nature of internet traffic.
With web pages averaging 2 megabytes these days, you're "doing large file transfers" all the time. And if your iPhone kicks off an upload of its pictures, or your child starts watching videos, or your spouse starts their own web browsing/mail session, you're at the mercy of your router's queue management algorithm.
I don't think a "20% increase" in latency is reasonable
Re: (Score:2)
Remember that you're trading that extra latency for lower probability of dropped packets.
Not once you've gotten into the "bloated" range of buffer sizes. Increased latency from large buffers also increases the latency to signal to the sender that the route is congested. The sender will spend more time sending packets that will ultimately just get dropped. If the latency was lower, the sender would have known sooner to reduce its rate. Latency and loss go hand-in-hand once you get into unnaturally large buffers. I'm not sure the exact recommend buffer size, but I think it's around 10ms of the ba
Re: Not magic (Score:1)
Buffering is more useful for UDP, and is primarily intended to smooth out transient congestion on a network link or interface.
On a Carrier network, it's used to help deal with bursty traffic... TCP is a rather "slow" response mechanism which works fine in general, but can't handle congestion which comes and goes on millisecond or sub millisecond time scales.
For example, if an ISP has ten 100gig links running in a bundle, and a 1ms duration traffic burst fills one link up, the buffer will soak it up and al
Yes (Score:3)
Now it is after I got my fiber connection it is all gone. My old *DSL connected at 50/10 mbit(errorfree) but I couldn't get anywhere near that(30mbit at most) and latency were way too high. Only place it caused me some problems was when I worked from home and the Citrix connection as I don't play online games.
Re: (Score:1)
Rogers isn't (Score:2)
Re: (Score:2)
No problem here! (Score:3)
Re: (Score:2)
So what OS did you use ? Did you enable fq_codel or similar ?
A testimonial (Score:1)
I've been using CeroWrt ( https://www.bufferbloat.net/projects/cerowrt/wiki/ [bufferbloat.net] - the initial testbed for all of the bufferbloat work) for at least four years. For the majority of that time I had 1.5Mbps DSL service, but now I'm connected via a 12Mbps ADSL2+ link.
Prior to the installation of CeroWrt, it was painful for me to attempt to work remotely using an SSH tunnel if someone was watching a show via Netflix, but after setting up CeroWrt everyone was happy (me for not having to yell at my daughter and my da
HFSC to the rescue (Score:1)
bufferbloat is definitely still a thing.
I've been using this script for years to drop packets early to improve latency. it uses HFSC (built into linux since forever) and works great:
https://gist.github.com/eqhmco... [github.com]
from that:
Congestion avoidance algorithms (such as those found in TCP) do a great job of allowing network endpoints to negotiate transfer rates that maximize a link's bandwidth usage without unduly penalizing any particular stream. This allows bulk transfer streams to use the maximum available ba
No (Score:2)
I have an LTE Verizon Jetpack as my primary Internet connection, and the firmware is proprietary and not user-modifiable, and of course they refuse to implement bufferbloat mitigations on their own. So, no, it's not free from bufferbloat.
Re: (Score:1)
Why the fuck would Tin Man have a woody?
Re: (Score:1)
Steely Dan?
Re: (Score:2)
Maybe in their core, but what happens when they try to fit that traffic down your 10 Mbit/s DSL link? There is going to be a buffer there.
Re: (Score:2)
Re: (Score:2)
Well... I disagree that the "modern internet does not suffer from this problem." I have seen it at my house, and at measurements at many other places. (If you're only considering FTTH as "modern", I have still seen bufferbloat there...)
The ISP does have an opportunity to control buffering in two places: at both ends of the bottleneck (which is likely to be your cable/DSL/FTTH/etc.) link between your house and their facility.
a) Their "head end" gear might control queues for traffic going *to* you
b) Their Cus
Re: (Score:3)
It's pretty much not that at all. It's closer to:
* The provider is selling 100/100 Mbit/s to 20 people with a 1 Gbit/s uplink.
* You hook a WiFi router up to the 100/100 connection.
* While trying to VoIP/Skype on one WiFi device, somebody else starts watching Netflix on another.
* The latency on your WiFi (and thus your VoIP call) jumps up to 50-100ms [cerowrt.org] due to bad buffer management on the WiFi.
* A third device starts trying to sync photos to a backup service, introducing another 100-250ms* [blogspot.com] of latency by tying u
Re: (Score:2)
There are definite peak hours for customer traffic, eg work hours for businesses, and evenings and weekends for home users, so even the very generous 2:1 contention ratio that you seem to be suggesting probably would still result in a saturated backhaul from time to time.
Thus shifting as much discretionary stuff away from that peak as possible will help, just as for power grids, but that's a separate topic.
Rgds
Damon
Re: (Score:2)
It depends on the number of users involved. For this case of 20 users... yeah, you're probably right that you couldn't guarantee no packet loss all of the time, but you would probably get quite close. "It's a weekend" wouldn't be enough to saturate it; even when actively using the internet, most people's bandwidth use is short large spikes surrounded by lots of idle time. Torrents would be a better bet, but maxing out the link would require 10 users torrenting at their max line speed. There are people who w