Recent Features
| |||||||||||||
Power impact of debufferbloatingPower impact of debufferbloatingPosted Sep 13, 2011 21:37 UTC (Tue) by njs (guest, #40338)In reply to: Power impact of debufferbloating by njs Parent article: LPC: An update on bufferbloat
...Also I should add that the above is very much talking about the long-term ideal architecture. Right now IIUC everyone's still focusing on figuring out how to make buffers smaller without killing throughput. I think this is basically the wrong question -- we're going to want big buffers anyway -- but no-one's even thinking about power consumption yet AFAICT.
And in the long run, packets will be dropped intelligently according to some control law that tries to maintain fairness and provide useful feedback to senders (i.e., AQM). For now we mostly use the "drop packets when the buffer overflows" rule, which is a terrible control law, but may be less terrible with small buffers than large ones.
So in the long run buffer size doesn't matter, but in the short run it's a single knob that's coupled to a ton of theoretically unrelated issues, and decoupling it is going to be a pain.
(Log in to post comments)
Power impact of debufferbloating Posted Sep 13, 2011 21:55 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
one thing here, the main focus of the bufferbloat project is not the endpoint application, it's the routers in the middle of the path.
to a small extent, the IP stack on your endpoint device can be considered such a router as it aggregates the traffic from all your applications, but the biggest problem of large buffers is where you transition from a fast network to a slow one.
in many cases this is going from the high speed local network in someone's house to the slow DSL link to their ISP
I also think that you are mistaken if you think that any computers send a large number of packets to the network device and then shift to a low power state while the packets are being transmitted. usually shifting to such a low power state ends up powering off the network device as well.
servers almost never do something like this because as soon as they are done working on one request, they start working on another one.
shifting power states is a slow and power hungry process, it's not done frequently and on reasonably busy servers seldom takes place
Power impact of debufferbloating Posted Sep 13, 2011 21:59 UTC (Tue) by arjan (subscriber, #36785) [Link]
I completely disagree with your last statement.
Servers run C states ALL THE TIME.... and often are "only" 50% to 80% utilized.... and not 10% is no exception either...
Power impact of debufferbloating Posted Sep 13, 2011 22:59 UTC (Tue) by jg (subscriber, #17537) [Link]
It's currently multiple knobs to twist... Sometimes the drivers even lack the knob one might want to twist. Not good.
It isn't clear that the current network stack buffering architecture in Linux is what it needs to be (in fact, pretty clear it needs some serious surgery; and I'm not the person to say what it really needs to be).
Ultimately, we need AQM *everywhere* that "just works". Right now we don't have an algorithm that is known to fit this description.
And yes, I'm very aware that power management folds into this; I've worked on iPAQ's as you may or may not remember, from which other hand held Linux devices were at least inspired.
Lots of interesting work to do...
|
|||||||||||||