Yes, especially for

the performance-reporting tools' own page and also for
some well-known, moderately complex ones.

Not the minimalist Google front page, but perhaps a particular query...

--dave

On 28/11/16 01:58 PM, Simon Barber wrote:

On Nov 28, 2016, at 10:37 AM, David Collier-Brown <davec-b@rogers.com> wrote: In this context, I'd say latency and the effect of bloat reduction on it and transfer time. Dave Taht can say much more (;-)) I'm just echoing his concern, from the point of view of a capacity planner. --dave c-b [I'm using latency as the time from the request to the first response, transfer time as the time from the first response to the last response, which may be 0, and sleep/think time as the time from the last response to the next request, for a given stream of requests and responses, AKA "transactions"] On 28/11/16 12:59 PM, Kathleen Nichols wrote:

That's a good idea in general, but what are you measuring for your "actual performance"? Raw throughput? Goodput (which requires a bit of processing)? Then what about delay? On 11/28/16 9:41 AM, David Collier-Brown wrote:

Put the speed-test /into the router/, with a big red button to turn fq_codel on and off. * The performance reporting graphs can then run on a browser page for as long as you like, while you do other things, and go back to the page and see what it's been like. * Have a line for "perfect" performance, and anyone can see how close you're system is coming to it. * Have a button for a synthetic load test, of some shortish duration, and, * Put it on normal Linux hosts too, so you can test end-to-end. This has the advantage that it's code-first, so you don't have to convince the uninterested, and from it you can write a small and limited RFC to tell everyone else how you did it. As each new improvement comes along, actual performance slowly gets closer and closer to the optimal performance line... --dave On 28/11/16 10:21 AM, Jonathan Foulkes wrote:

Thanks for the Introduction Rich, and thanks again to you and many others on this list for all your contributions over the years helping to combat bloat. This product was born of my own frustration with finding a way to help neighbors and family get a simple off-the-shelf solution that even non-technical users can deploy. I look forward to participating more actively on this list. Jonathan

On Nov 26, 2016, at 9:08 AM, Rich Brown <richb.hanover@gmail.com> wrote: I have been exchanging a few emails with Jonathan Foulkes from evenroute.com. He tells me that his company is installing OpenWrt on a commercial, off the shelf (COTS) TP-Link router and selling them on commercially. His "secret sauce" is an auto-update facility and improved setup software, which includes a rate-detection step that operates continually to adjust the fq_codel parameters to the actual line rate. You can take a look at IQrouter.com, or look them up on Amazon. This might be a solution to our current conundrum about not having an easy solution that solves our family's networking problem. I'm going to get one of these and try it out. He has been following our bufferbloat and make-fifi-fast work closely, as well as the work on LEDE, which he'll consider once it hits a stable point. I have invited him to join this list. Welcome, Jonathan.

-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat

-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain