Re: [Cake] [PATCH] q_cake: Update xstats format to use per-tin structure

[Luis E. Garcia]

Nice work Kevin.

On Sat, Mar 10, 2018 at 09:56 Kevin Darbyshire-Bryant <
ke...@darbyshire-bryant.me.uk> wrote:

>
>
> > On 8 Mar 2018, at 11:21, Toke Høiland-Jørgensen  wrote:
> >
> >>
> >> Oh and curiously the bad values go away if you ask for json output
> >> it’s much better.  Which rather points at a ‘feature’ of the
> >> ‘print_string’ behaviour.
> >
> > Right. Well, the print_* functions are behind several levels of
> > pre-processor indirection, so not quite obvious what's going on here.
> > Don't really see why they should spit out garbage values, though.
> >
> >
> > Stephen, do you have any ideas?
> >
> > -Toke
>
> Right, cracked it and it’s horrible!
>
> print_uint is expanded thus:  Note the type of value uint64_t
>
>   void print_color_uint(enum output_type t, enum color_attr
> color, const char *key, const char *fmt, uint64_t value);
> static inline void print_uint  (enum output_type t,
> const char *key, const char *fmt, uint64_t value)
>  { print_color_uint( t, COLOR_NONE,
> key, fmt,  value); };
>
> So far so good.
>
> print_color_uint expands to:
>
>  void print_color_uint(enum output_type t, enum color_attr
> color, const char *key, const char *fmt, uint64_t value)
>  {
>   if (((t & PRINT_JSON || t & PRINT_ANY) && _jw))
> { if (!key) jsonw_uint(_jw, value);
>   else  jsonw_uint_field(_jw, key, value);
> }
>   else if ((!_jw && (t & PRINT_FP || t & PRINT_ANY)))
> { color_fprintf( (stdout) , color, fmt, value);
> }
>  };
>
> Again, no issue and we eventually call color_fprintf
>
> int color_fprintf(FILE *fp, enum color_attr attr, const char *fmt, ...)
> {
> int ret = 0;
> va_list args;
>
> va_start(args, fmt);
>
> if (!color_is_enabled || attr == COLOR_NONE) {
> ret = vfprintf(fp, fmt, args);
> goto end;
> }
>
>
> Now, color_printf is a variable argument list function and as such is
> dependent upon being told the correct size of argument variables in the fmt
> variable.  And that’s our problem, we’re passing a 64bit integer but
> telling the format string that it’s ‘int’…which I’m guessing can be
> variable sizes depending on architecture, as can the endianness.
>
> If we instead do (in q_cake.c)
>
> #include 
>
> print_uint(PRINT_ANY, "min_transport_size", " min/max transport layer
> size: %10" PRIu64, stnc->min_trnlen);
>
> it works.  This needs sanity checking by a clever person.
>
> Cheers,
>
> Kevin D-B
>
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
>
> ___
> 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

Re: [Cake] [Fwd: Re: RHODIUM - nuking blue (for testing)]

[Luis E. Garcia]

Dave,
What is the highest bandwidth that you have been able to shape with CAKE on
the APU2?

Regards,
Luis Garcia

On Wed, Dec 6, 2017 at 3:08 PM, Dave Taht  wrote:

>
> Groovy.
>
> I guess if I had any one goal, was that I wanted to have cake to shape
> well on the APU2 at a gigabit. That's the highest end "home router" we
> have, although it would be good to get results on things like the turris
> omnia, also.
>
> I hope to start a round of profiling as to what can be optimized (out)
> this weekend. Last I looked the hashing costs dominated.
>
> Pretty sure we're good at 200Mbit there (aside from the ingress bug).
>
> It would be nice to have a test showing blue being useful.
>
> Did you get cpu stats for the below tests?
>
> Georgios Amanakis  writes:
>
> >  Forwarded Message 
> > From: Georgios Amanakis 
> > To: Dave Taht 
> > Cc: Cake List , Jonathan Morton  > 9...@gmail.com>, Pete Heist 
> > Subject: Re: [Cake] RHODIUM - nuking blue (for testing)
> > Date: Tue, 05 Dec 2017 20:58:39 -0500
> >
> > I just finished testing Rhodium, and I am supplementing Sunday's
> > results.
> >
> > CMTS setup:
> > server -- delay -- isp -- mbox -- client
> >
> > ISP limited at 200/10mbit.
> > Cake/HTB shaping at 180/9mbit.
> > RTT 20ms with cake's RTT set at 20ms
> > rrul_be_nflows, 32 download, 8 upload streams.
> > net.ipv4.tcp_ecn=2 in all nodes (linux default)
> >
> > Cake tested in all flow-isolation modes with all ack filtering options.
> > HTB tested with codel,pie,fq,sfq,fq_codel.
> >
> > Rhodium(cakerhod) doesn't show much difference against Cobalt(cake).
> >
> > George
> >
> > On Tue, 2017-12-05 at 11:32 -0800, Dave Taht wrote:
> >> Given some of the results thus far at various RTTs, and at higher
> >> loads, like the ginormous one georgios just ran, I thought it might
> >> be
> >> useful to run a battery of tests with blue disabled.
> >>
> >> I haven't gone to the trouble of creating a formal branch - tho if I
> >> did, I'd call it rhodium, as rhodium detectors are used in nuclear
> >> reactors to measure the neutron flux level.
> >>
> >> untested-but-compiling-patch attached. I'm busy on a few other things
> >> this week, and it is looking like we'll have to replace the xstats
> >> structure with something smaller to go mainline.
> >>
> >> ___
> >> 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
> ___
> 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

Re: [Cake] A quick question about FQ_CoDel vs Cake

[Luis E. Garcia]

Thanks Jonathan,
With this explanation it makes sense.

Regards,
Luis

On Thu, Apr 6, 2017 at 11:06 AM Jonathan Morton <chromati...@gmail.com>
wrote:

>
> > On 6 Apr, 2017, at 16:51, Luis E. Garcia <l...@bitamins.net> wrote:
> >
> > I've been doing some testing of Cake on LEDE (WD MyNet 750) and on
> EdgeOS (Ubiquity ERPoe). One big question that I have is why does Cake have
> a higher/better average throughput than FQ_CoDel? The graph seems a bit
> smoother through the speed test.
> >
> > The test are against a 10down/2up Mbps connection from a local provider.
>
> The main difference that’s probably responsible for this is Cake’s
> integrated deficit-mode shaper, which is more accurate on short timescales
> than the more typical token-bucket shaper that fq_codel is used with.
>
> There’s also some difference in the Codel implementation which might or
> might not be relevant, specifically in the calculation of “count” after a
> relatively brief exit from dropping state.
>
>  - Jonathan Morton
>
>
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] A quick question about FQ_CoDel vs Cake

[Luis E. Garcia]

Hi everyone,
I've been doing some testing of Cake on LEDE (WD MyNet 750) and on EdgeOS
(Ubiquity ERPoe). One big question that I have is why does Cake have a
higher/better average throughput than FQ_CoDel? The graph seems a bit
smoother through the speed test.

The test are against a 10down/2up Mbps connection from a local provider.

Luis
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Master branch updated

[Luis E. Garcia]

If we can replicate the results of your test then I would say we're onto
something.

On Monday, 10 October 2016, Jonathan Morton  wrote:

>
> > On 4 Oct, 2016, at 19:28, Jonathan Morton  > wrote:
> >
> >> Ha ha!  I don't know if you're back from shopping yet...and I'm not
> sure that I've broken it (cobalt branch)...but it has broken my router!
> >
> > Hmm.  It’s been running all day with plenty of traffic over here - but
> it did crash the very first time I loaded it, just not the second.  I will
> need to exercise it some more, preferably on a non-critical machine.
>
> Okay, that bug is fixed and I’ve made further improvements to the
> triple-isolate algorithm.  It no longer needs quite as much spaghetti logic
> in the fast path, and might even be easier to understand from reading the
> code, since it’s now more obviously a modification of DRR++ rather than a
> brute-force wrapper around it.  It should certainly give smoother behaviour
> and be less CPU intensive in common cases.
>
> In brief, what I now do is to scale the *flow* quantum down by the higher
> of the two hosts’ flow counts.  I’ve even dealt with underflow of the
> quotient using a dithering mechanism, which should also ensure that flows
> random-walk out of lockstep with each other.
>
> It works sufficiently well that I was able to set Cake to 2.5Mbit
> besteffort triple-isolate, then watch a 720p YouTube video on one machine
> while another was downloading a game update using a 30-flow swarm.  I’d
> call that a success.
>
> Hammer away at it, and then we’ll see if we can merge it up to master.
>
>  - Jonathan Morton
>
> ___
> 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