* [Cake] cake work needed for openwrt merge
@ 2015-09-06 22:35 Dave Taht
2015-09-07 7:35 ` Sebastian Moeller
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Dave Taht @ 2015-09-06 22:35 UTC (permalink / raw)
To: cake, Felix Fietkau
In discussing with felix what is needed for cake to go into openwrt
trunk, we came up with the following list:
* Cake work needed
** Add squash option (besteffort + squashing diffserv)
** Fix diffserv
** Add man page
** Clean up patches to only do cake
*** Reformat for kernel_style
*** IProute patches for mainline iproute
** Submit as a single patch to openwrt for each
** cake patches goes into the openwrt iproute directly
** continues to be built externally as kmod-sched-cake
** Needs update to the new kernel hashing api
** Openwrt is stablizing for now, on linux 4.1
** CC is essentially done, but there will a CC.1 release at some point
** Add better statistics (like active_flows) - have part of this already
--
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-06 22:35 [Cake] cake work needed for openwrt merge Dave Taht
@ 2015-09-07 7:35 ` Sebastian Moeller
2015-09-07 10:45 ` Dave Taht
2015-09-29 13:41 ` Sebastian Moeller
2 siblings, 0 replies; 12+ messages in thread
From: Sebastian Moeller @ 2015-09-07 7:35 UTC (permalink / raw)
To: Dave Täht; +Cc: cake, Felix Fietkau
Hi Dave hi List,
not that I have contributed to cake at all...
On Sep 7, 2015, at 00:35 , Dave Taht <dave.taht@gmail.com> wrote:
> In discussing with felix what is needed for cake to go into openwrt
> trunk, we came up with the following list:
>
> * Cake work needed
> ** Add squash option (besteffort + squashing diffserv)
I believe this should be two independent options, best effort already exists, so it is really a "re-mapp all DSCPs to 0” option that would be great to have (this would allow a simple.qos equivalent without needing iptables)
> ** Fix diffserv
What is broken in cake’s diffserv, that is not already broken under-specified in the diffserv RFC?
> ** Add man page
> ** Clean up patches to only do cake
What are the current patches do that falls outside of cake itself?
> *** Reformat for kernel_style
> *** IProute patches for mainline iproute
In preparation for an upstream merge?
> ** Submit as a single patch to openwrt for each
> ** cake patches goes into the openwrt iproute directly
> ** continues to be built externally as kmod-sched-cake
> ** Needs update to the new kernel hashing api
> ** Openwrt is stablizing for now, on linux 4.1
> ** CC is essentially done, but there will a CC.1 release at some point
> ** Add better statistics (like active_flows) - have part of this already
What is the ETA, I still want to add a maxpacket statistic to the outputs, and want to know how much time I have. Getting maxpackets is quite helpful for dealing with different encapsulations (especially in figuring out which headers the kernel does or does not add automatically).
Best Regards
Sebastian
>
>
> --
> Dave Täht
> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-06 22:35 [Cake] cake work needed for openwrt merge Dave Taht
2015-09-07 7:35 ` Sebastian Moeller
@ 2015-09-07 10:45 ` Dave Taht
2015-09-07 11:21 ` Sebastian Moeller
2015-09-29 13:41 ` Sebastian Moeller
2 siblings, 1 reply; 12+ messages in thread
From: Dave Taht @ 2015-09-07 10:45 UTC (permalink / raw)
To: cake, Felix Fietkau
** expose the interval parameter for longer rtts.
In fact, I think using the word "rtt" might be saner than "interval".
We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> In discussing with felix what is needed for cake to go into openwrt
> trunk, we came up with the following list:
>
> * Cake work needed
> ** Add squash option (besteffort + squashing diffserv)
> ** Fix diffserv
> ** Add man page
> ** Clean up patches to only do cake
> *** Reformat for kernel_style
> *** IProute patches for mainline iproute
> ** Submit as a single patch to openwrt for each
> ** cake patches goes into the openwrt iproute directly
> ** continues to be built externally as kmod-sched-cake
> ** Needs update to the new kernel hashing api
> ** Openwrt is stablizing for now, on linux 4.1
> ** CC is essentially done, but there will a CC.1 release at some point
> ** Add better statistics (like active_flows) - have part of this already
>
>
> --
> Dave Täht
> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
--
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 10:45 ` Dave Taht
@ 2015-09-07 11:21 ` Sebastian Moeller
2015-09-07 19:43 ` Benjamin Cronce
0 siblings, 1 reply; 12+ messages in thread
From: Sebastian Moeller @ 2015-09-07 11:21 UTC (permalink / raw)
To: Dave Täht; +Cc: cake, Felix Fietkau
Hi Dave,
On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
> ** expose the interval parameter for longer rtts.
>
> In fact, I think using the word "rtt" might be saner than "interval”.
Not sure, RTT will make a lot of people nervous about this being basically a run-time constant while actual RTTs of the flows range from a few ms to several 100s. To not confuse these people we would need something like “typical average/median RTT” or “longest realistic RTT” or even “center of realistic RTT range” that conveys that this is more about order of magnitude than any real RTT. It could also be that people in general are much better about this and I just got a specific subset in the crowd I try to help getting sqm-scripts up and running ;)
Best Regards
Sebastian
> We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
>
>
> On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> In discussing with felix what is needed for cake to go into openwrt
>> trunk, we came up with the following list:
>>
>> * Cake work needed
>> ** Add squash option (besteffort + squashing diffserv)
>> ** Fix diffserv
>> ** Add man page
>> ** Clean up patches to only do cake
>> *** Reformat for kernel_style
>> *** IProute patches for mainline iproute
>> ** Submit as a single patch to openwrt for each
>> ** cake patches goes into the openwrt iproute directly
>> ** continues to be built externally as kmod-sched-cake
>> ** Needs update to the new kernel hashing api
>> ** Openwrt is stablizing for now, on linux 4.1
>> ** CC is essentially done, but there will a CC.1 release at some point
>> ** Add better statistics (like active_flows) - have part of this already
>>
>>
>> --
>> Dave Täht
>> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
>
>
>
> --
> Dave Täht
> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 11:21 ` Sebastian Moeller
@ 2015-09-07 19:43 ` Benjamin Cronce
2015-09-07 20:35 ` Sebastian Moeller
0 siblings, 1 reply; 12+ messages in thread
From: Benjamin Cronce @ 2015-09-07 19:43 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cake, Felix Fietkau
[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]
If you're only concerned about the magnitude, fixed-line based Internet
connections only have two magnitudes. Local(10ms) and world-wide(100ms). My
break down goes like this for datacenters from my home connection.
10ms Chicago
30ms New York City and Washington DC
45ms Houston and Miami
60ms San Jose and San Francisco
70ms LA, San Diego, and Seattle
90ms London and Paris
115ms Hawaii
120ms Frankfurt and Switzerland
150ms Japan
170ms Moscow
190ms New Zealand
210ms Sao Paulo(Brazil)
215ms Sydney
220ms Hong Kong and Dubai(United Arab Emirates)
250ms Singapore, China, India, Cape Town(South Africa)
As you can tell, terrestrial latency doesn't have many flavors except when
congestion or horrible routing is involved. In my case, my 95th percentile
of high RTTs is around 20ms because of CDNs and my 80th is closer to 10ms.
Similar with video games, except Eve Online which is hosted in London. In
my case, a 100ms RTT is from Hawaii to Europe.
If you're only concerned about magnitudes, then only need a few options
like fixed-line terrestrial mode and satellite mode for your main options.
If I was to choose a custom interval/RTT for myself without doing a proper
measurement, probably 40ms, assuming that gives any benefit over the
default 100ms
On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
>
> > ** expose the interval parameter for longer rtts.
> >
> > In fact, I think using the word "rtt" might be saner than "interval”.
>
> Not sure, RTT will make a lot of people nervous about this being
> basically a run-time constant while actual RTTs of the flows range from a
> few ms to several 100s. To not confuse these people we would need something
> like “typical average/median RTT” or “longest realistic RTT” or even
> “center of realistic RTT range” that conveys that this is more about order
> of magnitude than any real RTT. It could also be that people in general are
> much better about this and I just got a specific subset in the crowd I try
> to help getting sqm-scripts up and running ;)
>
>
> Best Regards
> Sebastian
>
> > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
> >
> >
> > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >> In discussing with felix what is needed for cake to go into openwrt
> >> trunk, we came up with the following list:
> >>
> >> * Cake work needed
> >> ** Add squash option (besteffort + squashing diffserv)
> >> ** Fix diffserv
> >> ** Add man page
> >> ** Clean up patches to only do cake
> >> *** Reformat for kernel_style
> >> *** IProute patches for mainline iproute
> >> ** Submit as a single patch to openwrt for each
> >> ** cake patches goes into the openwrt iproute directly
> >> ** continues to be built externally as kmod-sched-cake
> >> ** Needs update to the new kernel hashing api
> >> ** Openwrt is stablizing for now, on linux 4.1
> >> ** CC is essentially done, but there will a CC.1 release at some point
> >> ** Add better statistics (like active_flows) - have part of this already
> >>
> >>
> >> --
> >> Dave Täht
> >> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> >
> >
> >
> > --
> > Dave Täht
> > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
[-- Attachment #2: Type: text/html, Size: 5246 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 19:43 ` Benjamin Cronce
@ 2015-09-07 20:35 ` Sebastian Moeller
2015-09-07 20:37 ` Dave Taht
2015-09-07 22:31 ` Benjamin Cronce
0 siblings, 2 replies; 12+ messages in thread
From: Sebastian Moeller @ 2015-09-07 20:35 UTC (permalink / raw)
To: Benjamin Cronce; +Cc: cake, Felix Fietkau
Hi Benjamin,
On Sep 7, 2015, at 21:43 , Benjamin Cronce <bcronce@gmail.com> wrote:
> If you're only concerned about the magnitude, fixed-line based Internet connections only have two magnitudes. Local(10ms) and world-wide(100ms). My break down goes like this for datacenters from my home connection.
> 10ms Chicago
> 30ms New York City and Washington DC
> 45ms Houston and Miami
> 60ms San Jose and San Francisco
> 70ms LA, San Diego, and Seattle
> 90ms London and Paris
> 115ms Hawaii
> 120ms Frankfurt and Switzerland
> 150ms Japan
> 170ms Moscow
> 190ms New Zealand
> 210ms Sao Paulo(Brazil)
> 215ms Sydney
> 220ms Hong Kong and Dubai(United Arab Emirates)
> 250ms Singapore, China, India, Cape Town(South Africa)
>
> As you can tell, terrestrial latency doesn't have many flavors except when congestion or horrible routing is involved. In my case, my 95th percentile of high RTTs is around 20ms because of CDNs and my 80th is closer to 10ms. Similar with video games, except Eve Online which is hosted in London. In my case, a 100ms RTT is from Hawaii to Europe.
Good point, so it is rather “longest realistic RTT” what we are after. My point was not about what the real RTTs are (even though your results are interesting in themselves) but how to name the parameter to not confuse novice users… and my hunch is RTT is not the best description here… but I lack a better snappy phrase
Best Regards
Sebastian
>
> If you're only concerned about magnitudes, then only need a few options like fixed-line terrestrial mode and satellite mode for your main options. If I was to choose a custom interval/RTT for myself without doing a proper measurement, probably 40ms, assuming that gives any benefit over the default 100ms
>
> On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
> On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
>
> > ** expose the interval parameter for longer rtts.
> >
> > In fact, I think using the word "rtt" might be saner than "interval”.
>
> Not sure, RTT will make a lot of people nervous about this being basically a run-time constant while actual RTTs of the flows range from a few ms to several 100s. To not confuse these people we would need something like “typical average/median RTT” or “longest realistic RTT” or even “center of realistic RTT range” that conveys that this is more about order of magnitude than any real RTT. It could also be that people in general are much better about this and I just got a specific subset in the crowd I try to help getting sqm-scripts up and running ;)
>
>
> Best Regards
> Sebastian
>
> > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
> >
> >
> > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> >> In discussing with felix what is needed for cake to go into openwrt
> >> trunk, we came up with the following list:
> >>
> >> * Cake work needed
> >> ** Add squash option (besteffort + squashing diffserv)
> >> ** Fix diffserv
> >> ** Add man page
> >> ** Clean up patches to only do cake
> >> *** Reformat for kernel_style
> >> *** IProute patches for mainline iproute
> >> ** Submit as a single patch to openwrt for each
> >> ** cake patches goes into the openwrt iproute directly
> >> ** continues to be built externally as kmod-sched-cake
> >> ** Needs update to the new kernel hashing api
> >> ** Openwrt is stablizing for now, on linux 4.1
> >> ** CC is essentially done, but there will a CC.1 release at some point
> >> ** Add better statistics (like active_flows) - have part of this already
> >>
> >>
> >> --
> >> Dave Täht
> >> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> >
> >
> >
> > --
> > Dave Täht
> > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 20:35 ` Sebastian Moeller
@ 2015-09-07 20:37 ` Dave Taht
2015-09-07 22:31 ` Benjamin Cronce
1 sibling, 0 replies; 12+ messages in thread
From: Dave Taht @ 2015-09-07 20:37 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cake, Felix Fietkau
there has been interest from at least one satcom provider in cake.
On Mon, Sep 7, 2015 at 1:35 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Benjamin,
>
> On Sep 7, 2015, at 21:43 , Benjamin Cronce <bcronce@gmail.com> wrote:
>
>> If you're only concerned about the magnitude, fixed-line based Internet connections only have two magnitudes. Local(10ms) and world-wide(100ms). My break down goes like this for datacenters from my home connection.
>> 10ms Chicago
>> 30ms New York City and Washington DC
>> 45ms Houston and Miami
>> 60ms San Jose and San Francisco
>> 70ms LA, San Diego, and Seattle
>> 90ms London and Paris
>> 115ms Hawaii
>> 120ms Frankfurt and Switzerland
>> 150ms Japan
>> 170ms Moscow
>> 190ms New Zealand
>> 210ms Sao Paulo(Brazil)
>> 215ms Sydney
>> 220ms Hong Kong and Dubai(United Arab Emirates)
>> 250ms Singapore, China, India, Cape Town(South Africa)
>>
>> As you can tell, terrestrial latency doesn't have many flavors except when congestion or horrible routing is involved. In my case, my 95th percentile of high RTTs is around 20ms because of CDNs and my 80th is closer to 10ms. Similar with video games, except Eve Online which is hosted in London. In my case, a 100ms RTT is from Hawaii to Europe.
>
> Good point, so it is rather “longest realistic RTT” what we are after. My point was not about what the real RTTs are (even though your results are interesting in themselves) but how to name the parameter to not confuse novice users… and my hunch is RTT is not the best description here… but I lack a better snappy phrase
>
> Best Regards
> Sebastian
>
>>
>> If you're only concerned about magnitudes, then only need a few options like fixed-line terrestrial mode and satellite mode for your main options. If I was to choose a custom interval/RTT for myself without doing a proper measurement, probably 40ms, assuming that gives any benefit over the default 100ms
>>
>> On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Dave,
>>
>> On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
>>
>> > ** expose the interval parameter for longer rtts.
>> >
>> > In fact, I think using the word "rtt" might be saner than "interval”.
>>
>> Not sure, RTT will make a lot of people nervous about this being basically a run-time constant while actual RTTs of the flows range from a few ms to several 100s. To not confuse these people we would need something like “typical average/median RTT” or “longest realistic RTT” or even “center of realistic RTT range” that conveys that this is more about order of magnitude than any real RTT. It could also be that people in general are much better about this and I just got a specific subset in the crowd I try to help getting sqm-scripts up and running ;)
>>
>>
>> Best Regards
>> Sebastian
>>
>> > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
>> >
>> >
>> > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
>> >> In discussing with felix what is needed for cake to go into openwrt
>> >> trunk, we came up with the following list:
>> >>
>> >> * Cake work needed
>> >> ** Add squash option (besteffort + squashing diffserv)
>> >> ** Fix diffserv
>> >> ** Add man page
>> >> ** Clean up patches to only do cake
>> >> *** Reformat for kernel_style
>> >> *** IProute patches for mainline iproute
>> >> ** Submit as a single patch to openwrt for each
>> >> ** cake patches goes into the openwrt iproute directly
>> >> ** continues to be built externally as kmod-sched-cake
>> >> ** Needs update to the new kernel hashing api
>> >> ** Openwrt is stablizing for now, on linux 4.1
>> >> ** CC is essentially done, but there will a CC.1 release at some point
>> >> ** Add better statistics (like active_flows) - have part of this already
>> >>
>> >>
>> >> --
>> >> Dave Täht
>> >> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
>> >
>> >
>> >
>> > --
>> > Dave Täht
>> > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
>> > _______________________________________________
>> > Cake mailing list
>> > Cake@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/cake
>>
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>>
>
--
Dave Täht
endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 20:35 ` Sebastian Moeller
2015-09-07 20:37 ` Dave Taht
@ 2015-09-07 22:31 ` Benjamin Cronce
2015-09-07 22:44 ` Jonathan Morton
2015-09-08 7:20 ` Sebastian Moeller
1 sibling, 2 replies; 12+ messages in thread
From: Benjamin Cronce @ 2015-09-07 22:31 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cake, Felix Fietkau
[-- Attachment #1: Type: text/plain, Size: 5231 bytes --]
On Mon, Sep 7, 2015 at 3:35 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Benjamin,
>
> On Sep 7, 2015, at 21:43 , Benjamin Cronce <bcronce@gmail.com> wrote:
>
> > If you're only concerned about the magnitude, fixed-line based Internet
> connections only have two magnitudes. Local(10ms) and world-wide(100ms). My
> break down goes like this for datacenters from my home connection.
> > 10ms Chicago
> > 30ms New York City and Washington DC
> > 45ms Houston and Miami
> > 60ms San Jose and San Francisco
> > 70ms LA, San Diego, and Seattle
> > 90ms London and Paris
> > 115ms Hawaii
> > 120ms Frankfurt and Switzerland
> > 150ms Japan
> > 170ms Moscow
> > 190ms New Zealand
> > 210ms Sao Paulo(Brazil)
> > 215ms Sydney
> > 220ms Hong Kong and Dubai(United Arab Emirates)
> > 250ms Singapore, China, India, Cape Town(South Africa)
> >
> > As you can tell, terrestrial latency doesn't have many flavors except
> when congestion or horrible routing is involved. In my case, my 95th
> percentile of high RTTs is around 20ms because of CDNs and my 80th is
> closer to 10ms. Similar with video games, except Eve Online which is hosted
> in London. In my case, a 100ms RTT is from Hawaii to Europe.
>
> Good point, so it is rather “longest realistic RTT” what we are
> after. My point was not about what the real RTTs are (even though your
> results are interesting in themselves) but how to name the parameter to not
> confuse novice users… and my hunch is RTT is not the best description here…
> but I lack a better snappy phrase
>
> Best Regards
> Sebastian
>
It may be easier to use a distance based naming. Instead of something like
"High(250ms) RTT" be like "Inter-continental", medium(100ms) RTT may be
"Intra-continental", and low(50ms) RTTs may be "Local Region". "Region" can
be a bit ambiguous, but I figured if given two options "Local Region" and
"Intra-continental", that the idea of what "region" represents in this
context is clear enough. Satellite links would only need one option because
the latency of the satellite will be greater than the latency from all of
the terrestrial links combined. As for the actual variable name and not the
option names. hmmm. Assuming similarly named options, "Optimize for"?
>
> >
> > If you're only concerned about magnitudes, then only need a few options
> like fixed-line terrestrial mode and satellite mode for your main options.
> If I was to choose a custom interval/RTT for myself without doing a proper
> measurement, probably 40ms, assuming that gives any benefit over the
> default 100ms
> >
> > On Mon, Sep 7, 2015 at 6:21 AM, Sebastian Moeller <moeller0@gmx.de>
> wrote:
> > Hi Dave,
> >
> > On Sep 7, 2015, at 12:45 , Dave Taht <dave.taht@gmail.com> wrote:
> >
> > > ** expose the interval parameter for longer rtts.
> > >
> > > In fact, I think using the word "rtt" might be saner than "interval”.
> >
> > Not sure, RTT will make a lot of people nervous about this being
> basically a run-time constant while actual RTTs of the flows range from a
> few ms to several 100s. To not confuse these people we would need something
> like “typical average/median RTT” or “longest realistic RTT” or even
> “center of realistic RTT range” that conveys that this is more about order
> of magnitude than any real RTT. It could also be that people in general are
> much better about this and I just got a specific subset in the crowd I try
> to help getting sqm-scripts up and running ;)
> >
> >
> > Best Regards
> > Sebastian
> >
> > > We could also add shortcuts like LEO, GEO, GTO, L1-L5, MOON, MARS. :)
> > >
> > >
> > > On Sun, Sep 6, 2015 at 3:35 PM, Dave Taht <dave.taht@gmail.com> wrote:
> > >> In discussing with felix what is needed for cake to go into openwrt
> > >> trunk, we came up with the following list:
> > >>
> > >> * Cake work needed
> > >> ** Add squash option (besteffort + squashing diffserv)
> > >> ** Fix diffserv
> > >> ** Add man page
> > >> ** Clean up patches to only do cake
> > >> *** Reformat for kernel_style
> > >> *** IProute patches for mainline iproute
> > >> ** Submit as a single patch to openwrt for each
> > >> ** cake patches goes into the openwrt iproute directly
> > >> ** continues to be built externally as kmod-sched-cake
> > >> ** Needs update to the new kernel hashing api
> > >> ** Openwrt is stablizing for now, on linux 4.1
> > >> ** CC is essentially done, but there will a CC.1 release at some point
> > >> ** Add better statistics (like active_flows) - have part of this
> already
> > >>
> > >>
> > >> --
> > >> Dave Täht
> > >> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> > >
> > >
> > >
> > > --
> > > Dave Täht
> > > endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> > > _______________________________________________
> > > Cake mailing list
> > > Cake@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/cake
> >
> > _______________________________________________
> > Cake mailing list
> > Cake@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cake
> >
>
>
[-- Attachment #2: Type: text/html, Size: 7135 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 22:31 ` Benjamin Cronce
@ 2015-09-07 22:44 ` Jonathan Morton
2015-09-08 7:20 ` Sebastian Moeller
1 sibling, 0 replies; 12+ messages in thread
From: Jonathan Morton @ 2015-09-07 22:44 UTC (permalink / raw)
To: Benjamin Cronce; +Cc: cake, Felix Fietkau
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
How about:
Datacentre (10 us, 100 kHz)
LAN/WiFi (1 ms, 1 kHz)
Metropolitan (10 ms, 100 Hz)
Regional (30 ms, 33 Hz)
Transcontinental (100 ms, 10 Hz)
Intercontinental (300 ms, 3 Hz)
Satellite (1000 ms, 1 Hz)
Translunar (3000 ms, 0.3 Hz)
Interplanetary (100000 ms, 0.01 Hz)
- Jonathan Morton
[-- Attachment #2: Type: text/html, Size: 378 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-07 22:31 ` Benjamin Cronce
2015-09-07 22:44 ` Jonathan Morton
@ 2015-09-08 7:20 ` Sebastian Moeller
2015-09-09 23:54 ` Benjamin Cronce
1 sibling, 1 reply; 12+ messages in thread
From: Sebastian Moeller @ 2015-09-08 7:20 UTC (permalink / raw)
To: Benjamin Cronce; +Cc: cake, Felix Fietkau
Hi Benjamin,
On Sep 8, 2015, at 00:31 , Benjamin Cronce <bcronce@gmail.com> wrote:
> [...]
> It may be easier to use a distance based naming. Instead of something like "High(250ms) RTT" be like "Inter-continental", medium(100ms) RTT may be "Intra-continental", and low(50ms) RTTs may be "Local Region". "Region" can be a bit ambiguous, but I figured if given two options "Local Region" and "Intra-continental", that the idea of what "region" represents in this context is clear enough. Satellite links would only need one option because the latency of the satellite will be greater than the latency from all of the terrestrial links combined. As for the actual variable name and not the option names. hmmm. Assuming similarly named options, "Optimize for"?
> [...]
For the crowd on this mailing list any names will do, but for novices that just heard of buffer bloat and its remedies, I believe we need simple unambiguous names. The challenge with distance is that while geographical distance should not be too hard to figure out, path distance is much trickier (aka true user will need i measure). If I recall correctly, codel is actually pretty robust against deviations of true RTTs from interval, but I do not remember any data showing this on a per true RTT basis or for fq_codel (where I assume the issue might be more pronounced, as the different RTT flows will be separated unlike in codel where all is mixed).
Best Regards
Sebastian
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-08 7:20 ` Sebastian Moeller
@ 2015-09-09 23:54 ` Benjamin Cronce
0 siblings, 0 replies; 12+ messages in thread
From: Benjamin Cronce @ 2015-09-09 23:54 UTC (permalink / raw)
To: Sebastian Moeller; +Cc: cake, Felix Fietkau
[-- Attachment #1: Type: text/plain, Size: 2253 bytes --]
On Tue, Sep 8, 2015 at 2:20 AM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Benjamin,
>
>
> On Sep 8, 2015, at 00:31 , Benjamin Cronce <bcronce@gmail.com> wrote:
> > [...]
> > It may be easier to use a distance based naming. Instead of something
> like "High(250ms) RTT" be like "Inter-continental", medium(100ms) RTT may
> be "Intra-continental", and low(50ms) RTTs may be "Local Region". "Region"
> can be a bit ambiguous, but I figured if given two options "Local Region"
> and "Intra-continental", that the idea of what "region" represents in this
> context is clear enough. Satellite links would only need one option because
> the latency of the satellite will be greater than the latency from all of
> the terrestrial links combined. As for the actual variable name and not the
> option names. hmmm. Assuming similarly named options, "Optimize for"?
> > [...]
>
> For the crowd on this mailing list any names will do, but for novices that
> just heard of buffer bloat and its remedies, I believe we need simple
> unambiguous names. The challenge with distance is that while geographical
> distance should not be too hard to figure out, path distance is much
> trickier (aka true user will need i measure). If I recall correctly, codel
> is actually pretty robust against deviations of true RTTs from interval,
> but I do not remember any data showing this on a per true RTT basis or for
> fq_codel (where I assume the issue might be more pronounced, as the
> different RTT flows will be separated unlike in codel where all is mixed).
>
>
> Best Regards
> Sebastian
You point out that the path distance is more important than geological
distance, which I find interesting because in my case, my max ping to any
fiber linked place on Earth is almost exactly 250ms. Assuming 0.6c for
light in fiber, that's 27,900 miles round trip. The Earth has a maximum
circumference of 24,901 miles. That means route distance is within 12.5% of
geological distance. I find latency to be a very good indication of
geological distance. You did mention that you found my latencies
"interesting". I have a feeling I have a special circumstance.
Watch people narrow down where I live based on those listed latencies. At
least I did some mild rounding.
[-- Attachment #2: Type: text/html, Size: 2900 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Cake] cake work needed for openwrt merge
2015-09-06 22:35 [Cake] cake work needed for openwrt merge Dave Taht
2015-09-07 7:35 ` Sebastian Moeller
2015-09-07 10:45 ` Dave Taht
@ 2015-09-29 13:41 ` Sebastian Moeller
2 siblings, 0 replies; 12+ messages in thread
From: Sebastian Moeller @ 2015-09-29 13:41 UTC (permalink / raw)
To: Dave Täht; +Cc: cake, Felix Fietkau
Hi Dave,
revisiting your old plan:
On Sep 7, 2015, at 00:35 , Dave Taht <dave.taht@gmail.com> wrote:
> In discussing with felix what is needed for cake to go into openwrt
> trunk, we came up with the following list:
>
> * Cake work needed
> ** Add squash option (besteffort + squashing diffserv)
Done, as of 444f9e5c0fde1400f21175eacfa7ced60b410e49 ?
> ** Fix diffserv
What needs fixing there?
> ** Add man page
> ** Clean up patches to only do cake
Was that fq_pie only? Then done as of dca3df3490470af6b134b7015559d9416f3a7616 ?
> *** Reformat for kernel_style
> *** IProute patches for mainline iproute
I thought this requires sch_cake to be upstream already?
> ** Submit as a single patch to openwrt for each
> ** cake patches goes into the openwrt iproute directly
> ** continues to be built externally as kmod-sched-cake
> ** Needs update to the new kernel hashing api
Isn’t that diner as well, as of f3289fe8ae2a28640616bf3f3289fe8ae2a2864061 ?
> ** Openwrt is stablizing for now, on linux 4.1
> ** CC is essentially done, but there will a CC.1 release at some point
> ** Add better statistics (like active_flows) - have part of this already
I would still like maxpacket per bin just as fq_codel does, this is really really helpful to figure out how much overhead accounting the kernel adds by itself.
Let me expand: the kernel does not simply give the payload size of a packet but, depending on the interface type in use, adds for example 14 byte “virtual size” for ethernet. But it is not well documented how much is added for which interface type, if a diffserv capable qdisc emits the packet sizes it is pretty easy to test what the kernel does, by simply sending an know sized packet on the relevant interface and ask the qdisc how large that packet was (rem how many bits were accounted). It also is helpful in figuring out whether GRO/GSO and friends are in use…
Best Regards
Sebastian
>
>
> --
> Dave Täht
> endo is a terrible disease: http://www.gofundme.com/SummerVsEndo
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-09-29 13:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-06 22:35 [Cake] cake work needed for openwrt merge Dave Taht
2015-09-07 7:35 ` Sebastian Moeller
2015-09-07 10:45 ` Dave Taht
2015-09-07 11:21 ` Sebastian Moeller
2015-09-07 19:43 ` Benjamin Cronce
2015-09-07 20:35 ` Sebastian Moeller
2015-09-07 20:37 ` Dave Taht
2015-09-07 22:31 ` Benjamin Cronce
2015-09-07 22:44 ` Jonathan Morton
2015-09-08 7:20 ` Sebastian Moeller
2015-09-09 23:54 ` Benjamin Cronce
2015-09-29 13:41 ` Sebastian Moeller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox