Slashdot Mirror

re:"Interesting problem for dd-wrt"

Agreed.
We are throwing efforts at both the mainline kernel and openwrt.
Openwrt is foundational for dd-wrt and several other (commercial) distributions of Linux on the router. I have a large set of debloated routers already, I'm just awaiting further work on the eBDP algorithm to make better....

http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_Bloated_LAGN_vs_debloated_WNDR5700

re: "using pings"
httpping is a much saner approach than ping, in many cases. Get it from:

http://www.vanheusden.com/httping/

re: RED & AQM

SFB and CHOKEe are in the debloat-testing kernel, as is eBDP.
RED 93 isn't going to work. nRED may. Experimentation and scripts highly desired. See the bloat and bloat-devel mailing lists for discussions.

Also:

http://www.bufferbloat.net/projects/bloat/wiki/Dogfood_Principle

Also:

I've seen some VERY interesting behavior with tcp vegas over bloated connections.

http://www.bufferbloat.net/projects/bloat/wiki/Experiment_-_TCP_cubic_vs_TCP_vegas

I think you are referring to an early draft of an article by Eric Raymond, which was wildly incorrect on this point, which was thoroughly discussed on the bloat mailing list. See the incredibly long thread starting at: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html There is a newer, fully corrected piece coming out soon. In the meantime, consider the words of Van Jacobson, Vint Cerf, and others. Carefully. https://lists.bufferbloat.net/pipermail/bloat/2011-February/000108.html http://www.bufferbloat.net/projects/bloat/wiki/Quotes

I think you are referring to an early draft of an article by Eric Raymond, which was wildly incorrect on this point, which was thoroughly discussed on the bloat mailing list. See the incredibly long thread starting at: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html There is a newer, fully corrected piece coming out soon. In the meantime, consider the words of Van Jacobson, Vint Cerf, and others. Carefully. https://lists.bufferbloat.net/pipermail/bloat/2011-February/000108.html http://www.bufferbloat.net/projects/bloat/wiki/Quotes

I think you are referring to an early draft of an article by Eric Raymond, which was wildly incorrect on this point, which was thoroughly discussed on the bloat mailing list. See the incredibly long thread starting at: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html There is a newer, fully corrected piece coming out soon. In the meantime, consider the words of Van Jacobson, Vint Cerf, and others. Carefully. https://lists.bufferbloat.net/pipermail/bloat/2011-February/000108.html http://www.bufferbloat.net/projects/bloat/wiki/Quotes

oh, that was a wonderful parody of an already wonderful parody. Thanks for that. I'd probably modify it a little bit for accuracy, if you'd let me paste a copy over to our humor page? http://www.bufferbloat.net/projects/bloat/wiki/Humor The bufferbloat problem is so big - in hundreds of millions of devices today and millions more in the pipeline, that if we didn't laugh sometimes, we'd explode.

oblig. car analogy, by Eric Raymond no less:
    https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html

== Packets on the Highway ==

To fix bufferbloat, you first have to understand it. Start by
imagining cars traveling down an imaginary road. They're trying to get
from one end to the other as fast as possible, so they travel nearly
bumper to bumper at the road's highest safe speed.
[snipped]

I should have also linked to a definition of bufferbloat by Jim Gettys. For the curious here's a page of links to bufferbloat resources and a 5 minute animation that shows the impact of large buffers on network communication (.avi).

I should have also linked to a definition of bufferbloat by Jim Gettys. For the curious here's a page of links to bufferbloat resources and a 5 minute animation that shows the impact of large buffers on network communication (.avi).

this explains it: https://lists.bufferbloat.net/pipermail/bloat/2011-February/000050.html