Hi Jonathan,
> On Oct 4, 2016, at 13:18 , Jonathan Morton <chromati...@gmail.com> wrote:
>
>
>> On 4 Oct, 2016, at 11:46, moeller0 <moell...@gmx.de> wrote:
>>
>> 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 shaper works by calculating the time occupied by each packet on the wire,
> and advancing a virtual clock in step with a continuous stream of packets.
>
> The time occupation, in turn, is calculated as the number of bytes which
> appear on the wire divided by the number of bytes that wire can pass per
> second. As an optimisation, the division is turned into a multiplication by
> the reciprocal.
Okay, but that seems not really relevant to the topic at hand as in PTM
systems the effective payload-rate is 64/65 of the raw bit rate. The 65th byte
is independent of the actual packet size sent so theoretically better modeled
as a rate reduction than as a size increase, even though in essence for a
shaper you can account for it either way.
>
> I’m quite keen to keep the “bytes per second” purely derived from the raw
> bitrate of the link, because that is the value widely advertised by ISPs and
> network equipment manufacturers everywhere. Hence, overhead compensation is
> implemented purely by increasing the accounted size of the packets.
Sorry that does not make much sense, I realize that mathematically they
are interchangeable, but that does not make them the same IMHO. Per packet
overhead needs to be accounted on a per-packet basis you have no other real
option (unless you work with a fixed packet length), but generic rate
reductions do not need to be recomputed for each packet.
>
> I have been careful here to calculate ceil(len * 65/64) here, so that the
> overhead is never underestimated.
Which is Jonathanese for might be overestimated, so you at least agree
with my point about the precision of the accounting being relevant. As I
proposed in on of my comments “floor(shaper_rate * 64/64)” has the same
property of being conservative, only with a lower possible error.
> For example, a 1500-byte IP packet becomes 1519 with bridged PTM or 1527
> with PPPoE over PTM, before the PTM calculation itself. These both round up
> to 1536 before division, so 24 more bytes will be added in both cases.
That is not one of the arguments I have made, but thanks for pointing
that out.
>
> This is less than 2 bits more than actually required (on average), so wastes
> less than 1/6200 of the bandwidth when full-sized packets dominate the link
> (as is the usual case). Users are unlikely to notice this in practice.
Erm, VoIP packets are not close to full MTU so I am not sure whether
“as is the usual case” is very convincing. Actually your tendency to always
“wing it” instead of doing research as shown when you claimed 64/65 bit
encoding for PTM instead of looking into the relevant standards (which I had to
cite twice to make you at least fix that misconception) does not not fill me
with confidence about those parts of cake where I do have zero expertise.
>
> Next to all the other stuff Cake does for each packet, the overhead
> compensation is extremely quick. And, although the code looks very similar,
> the PTM compensation is faster than the ATM compensation, because the factor
> involved is a power of two (which GCC is very good at optimising into shifts
> and masks). This is fortunate, since PTM is typically used on
> higher-bandwidth links than ATM.
I venture a guess that I have forgotten more about ATM/PTM ADSL/VDSL
than you ever bothered to read up on, so why do you keep telling me these
observations? If the goal is to annoy me, then mission accomplished.
>
> Now, if you can show me that the above is in fact incorrect - that
> significant bandwidth is wasted on some real traffic profile, or that
> cake_overhead() figures highly in a CPU profile on real hardware - then I
> will reconsider.
And that is great fun, the guy (you) that most often argues from first
principle instead of from real world data, requests actual data in one of the
cases where first principle seems quite applicable: when an operation can be
(almost) completely avoided.
But I guess we just keep it as in the past; you keep not fully grasping
the intricacies of different XDSL/DOCSIS encodings and I keep ridiculing you
for the demonstrated lack of love to detail in these matters.
In the past I sometimes wondered whether I did anything to offend you
by voicing my concerns in too brash or impolite way, but now I simply assume
that you (like most of us) simply do not react well to criticism (even if
justified) and prefer to just harass the messenger.
>
> - Jonathan Morton
>
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
