Normally you start with shaping upload only (set ingress to 0) , by splicing up from half of bandwidth, and taking one step back when loaded upload latency starts to grow.
If you are on something like cortex a53 or ramips you stop here if dl mahically got improved, but you have virtually unlimited CPU so you can repeat the excersise with ingress too.
For x86 - check if network card has multiple interrupts (cat /proc/interrupts) - if so seplace packet steering with irqbalance.
I suggested a more pedantic approach - if netcard driver spreads packets across all cores there is no practical need to do extra roll with explicit steering them again.
A bit more testing and this might be the best result yet, i did follow @brada4 disabled packet steering but kept irqbalance enabled, and also your notes @moeller0:
Dave Taht (rip) gave advice about using ack-filter but only if your connection is very asymmetric, something like your download being 20x higher than upload speed which usually only happens on DOCSIS. I don’t believe this should be used on a 550/550 connection like yours.
Yes, you completely control upload direction, download direction is mostly managed by your provider, you just delay/drop/ecn few packets to slightly affect stream speeds to avoid saturating their buffers.
ACK Filtering supposedly helps if:
a) your egress is much lower than the ingress so egress ACK traffic (typically aroubd 1/40 of forward data traffic) consumes a noticeable fraction of egress capacity, then ack filters frees some of the egress capacity for actual data traffic
b) you are on a quite bursty medium where the ACK traffic is bunched up and you essentialky release a number of ACKs for a given flow simultaneously, so the ACKs are truly redundant and do nog help flow control any better than replacing a flight of such ACKs with the most recent one.
in prctice I would try fair testing to assess its utility on a given link by running test with and without ACK filtering back to back.
puzzled in your shaper setting there egress is roughly at 90% of ingress, but in the libreqos test we see more like 20% of ingress, what happened there, did you test with different shaper settings?
That’s a good observation. The variance in this libreqos testing is leading me to believe there are bugs or capacity constraints with the tool. Waveforms test seems much more reliable
One thing waveform does is reporting the difference in the mean RTTs between idle and the two load conditions, while the LibreQosS tests reports the more sensitive difference between the 5%-ile during idle with the 90%-ile RTTs during the load epochs, that way latency spikes have a much larger influence in the libreqos test. That IMHO is a good thing, as such latency spikes also degrade the perceived quality of a number of interactive use cases, but it does creat situations where the waveform test looks "better", but simply by reporting a different metric, from the "Detailed Statistics" field you can calculate what waveform would report, +0.5 down and +3.8 up...
Personally I think I like the LibreQoS test better even though it will be less repeatable..
Regarding shaping only one direction, that can occasionally help, e.g. on a heavily asymetric links where an underpowered router might not be able to shape the higher capacity direction anywhere close to the contracted rate... (personally I would always test whether the link might not feel actually more useful with an sqm instance and lower capacity than without sqm bug higher capacity).
Ingress shaping is a bit more approximate than egress shaping, because there is always the chance of traffic backspilling into the ISP-side buffers of the access link. The smaller the differencf between the true bottleneck rate and the shaper rate the more likely backspill events will be, and since the ISP side buffers typically are both oversized and undermanaged these likely result in noticeable latency spikes.
it appears to top out B/W lower then the ingress, however if i use speedtest.net or fast.com, the speed measured is around 538/538.
@moeller0 based on this what would you set egress value to?
About the router spec its X86 N100, it should have enough processing power to hit around 2gb i think. But i dont know if there is any specifc packages other then irqbalance i should have considered, i just took the default in firmware-selector.
also another unexplainable test. From laptop lan connection disabled IPv4, and had this run IPv6 only and the results seem to be better then when ipv4 and ipv6 were enabled. I also tested on ipv4 only and the loaded latency for both was around 19ms so perhaps the upload higher latency was doing ipv4 on the upload and ipv6 on the download?
