[Bloat] COTS router with OpenWrt

[Bloat] COTS router with OpenWrt

[Rich Brown]

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.

Re: [Bloat] COTS router with OpenWrt

[Jonathan Foulkes]

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.
> 
> 

Re: [Bloat] COTS router with OpenWrt

[Jonathan Morton]

> On 26 Nov, 2016, at 16:08, Rich Brown <richb.hanover@gmail.com> wrote:
> 
> 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.

Excellent.

He’s using DSLreports for the quality testing, which is always a good sign.  After turning off my webcache, I get a nice “A” grade over here while running through my custom Cake setup, and a big fat “F” grade with Cake turned off.  Just as it should be, given my connection.

With the webcache left on, though, I just get errors, not results.  That might be something to get fixed.

I think we can rally around this device, if it works as well as advertised (and it should).  I know of a handful of well-placed people who could potentially try out and endorse it, but I would like to see some of us trying it out before I involve them.

 - Jonathan Morton

Re: [Bloat] COTS router with OpenWrt

[Jonathan Foulkes]

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.
> 
> 

Re: [Bloat] COTS router with OpenWrt

[Dave Taht]

On Mon, Nov 28, 2016 at 7:21 AM, Jonathan Foulkes
<JF@jonathanfoulkes.com> 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 hope that your marketing campaign is being successful on these
fronts. It has always been my goal to "enable better products", but
not have the headache of making them myself, where 99.99% of the
effort is (like in cerowrt), in making everything else "just work" and
be reliable enough to ship.

>
> I look forward to participating more actively on this list.

One of my thoughts has been since it has become so difficult in the
USA for an open source organization to achieve 501c3 status (icei.org
is now 5 years into their attempt) was to go the 501c6 route, like the
linux foundation. We now have a reasonable set of companies doing the
right things for queueing, updates, and so on, that perhaps banding
together to promote "less lag, regular updates" would be a way to
support some of the other costs of this effort, such as effective
outreach.

>
> 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.
>>
>>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org

Re: [Bloat] COTS router with OpenWrt

[Jonathan Foulkes]

Hi Dave, a special thanks to you for all the cheerleading and pushing you do on this topic.

> I hope that your marketing campaign is being successful on these
> fronts. It has always been my goal to "enable better products", but
> not have the headache of making them myself, where 99.99% of the
> effort is (like in cerowrt), in making everything else "just work" and
> be reliable enough to ship.


I haven’t ramped up the marketing in a big way yet, but what I am doing is quite effective (e.g. click through metrics are 5 to 10x the norm); what’s been most astonishing is the word of mouth spread.

Yes, lots of effort in having a reliable, supportable product. 

As you can see from the site, my messaging has been focused on regular end users, using terminology they can hopefully grasp (I get accused of both being too technical and not technical enough, so maybe I got it right ;-)

One area of messaging that I believe members of this list could provide input on is around how to get people to understand that ‘speed’ (line capacity) is not everything. I keep looking for ways to address that and wrote a short post on it: http://evenroute.com/the-last-50-feet/quick-vs-fast

I’ll post more thoughts on the other thread you started.

- Jonathan

> On Nov 28, 2016, at 10:57 AM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Mon, Nov 28, 2016 at 7:21 AM, Jonathan Foulkes
> <JF@jonathanfoulkes.com> 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 hope that your marketing campaign is being successful on these
> fronts. It has always been my goal to "enable better products", but
> not have the headache of making them myself, where 99.99% of the
> effort is (like in cerowrt), in making everything else "just work" and
> be reliable enough to ship.
> 
>> 
>> I look forward to participating more actively on this list.
> 
> One of my thoughts has been since it has become so difficult in the
> USA for an open source organization to achieve 501c3 status (icei.org
> is now 5 years into their attempt) was to go the 501c6 route, like the
> linux foundation. We now have a reasonable set of companies doing the
> right things for queueing, updates, and so on, that perhaps banding
> together to promote "less lag, regular updates" would be a way to
> support some of the other costs of this effort, such as effective
> outreach.
> 
>> 
>> 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.
>>> 
>>> 
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> 
> -- 
> Dave Täht
> Let's go make home routers and wifi faster! With better software!
> http://blog.cerowrt.org

Re: [Bloat] COTS router with OpenWrt

[Toke Høiland-Jørgensen]

Jonathan Foulkes <jf@jonathanfoulkes.com> writes:

