> 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. 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. I have been careful here to calculate ceil(len * 65/64) here, so that the overhead is never underestimated. 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. 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. 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. 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. - Jonathan Morton _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
