[Cake] Master branch updated

[moeller0]

Hi Jonathan,

> On Oct 4, 2016, at 13:18 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> 
> 
>> On 4 Oct, 2016, at 11:46, moeller0 <moeller0 at 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
>