> Hi Dave, a special thanks to you for all the cheerleading and pushing you do on this topic.
>
>> I hope that your marketing campaign is being successful on these
>> fronts. It has always been my goal to "enable better products", but
>> not have the headache of making them myself, where 99.99% of the
>> effort is (like in cerowrt), in making everything else "just work" and
>> be reliable enough to ship.
>
> I haven’t ramped up the marketing in a big way yet, but what I am
> doing is quite effective (e.g. click through metrics are 5 to 10x the
> norm); what’s been most astonishing is the word of mouth spread.
>
> Yes, lots of effort in having a reliable, supportable product. 
>
> As you can see from the site, my messaging has been focused on regular
> end users, using terminology they can hopefully grasp (I get accused
> of both being too technical and not technical enough, so maybe I got
> it right ;-)
>
> One area of messaging that I believe members of this list could
> provide input on is around how to get people to understand that
> ‘speed’ (line capacity) is not everything. I keep looking for ways to
> address that and wrote a short post on it:
> http://evenroute.com/the-last-50-feet/quick-vs-fast

Well, there's Stuart's classic rant from two decades ago (which is on
the technical side):
http://www.stuartcheshire.org/rants/Latency.html

On the less technical side, there's this video from the RITE project:
https://www.youtube.com/watch?v=F1a-eMF9xdY

And this one that nicely showcases latency, but then draws the wrong
conclusion (that you need more bandwidth to fix it):
https://www.youtube.com/watch?v=_fNp37zFn9Q

-Toke

[Bloat] How to "sell" improvement (was: COTS router with OpenWrt)

[David Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

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.
>>
>>
> _______________________________________________
> 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


[-- Attachment #2: Type: text/html, Size: 3706 bytes --]

Re: [Bloat] How to "sell" improvement

[Kathleen Nichols]

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.
>>> 
>>> 
>> _______________________________________________ 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
> 
> 
> 
> _______________________________________________ Bloat mailing list 
> Bloat@lists.bufferbloat.net 
> https://lists.bufferbloat.net/listinfo/bloat
> 

Re: [Bloat] How to "sell" improvement

[David Collier-Brown]

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.
>>>>
>>>>
>>> _______________________________________________ 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
>>
>>
>>
>> _______________________________________________ Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>>
> _______________________________________________
> 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

Re: [Bloat] How to "sell" improvement

[Simon Barber]

Web page load time.

Simon

> 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.
>>>>> 
>>>>> 
>>>> _______________________________________________ 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
>>> 
>>> 
>>> 
>>> _______________________________________________ Bloat mailing list
>>> Bloat@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/bloat
>>> 
>> _______________________________________________
>> 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
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] How to "sell" improvement

[David Collier-Brown]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

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:
> Web page load time.
>
> Simon
>
>> 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.
>>>>>>
>>>>>>
>>>>> _______________________________________________ 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
>>>>
>>>>
>>>>
>>>> _______________________________________________ Bloat mailing list
>>>> Bloat@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/bloat
>>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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


[-- Attachment #2: Type: text/html, Size: 6743 bytes --]

Re: [Bloat] How to "sell" improvement

[Jonathan Morton]

> On 28 Nov, 2016, at 20:37, David Collier-Brown <davec-b@rogers.com> wrote:
> 
> 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"

This is a useful set of definitions, though I would quibble that “transfer time” should also be measured from the request, not from the first response.

A more complete picture would add a measure of application-induced delay, which is visible to the user but not necessarily to the network.  It is influenced mainly by the end host's performance, not by anything in the network, and would presumably count as part of the “think time” for many applications.  Hence it’s not relevant for *our* objectives, but might be to others.

Incidentally, did anyone notice that Intel revived their old “optimised for the Internet” marketing fluff for their new Kaby Lake CPUs?  Last seen for the Pentium III, and just as disingenuous.

 - Jonathan Morton

Re: [Bloat] How to "sell" improvement

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 898 bytes --]

On Mon, 28 Nov 2016, David Collier-Brown wrote:

> 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...

First off, can we get people to nominate candidate pages?

Then, let's see if we can make a simulator for that page, so the test won't 
break when the website gets updated, something that has the same serialization 
issues hitting multiple sites and fetching a bunch of items of various sizes 
(ideally, but not neccessarily involving slight delays on the server before 
returning the objexts)

turn this test into a apache module so it's easy to use and isn't affected by 
system variations (and eliminates possible security risks by having the module 
not access anything on the system)

Then get this deployed a bunch of places.

David Lang

[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] How to "sell" improvement

[David Collier-Brown]

On 28/11/16 02:26 PM, Jonathan Morton wrote:
>> On 28 Nov, 2016, at 20:37, David Collier-Brown <davec-b@rogers.com> wrote:
>>
>> 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"
> This is a useful set of definitions, though I would quibble that “transfer time” should also be measured from the request, not from the first response.
Latency + Transfer Time add up to make "Response Time", which is from 
very beginning to very end, as you note.

>
> A more complete picture would add a measure of application-induced delay, which is visible to the user but not necessarily to the network.  It is influenced mainly by the end host's performance, not by anything in the network, and would presumably count as part of the “think time” for many applications.  Hence it’s not relevant for *our* objectives, but might be to others.
The response also breaks down into queue delay and service time, which 
don't line up with the latency/transfer split.  Service time is the time 
a warm system takes to process one request-response pair, while delay is 
the time spent waiting for the cache to load, stuff get read from disk 
and, especially especially, the time sitting in the run-queue, twiddling 
your thumbs, waiting for a CPU.

Those aren't easily measured from outside the system, although I've 
approximated them with a stepping load test. They're easy to measure 
in-app, though.
>
> Incidentally, did anyone notice that Intel revived their old “optimised for the Internet” marketing fluff for their new Kaby Lake CPUs?  Last seen for the Pentium III, and just as disingenuous.
>
>   - Jonathan Morton
>
>
"Intel inside" is a warning label (;-))

