Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Networking Linux

Got (Buffer) Bloat? 121

mtaht writes, "After a very intense month of development, the Bufferbloat project has announced the debloat-testing git kernel tree, featuring (via suggestion of Van Jacobson) a wireless network latency smashing algorithm, (called eBDP), the SFB and CHOKe packet schedulers, and a slew of driver level fixes that reduce network latency across the Linux kernel by over 2 orders of magnitude. Got Bloat?"
This discussion has been archived. No new comments can be posted.

Got (Buffer) Bloat?

Comments Filter:
  • by MichaelSmith ( 789609 ) on Saturday February 26, 2011 @07:13AM (#35322668) Homepage Journal

    high latency that can occur in modern network connections due to large buffers in the network

    Nobody ever explained this to me but I was using ping to measure latency on a network where I was actually most interested in ssh. Ping times went something like 10ms, 50ms, 90ms, 130ms... up to about 500ms, then started again at 10ms, 50ms and so on. Maybe some of my pings shared a buffer with a large, periodic data transfer and when that transfer filled a buffer somewhere my latency dropped.

    I am pretty sure the people actually operating the WAN in question had no idea what was going on either.

  • by Lennie ( 16154 ) on Saturday February 26, 2011 @07:36AM (#35322720)

    It is about reducing latency. So it helps prevent problems with VoIP failing when there is a lot of other data flowing over the same connection(s).

    Some buffers are really large and it turns out some introduce latency of several seconds (!).

  • by Colin Smith ( 2679 ) on Saturday February 26, 2011 @07:40AM (#35322730)

    A lot of our problems today would not be here if.

    OSI stack instead of TCP/IP.
    DCE & DFS instead of passwd/whatever + the bastard abomination which is NFS.

    Meh. People are lazy and cheap. Free with the network effect always wins. The Lowest Common Denominator. It's going to take another 15 years before we are near where we were 15 years ago. But this time it will be in Java!
     

  • by Kjella ( 173770 ) on Saturday February 26, 2011 @08:01AM (#35322776) Homepage

    Most network throughput is at least 80-90% efficient already, so it won't get much faster. It will make it more responsive though, which is good if you're browsing the web, playing an online game or something else interactive.

    I assume this is under load though, because on ping there's not much to be saved. On local sites I have 8-12 ms ping, on slashdot I have 140-150 ms. Since the theoretical round trip in a straight line at light speed is some 110 ms, there's not even room for a 50 ms drop. A lot of weirdness can happen under load though if stuff gets buffered up various places.

  • by tepples ( 727027 ) <tepples@gmai l . com> on Saturday February 26, 2011 @11:12AM (#35323538) Homepage Journal

    You further penalize the endpoint by cutting it down to 56k modem speeds for a month if you see it making too many short-lived (<5s) connections to multiple IPs and declaring them isoch. By definition, any such connections are an abuse of the standard.

    But isn't that exactly how channel surfing would work on IP-based television?

"Life begins when you can spend your spare time programming instead of watching television." -- Cal Keegan

Working...