Time, not bandwidth/delay, is the key
Posted Sep 14, 2011 14:53 UTC (Wed) by davecb
In reply to: At the very least Gettys got a wicked T-shirt.
Parent article: LPC: An update on bufferbloat
Some practical suggestions will be much appreciated.
Changing the subject slightly, there's a subtle, underlying problem in that we tend to work with what's easy, not what's important.
We work with the bandwidth/delay product because it's what we needed in the short run, and we probably couldn't predict we'd need something more ta the time. We work with buffer sizes because that's dead easy.
What we need is the delay, latency and/or service time of the various components. It's easy to deal with performance problems that are stated in time units and are fixed by varying the times things take. It's insanely hard to deal with performance problems when all we know is a volume in bytes. It's a bit like measuring the performance of large versus small cargo containers when you don't know if they're on a truck, a train or a ship!
If you expose any time-based metrics or tuneables in your investigation, please highlight them. Anything that looks like delay or latency would be seriously cool.
One needs very little to analyze this class of problems. Knowing the service time of a packet, the number of packets, and the time between packets is sufficient to build a tiny little mathematical model of the thing you measured. From the model you can then predict what happens when you improve or disimprove the system. More information allows for more predictive models, of course, and eventually to my mathie friends becoming completely unintelligable (;-))
--dave (firstname.lastname@example.org) c-b
to post comments)