On DSLReports I measure 16~16.5mbit/s with cake and 18mbit/s without cake, as expected.
But my real-world download speeds (e.g. from steam or chrome) are at 12mbit/s, which testmy.net seems to agree with (albeit with some big fluctuations/variance).
ISP is Comcast and they advertise 15/2 mbit/s.
These are my configs on an ER-X:
Down: 17200kbit/s, Up: 2200kbit/s
(Ingress) nat wash dual-dsthost ingress mpu 64
(Egress) nat wash dual-srchost mpu 64
and link-layer: Ethernet with overhead 22
Everything else is left on their defaults.
For some reason, setting "Ignore DSCP on ingress" to "Allow" ups my bandwidth back to a steady 16mbit/s on testmy.net and on downloads (and DSLReports remains unaffected). The problem with leaving it on "Allow" is that most traffic is lumped into the 'Bulk' tin and sometimes in 'Best Effort' (because comcast). Some of the traffic in 'Best Effort' is bulk so per-host isolation is sort of circumvented in this way.
Any idea why letting cake do diffserv on ingress seems to up my bandwidth?
also: I noticed during my DSLReports speedtests, most traffic fell under 'Best Effort'
From my ISP, I only get 25.2/2.8 with multithreaded and 42/2.7 without multithreaded, while fast.com gives 43/30, so I would not put much stock in testmy.net (as far as speedtests go it beats speedotf.me, which routinely reports impossible numbers...), but that still leaves your observed slowdown for real downloads...
As a test, please try again without the "ingress" option (as that will reduce the measurable thoughput if you have multiple downloads going on simultaneously, which is a good thing if you want to keep latency under load in check, but for testing disabling is a good idea). Also, it would be helpful, if you could post links to your dslreports speedtest results (please see https://forum.openwrt.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for recommendations for dslreports).
Yeah, Comcast is still doing this arbitrary re-mapping into CS1? I really need to get @ldir's great copy-egress-dscs-to-ingress-packets-of-the-same-flow mode into sqm-scripts as that should defang Comcast's silliness for good.
Why, the per host isolation should still work...
That seems as expected.
as does this. Puzzling.
Please do a test with and without the ingress keyword, if you will. That still does not explain the differences between best-effort and diffserv3, but it might indicate a mechanism.
I did three tests each, and noted the total bandwidth used (Data is in MBytes)
It's just like what you said, so I'll just leave the ingress keyword out.
With no dscp, bufferbloat seems to be similar with and without "ingress", but i'll need to repeat the dslreports test more. Diffserv3 gives me occaisonal spikes in bufferbloat.
Well, Ingress shaping is less precise than egress shaping, at least if one uses a shaper designed for egress. Cake is the only shaper that explicitly allows to shape ingress. But what does that mean? An egress shaper will act such that the data it transmits is <= the configured rate, an ingress shaper such that the rate of incoming traffic will be <= the configured rate. If one wants to avoid backspill ofvexcess traffic into the typically oversized and undermanaged buffers of the upstream network device than ingress shaping is the correct solution... Ingress shaping will behave more aggressive the more flows there are and the less elastic/responsive these flows behave.
As it looks the dslteports test uses a sufficiently low number of responsive enough flows to not cause a large bandwidth sacrifice. While your other traffic seems less ideal, but to see that you will need to run a latency test while saturating your link (that could be as simple as running opkg update ; opkg install mtr ; mtr 8.8.8.8 and look at the RRT of all upstream hops before and during saturating the link).
None of this explains your observed differences in ingress behavior between best effort and diffserv3 though.
And finally, I am a strong believer in "your network, your rules", so if you are happy without the ingress keyword that obviously is fine too, as your networks admin it is your prerogative to set your desired/acceptable trade-off between bandwidth sacrifice and latency under load.
