latency is a function of buffer depth, not a constant
dtaht opened this issue · comments
For example, cable modems have about 7-10ms RTT latency to the head end. DSL is often worse 16ms-30ms depending on interleave.
It is the buffer depth that is what causes the latency under load. And that is something netem doesn't really do "right" - what I typically do is setup a byte fifo on one interface to emulate that, and netem - with a proper emulation for loss and full path delay on the other, with a more correct limit.
If you are going to have a snarky test tool, it would pay to get this part right. Otherwise you aren't going to see #bufferbloat in all it's glory.
I agree, it would be nice to be able to model network conditions more realistically, but I think it would be difficult to build a portable abstraction. You're better off just using the low-level tools at that point. That said, I accept pull requests.
This was never meant to be a "snarky" test tool. In fact, the name was a complete afterthought, for better or worse. I wrote it so I could easily test systems I work on under more extreme conditions. This was something I built entirely for myself and not as a joke. If other people find it useful, great!
The behavior of a fixed 250ms delay is very, very different from a system with 250ms worth of buffer. 250ms worth of buffer ramps up, WAY faster than 250ms delay does.
http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html
I will think about constructing a patch. Have you seen https://github.com/ravinet/mahimahi ? These guys made the opposite mistake in their code, having an infinite buffer.
Again, I don't disagree with you at all, and I actually appreciate your concern considering many others have been seeing this as a joke (hard to blame them—most people don't read the readme). Unfortunately, I just haven't had the bandwidth or the wherewithal to build it into a more compelling tool. That said, the motivation was really more to raise awareness of failure injection as described in my blog post.
I haven't seen mahimahi. Do you have more context for that? The readme is pretty lacking.
I honestly feel that these sorts of changes need to be submitted to the projects responsible for actually affecting the network traffic. (netfilter, ipfw, etc) All this project really does is provide an abstraction to the configuration of said tools using existing technologies. I think that this sort of thing is outside the scope of Comcast.
That being said, if you're aware of a method to more reliably call upon the use of this buffer you mentioned by way of a rule for either netfilter or ipfw, @dtaht, let me know I can I add a configuration rule generation for it.
I have asked my lists to see what they can do to help.
The actual behavior of cable modems is pretty well explored here, in the real world: http://burntchrome.blogspot.co.nz/2014_05_01_archive.html
The above link shows how someone equipped with their own home router and a modern openwrt firmware can vastly improve their cable modem experience.
The cable modem behaviors that are so bad are well known, and the DOCSIS 3.1 standard addresses much of the problem, on the uplink side, but not the downlink side. That, unfortunately, is taking a while to roll out.
http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pdf
And the clearest description of how that works is here: https://tools.ietf.org/html/draft-white-aqm-docsis-pie-02
As for mahimahi, it uses linux containers to create delay, loss, and so on, in a very nice, flexible manner (but as I said, they too got their FIFO design wrong, being infinite. They have a codel patch in a branch that I keep meaning to get around to fixing up, but it would be nice if they had a fixed length byte fifo built into their code also)
and I feel your pain, regarding the snark. Far too many people have the ability to criticise, and far too few, seemingly, the ability or time to do something constructive. Keep at it! The publicity will die down, and hopefully your tool and concerns as you expressed on your blog http://www.bravenewgeek.com/sometimes-kill-9-isnt-enough/ will be understood and addressed by more people that can do constructive things. Eventually.