Please create an account to participate in the Slashdot moderation system


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Networking Linux

Got (Buffer) Bloat? 121

Posted by Roblimo
from the good-buffering-is-better-than-licking-a-cake-batter-bowl dept.
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:
  • what it is (Score:1, Insightful)

    by leaen (987954) on Saturday February 26, 2011 @06:37AM (#35322566)
    It is good to write in summary what program nobody hear before actually do
  • Re:what it is (Score:5, Insightful)

    by TheLink (130905) on Saturday February 26, 2011 @08:06AM (#35322796) Journal
    IMO it's fine for buffers to be very big.

    What routers should do is keep track of how long packets have been in the router (in milliseconds or even microseconds) and use that with QoS stuff (and maybe some heuristics) to figure out which packets to send first, or to drop.

    For example, "bulk/throughput" packets might be kept around for hundreds of milliseconds, but while latency sensitive packets get priority they are dropped if they cannot be sent within tens of milliseconds (then the sender will faster realize that it should slow down).
  • Re:what it is (Score:3, Insightful)

    by Brian Feldman (350) <> on Saturday February 26, 2011 @09:47AM (#35323132)

    That's a much more complex solution than "don't buffer so much damn stuff for no good reason."

  • Latency again (Score:4, Insightful)

    by Twinbee (767046) on Saturday February 26, 2011 @10:14AM (#35323258) Homepage

    I've seen it time and time again, people just generally don't care about latency, or even deny it exists in many cases (buffer bloat is certainly one cause of latency).

    Everything from changing channel on your TV remote, to a mobile phone number entry, to the frame delays you get from LCD monitors, to the soundcard delay, to the GUI widgets you click on;......... it's all over the place, and it can wreck the experience, or reduce it somewhat according to how big the delay is. Just because latency is harder to measure, that doesn't mean it isn't very important, especially when it builds up with lots of other 'tiny' delays to make one big delay.

  • Re:Latency again (Score:4, Insightful)

    by mtaht (603670) on Saturday February 26, 2011 @12:00PM (#35323796) Homepage
    "The bulk of Internet traffic in the US these days is streaming video. For that you need big bandwidth and big buffers, not low latency. " Emphatically not true. ESPECIALLY for streaming video, you need a functioning feedback mechanism (tcp acks or ECN or some other mechanism) to slow down the video periodically, so that it *doesn't* overflow what buffers you have, and catastrophically drop all the packets in the queue, resulting in stuttering video.

The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft.