<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 1:04 PM, Jonathan Morton <<a href="mailto:chromatix99@gmail.com" class="">chromatix99@gmail.com</a>> wrote:</div><div class=""><p dir="ltr" class="">My pet suggestion here is to represent latency as its inverse, "responsiveness" with units of Hz. This has the dual advantages of bigger numbers being better, and the figures being directly comparable with framerates.</p><p dir="ltr" class="">As you say, the methodology will need to be very carefully specified, so that we get a meaningful measurement that's hard to game.</p></div></blockquote></div>I like that idea...<div class=""><br class=""></div><div class="">Then it’s how to measure it. 1 / latency where latency is what…the maximum value you’ll see considering all traffic as besteffort at a fixed number of concurrent flows? Otherwise it would have do be expressed differently for different traffic classes, which is probably already too complicated for most people.</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><div class="">Food for thought, I know this is the opposite direction, but I’ve always liked in Europe how car “mileage” is expressed as consumption (L/100km) instead of efficiency (miles/gallon). Yes, then a lower number is better, but it’s easier to calculate how much gas you’ll use for a given trip.</div></div></div></div></body></html>