Hi Fuller,
if you believe the problem to be related to cake’s overhead accounting feel free to set the $LLAM to “tc_stab”, that way you can also configure the MPU, the minimal size of a packet, which in all likelihood is >= 64 bytes on ethernet. On pppoe-wan the kernel will not automatically add 14 bytes so you should be okay. The MPU question is more relevant, but also massively unclear, VDSL2 can send frames <64B unlike ethernet, but whether it actually does or does not escapes my understanding. I assume that in most conditions if passed a padded ethernet frame VDSL2 will simply pass on that frame including padding, as otherwise it would need to calculate a new FCS at the vdsl-sender and the vdsl-receiver would need to undo this and padd the packets again, in essence that indicates that all transports using ethernet frames might want mpu set to 64, bytes.
Regarding using cake’s “ptm” setting, please don’t. This is a misfeature, rather go and statically discount your bandwidth by 100-100*64/65 = 1.54% instead of incurring additional computations at each packets that also seem to be less precise.
BUT on DTAG links your problem might actually not be the VDSL2 leg, but rather the BRAS/BNG level shaper that DTAG employs. You would need to configure your sqm-instance to do the right thing for that shaper (as far as I know it uses double VLAN tagging, but not sure about the FCS) also that shaper’s actual bandwidth is not communicated to end users so it requires careful testing, if you use your modems sync bandwidth you certainly will shape too high which will show especially when testing with small packets…
Best Regards