Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:More data? (Score 1) 147

Dear Damon:
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) every lossy (or speed-mismatched) network gap" needs better queue management. That's a LOT (billions) of devices. The thing is, the queue management problem was known well before 1992, it's just that RED did not deploy very well, and FQ techniques were often kept as secret sauce. Things got out of hand as speeds went up and the potential speed mismatch variance between links went to 6 orders of magnitude, since 1992.
I (we) fully realize that the scope (billions of machines/year) of sticking solutions everywhere is hard, but it is never too late to start, (b and replacing dumb overbuffered fifos everywere with a couple hundred lines of code - considering the millions elsewhere seems simple!) and we've pursued developing an easily deployable solution (fq_codel primarily), as well as standardization efforts (ietf aqm working group). Things like systemd default to fq_codel, so do most third party linux router firmwares.
About the only major thing left (since fixing wifi) is actually getting this stuff into hardware and "big iron" like cmtss and BRASes.
... On devices themselves, we've worked on ripping out excessive buffering throughout the stack (BQL, things like TCP_NOTSENT_LOWAT (now the default in OSX), most recently pacing via the sch_fq qdisc and "TCP BBR") so that the tcp's and applications (mostly linux, but increasingly BSD), are not storing crazy amounts of data internally. There's been a lot of other changes, all my talks include a slide on the higher levels of stack and application issues.
... IF you have enough capacity, you don't see BB (except for microbursts, which couldbe quite bad before we started moderating TSO/GSO/GRO bursts). Certainly the core and a well designed infrastructure that never saturates removes the issue (except when it does happen!)
... At some point I need to sit down and write something definitive, instead of this vapor trail of 6 years worth of work all over all the gear and all of the stack(s).
-- Dave TÃht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org/

Comment Re: More data? (Score 2) 147

Many enterprise APs are pretty good, btw - and while I have not tested the current crop of stuff from eero, and google and so on, I'm pretty sure they've been paying attention to the work. (portions of the make-wifi-fast project were funded both by google and comcast research) So I hope you've been making your stuff great in the first place, and not having to deal with paying off all the technical debt we've been paying off here: https://docs.google.com/docume... But please go test for the things we are testing for and fixing!

Comment Re: More data? (Score 1) 147

These are "latency under load" measurements (using the dslreports and flent tools to stress out your link). If your network is otherwise idle voip is fine, but with people adding ever more devices to their network doing random things at random times, the bloat problem raises its ugly head.
(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 bloat from the ISP link will make your wifi a lot better, because wifi is usually not the bottleneck in many scenarios. But: the wifi work we just pushed upstream makes voip far more possible when wifi is contended.
Is it limited to linux? No - it seems to be deeply affecting the current crop of gateways supplied by ISPs, as well as nearly the entire 3rd party router market, except those who are deploying qos sanely (which is nearly everybody these days in third party firmware - "fq_codel" lies underneath many a rebranded qos system nowadays. "cake" is a possible successor.
The frustrating part is that wifi folk are often saying their stuff is fine, when it can be so deeply affected by the next hop up, and also tends to become poor anytime a second or third device is stressing the link (transferring files to a NAS, for example, screensharing for another). 802.11ac devices tend to have more latency than 802.11n, also, because they tend to use a fixed buffer size suitable for their highest rates, and not something that adjusts to the actual rate.
If you are interested in poking into these issues further, on your equipment, take a look at flent, and/or come on over for the discussions on the make-wifi-fast mailing list.

Comment Re:Not magic (Score 1) 147

Nice success story and the exact circumstances we were trying to make easier to solve with cake. (and the dream is more ISPs would just be doing it for you on their default supplied boxes)
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 but not much.

Comment Re:Go measure (Score 2) 147

I am not huge on basic web tests, preferring the finer grained results we get from flent. (https://flent.org).
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/

Comment Re:Nagle algorithm? (Score 5, Informative) 147

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.

Comment Re:More data? (Score 4, Informative) 147

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....

Comment Go measure (Score 1) 147

Judging from the first 25 replies, the slashdot readership is suffering from an overdose of eggnog. Here's a link (which has links to results from every ISP), which shows latency under load often measured in seconds. http://www.dslreports.com/spee... The problem with this survey is that there are now plenty of folk that get sub-30ms latencies on their internet - which is what those using bufferbloat fixes get, and the question was if you or your isp was driving improved hardware to get those results. Problem seems to be 99% of the results are worse than that, still, 4+ years after the code to fix first arrived in Linux.

Slashdot Top Deals

"For a male and female to live continuously together is... biologically speaking, an extremely unnatural condition." -- Robert Briffault

Working...