Not really missing, it would just be a bit more predictable than the default triple-isolate (which in normal situations works quite well, but under speedtest conditions its behavior is not easily explained or predicted).
this together with:
makes sense, in that your link in all likelihood is not using ATM but rather PTM as is customary for VDSL2 (likelihood as it still is permissable to use ATM on VDSL2 links, I just hope no ISP will ever do this; I rather hope ISPs with start to do the also permitted opposite of usinf PTM on ADSL links, but I digress). The will only ever report trustworthy numbers for real ATM links (actually not ATM per se, but ATM/AAL5). But now you got my curiosity, could you maybe post the result pictures somewhere?
But if you carrier happens to be DTAG (deutsche telekom) I can guarantee 1526 byte frames over PTM, so on the ppppoe-wan interface you will need to specify 34 bytes, 8 bytes for the PPP/PPPoE Overhead and 26 Bytes for ethernet (VLAN) and PTM headers.
Also DTAG actually limits the bandwidth at the BRAS/BNG level so you need to set the shaper bandwidth relative to that unknown limit bandwidth and not the pure sync reported by the VDSL2-modem. The one set of numbers I got from an on-line discussion at https://www.onlinekosten.de/forum/showthread.php?p=2380059#post2380059 is:
Download: 48.400 Kibps (vertraglich: 51.300 kbit/s)
Upload: 9.470 Kibps (vertraglich: 10.000 kbit/s)
I would not put my hand into the fire for these numbers but they pretty much agree with my internal tests. Here is my current config (for a DTAG 50/10 @BRAS link):
config queue
option debug_logging '0'
option verbosity '5'
option enabled '1'
option interface 'pppoe-wan'
option download '46246'
option upload '9545'
option linklayer 'ethernet'
option overhead '34'
option linklayer_advanced '1'
option tcMTU '2047'
option tcTSIZE '128'
option tcMPU '64'
option linklayer_adaptation_mechanism 'default'
option qdisc 'cake'
option script 'layer_cake.qos'
option qdisc_advanced '1'
option ingress_ecn 'ECN'
option egress_ecn 'NOECN'
option qdisc_really_really_advanced '1'
option iqdisc_opts 'nat dual-dsthost'
option eqdisc_opts 'nat dual-srchost'
option squash_dscp '0'
option squash_ingress '0'
I probably should add "mpu 64" to both i- and eqdisc_opts...
Regarding your initial problem, could you test to set sqm to say 25000/5000 and restest whether the choppyness is still there? If yes this would indicate to low safety margins in your shaper settings, if not it would indicate additional issues. BTW for sqm testing it would be best if all test computers (the downloader and the VoIP device) are connected vie wired-lan ports, coppyness can easily be created by wifi links so it would be great if you could rule this out (I am not saying that wifi is the culprit in any way, only that wifi links add loads of variability that makes finding the root cause not any easier)...
The statustics look fine, but could you repeat the "tc -s qdisc" directly before and after a speedtest run (have a look at https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for how to get the most out of the dslreports speedtest to stress sqm).
From your egress cake stats I see:
that means that somehow your system assembles giant packets (basically meta packets consisting out of a bunch of normal packets belonging to the same flow which the kernel treats as one big packet to ameliorate the costs involved in routing lookups). This generally is great as it will allow the kernel to deal with higher speeds but in your case it seems less than ideal as it will cause roughly (44238) / (95001000) = 0.00372463157895 or 3 millisecond serialization delay. If you ever see larger giants the delay will increase. Again, I am not saying that this causes your choppiness issue, but it will introduce additional variance... We often see giant packets in ingress and then disabling GRO on the ethernet interface below ifb4pppoe-wan would be sufficient, but for egress you would need to disable GRO for LAN and wifi interfaces. Ad that is somewhat unfortunate as it would incur move processing cost on your router's cpu...
Best Regards
Best Regards