Ah, okay, but the little pedantic person inside of me, needs to point out that you are still running double NAT unless your ISP asigns you the 192.168.0.2 as the WAN IPv4 address (which given its RFC 1918 “Address Allocation for Private Internets” nature seems quite unlikely). I would guess you have:
external public IP assigned to SkyHubWAN -> 192.168.0.0/24 assigned to SkyHubLAN and (assuming no other device is connected ot the sky hub via cable or WLAN -> 192.168.0.2 assigned to TurrisOmniWAN -> 192.168.1.0/24 assigned to TurrisOmniaLAN/WLAN
Is that correct? If yes, you still have double NAT, even though you most likely will not see any port remapping between SkyHubWAN and TurrisOmnisWAN. But as I said this should not really affect the per-internal-host-IP fairness.
Okay, especially with link layer accounting configured these values are very conservative and should work. (Heck for egress with the overhead and link layer accounted for correctly you should be able to specify 1282 Kbps, and you might want to try this). Now, if your ISP actually uses upstream shapers/policers that would be a different kettle of fish, but luckily we can sort of test for that: if you hook up your computer directly to the sky hub and use no traffic shaping/QoS at all what are the speeds you can measure against the dslreports speedtest (from that we can calculate back to the gross synch bandwidth required for the measured goodput)? (Have a look at https://forum.lede-project.org/t/sqm-qos-recommended-settings-for-the-dslreports-speedtest-bufferbloat-testing/2803 for recommendations how to set up that speedtest, but be advised that with your upstream you most likely will only be able to use 4 upstream streams).
Question: with these slightly modified settings how is your perception of shaper fairness (and how exactly are you testing that)?
Ah, 44 is quite conservative and should work to keep latency under load increases under control (during epochs of network satruration) at the cost of a slightly larger bandwidth sacrifice than you intended. You could follow the instructions on https://github.com/moeller0/ATM_overhead_detector and try to empirically deduce the applicable overhead on your link.