On Tue, Oct 4, 2016 at 3:54 PM, moeller0 <[email protected]> wrote: > Hi Jonathan, > >> On Oct 4, 2016, at 13:18 , Jonathan Morton <[email protected]> wrote: >> >> >>> On 4 Oct, 2016, at 11:46, moeller0 <[email protected]> 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 >> >
Perhaps a good way to move forward on this might be to have some kind of hackathon, and have a face to face discussion so that we could move on ? > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