--dave


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

Re: [Bloat] How to "sell" improvement

[Jonathan Foulkes]

Hear, hear, the concept of having ‘simulators’ for typical heavy modern web pages is exactly what we need to get across the benefits of lowered bloat having a larger impact on page-load performance than ‘speed’.
Those simulated pages should report total page load time and maybe even how many objects we’re ‘missed’ due to bloat induced issues.

These sites can then be recorded as they perform on various types of lines and bloat and allow for a really impactful before/after video to be produced.

Here are my suggestions for candidate ‘sites’:

News Site front page, with mix of uniquely fetched text areas and images. Also, dozens of ad-like payloads sourced from multiple domains.
News ‘content’ can actually be a bunch of educational material on Bloat, why waste an opportunity to further the message ;-)

Shopping site with tons of images and other smaller payloads, generating >300 requests.
Again, content can be designed to further our message.

What do we need to do to move this forward?

I have an experienced graphic designer and web-master that I can direct to help with some of the content and creative work. 
But what we need first is some agreement on general scope and then a technical framework to achieve the desired outcome.

Cheers,

Jonathan


> On Nov 28, 2016, at 2:40 PM, David Lang <david@lang.hm> wrote:
> 
> On Mon, 28 Nov 2016, David Collier-Brown wrote:
> 
>> 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...
> 
> First off, can we get people to nominate candidate pages?
> 
> Then, let's see if we can make a simulator for that page, so the test won't break when the website gets updated, something that has the same serialization issues hitting multiple sites and fetching a bunch of items of various sizes (ideally, but not neccessarily involving slight delays on the server before returning the objexts)
> 
> turn this test into a apache module so it's easy to use and isn't affected by system variations (and eliminates possible security risks by having the module not access anything on the system)
> 
> Then get this deployed a bunch of places.
> 
> David Lang_______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] How to "sell" improvement

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

On Sun, 4 Dec 2016, Jonathan Foulkes wrote:

> Hear, hear, the concept of having ‘simulators’ for typical heavy modern web pages is exactly what we need to get across the benefits of lowered bloat having a larger impact on page-load performance than ‘speed’.
> Those simulated pages should report total page load time and maybe even how many objects we’re ‘missed’ due to bloat induced issues.
>
> These sites can then be recorded as they perform on various types of lines and bloat and allow for a really impactful before/after video to be produced.
>
> Here are my suggestions for candidate ‘sites’:
>
> News Site front page, with mix of uniquely fetched text areas and images. Also, dozens of ad-like payloads sourced from multiple domains.
> News ‘content’ can actually be a bunch of educational material on Bloat, why waste an opportunity to further the message ;-)
>
> Shopping site with tons of images and other smaller payloads, generating >300 requests.
> Again, content can be designed to further our message.
>
> What do we need to do to move this forward?

I think the first step is to get some sample measurements from some sample 
sites.

how many objects of what size are fetched taking how long (possibly in what 
order, i.e. fetch javascript libraries and then javascript fetches other stuff)

I think we want to create gant-chart like diagrams of the page loads.

once we have that, we can create the simulated pages, but before we have this 
sort of info, we don't know what to create.

Is there any off-the-shelf tool we can use to measure this? perhapse some web 
proxy software?

> I have an experienced graphic designer and web-master that I can direct to help with some of the content and creative work.
> But what we need first is some agreement on general scope and then a technical framework to achieve the desired outcome.

I think we first need to get it working with dummy data and then let your 
graphic designer at it to make the content useful to us.

David Lang

> Cheers,
>
> Jonathan
>
>
>> On Nov 28, 2016, at 2:40 PM, David Lang <david@lang.hm> wrote:
>>
>> On Mon, 28 Nov 2016, David Collier-Brown wrote:
>>
>>> 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...
>>
>> First off, can we get people to nominate candidate pages?
>>
>> Then, let's see if we can make a simulator for that page, so the test won't break when the website gets updated, something that has the same serialization issues hitting multiple sites and fetching a bunch of items of various sizes (ideally, but not neccessarily involving slight delays on the server before returning the objexts)
>>
>> turn this test into a apache module so it's easy to use and isn't affected by system variations (and eliminates possible security risks by having the module not access anything on the system)
>>
>> Then get this deployed a bunch of places.
>>
>> David Lang_______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>