I was reading the latest article in LWN, and commented there, but part of the comment may be relevant to the list...
-- reply to mlankhorst (subscriber, #52260) -- Changing the subject slightly, there's a subtle, underlying problem in that when developing products and protocols, 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 at the time. We work with buffer sizes because that's dead easy. What we need instead is to work in 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 unintelligible (;-)) --dave ([email protected]) c-b -- As you might guess, I'm a capacity planner, and might be able to help a bit on the modeling side. Besides, I'm looking for a networking example for my next book (;-)) --dave _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
