Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Comment bufferbloat mentioned not once in the article (Score 1) 325

Bloat, yes, bufferbloat, no.

Recently I made a trip to nicaragua and deployed a few fq_codel and cake equipped routers there. The effects were *marvellous*. The kind of total failure to load problems dan describes, in particular, went away.

Still, I'd like to banish those that think IW of greater than 2, TSO and GSO, and 6 simultaneous connections in web browsers - as a good idea - to remote locations for a while, until they learn the errors of their ways.

https://tools.ietf.org/html/dr...

is also a good read.

Comment Re:Using a computer has become a minefield. (Score 1) 498

Hasn't Linus at this point admitted that globally 100% reliable unloading of linux kernel modules is impossible? It can work most of the time but no guarantee that someone else's poorly made module isn't holding a pointer to your kernel memory _somewhere_ no matter how airtight you make yours. Only sure way is to reboot. Unlike say MINIX.
Earth

First Human-Pig 'Chimera' Created in Milestone Study (theguardian.com) 158

Scientists have created a human-pig hybrid in a milestone study that raises the prospect of being able to grow human organs inside animals for use in transplants. From a report: It marks the first time that embryos combining two large, distantly-related species have been produced. The creation of this so-called chimera -- named after the cross-species beast of Greek mythology -- has been hailed as a significant first step towards generating human hearts, livers and kidneys from scratch. Juan Carlos Izpisua Belmonte, who led the work on the part-pig, part-human embryos at the Salk Institute for Biological Studies in La Jolla, California, said: "The ultimate goal is to grow functional and transplantable tissue or organs, but we are far away from that. This is an important first step." The study has reignited ethical concerns that have threatened to overshadow the field's clinical promise. The work inevitably raises the spectre of intelligent animals with humanised brains and also the potential for bizarre hybrid creatures to be accidentally released into the wild. The US National Institutes of Health (NIH) placed a moratorium on funding for the controversial experiments last year while these risks were considered.

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

Slashdot Top Deals

If you fail to plan, plan to fail.

Working...