Cake - FQ_codel the next generation
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: Benjamin Cronce <bcronce@gmail.com>
Cc: cake@lists.bufferbloat.net, Felix Fietkau <nbd@nbd.name>
Subject: Re: [Cake] cake work needed for openwrt merge
Date: Mon, 7 Sep 2015 22:35:22 +0200	[thread overview]
Message-ID: <E7B5448A-8343-4D39-9349-A8445E693F23@gmx.de> (raw)
In-Reply-To: <CAJ_ENFFB8vwHtOFw7ZVV5R=dxO1OMWsJrUnKBq+twYX6w81RXg@mail.gmail.com>

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
> 


  reply	other threads:[~2015-09-07 20:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-06 22:35 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E7B5448A-8343-4D39-9349-A8445E693F23@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bcronce@gmail.com \
    --cc=cake@lists.bufferbloat.net \
    --cc=nbd@nbd.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox