Hi Jonathan,
> On Oct 4, 2016, at 09:22 , Jonathan Morton <[email protected]> wrote:
>
> I’ve just merged the NAT, PTM
About that PTM accounting, could you explain why you want to perform
the adjustment as a a “virtual” size increase per packet instead of a “virtual”
rate reduction? The arguments for adjusting the rate are as follows:
1) You only need to adjust the rate if the rate was changed compared to for
each packet, which should save CPU time and be more efficient.
2) For most users the rate (potentially expressed as bits per second) will be
larger than the typical packet size (around 1540 Bytes) so adjusting the rate
should introduce less rounding imprecision. To put this in numbers 1540 Byte
equal 12.32 Kbit.
I am confident that you have good reasons for you implementation decisions, all
I want is to learn what those are.
Best Regards
Sebastian
P.S.: I realize that I am looking like a one-trick pony totally hung up on
the overhead adjustment issue. I would prefer to let go, but I want to be
certain that this is in good hands before I do this, as the value of doing
these compensations IMHO depends on absolute meticulous attention (so needs any
additional pair of eyes to peer over it).
> and Linux-4.8 compatibility stuff into the master branch of Cake. It’s
> stable code and a definite improvement.
>
> This frees up the Cobalt branch for more experimentation, such as the rewrite
> of triple-isolate that I also just pushed. I found a way to make it more
> DRR-like, by simply scaling down the quantum used for each host by the number
> of flows attached to that host.
>
> I still need to test whether it works as well as the old version, but it
> should at least be less CPU intensive. In particular it should no longer
> require bursts of CPU activity when the host deficits expire, and host
> deficit expiry should no longer be explicitly synchronised.
>
> See if, between you, you can break it before I get back from shopping. :-)
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
