@strannik Why would you want to do something like that? Too complex, you would be underutilizing you bandwidth, and it won't be fair anyways. I'm pretty sure that the configuration presented on the first message up there would manage bandwidth, fairness and latency much better than that. With this, it would be impossible for one user to "hijack" all of the bandwidth. Of course, if other users are not using much of the bandwidth at all, it can look like one user has hijacked the link, but in reality he's just using the bandwidth that no one else is using anyways. You want that to happen. Why would you pay for a 800 Mbps link to download at 100 Mbps if you could be using almost the 100% of it? The whole point of traffic shaping is to be able to share bandwidth between all users in the most efficient way, fairly, and for latency-critical protocols to continue to work well even when the link is under heavy load. This seems to accomplish this task quite well.
In a "live" network it's hard to see if the bandwidth is being fairly shared, because the hosts are likely not even attempting to download at the same rate (using different amount of connections/flows, using different protocols, etc), they're downloading from different servers with different bandwidth and different amount of clients connected to them, etc.
That said, i have seen several times in the traffic graph than two PCs from LAN were downloading at nearly the same rate. And bandwidth tests off-hours when the link is not utilized should show good "host fairness" with this configuration, even if not mathematically perfect.
Just check that the per-IP queues are being created in the way you think they are in the limiter diagnostics (the default scheduler shows this), check the firewall logs to see if the traffic is hitting your rules correctly. Test off-hours when you can control which PC or PCs are downloading/uploading, etc.
It's odd that you continue to see problems when switching schedulers in 2.8.1, even after restarting. I didn't found such issues. At most you could need to reset the state table. You could try to delete all limiters, restart and create them from scratch, to see if that fixes the odd behaviour.
Or if you continue to find such problems, you could resort to keep one set of FQ_Codel limiters and another set of limiters with the default Scheduler (for testing). Then you only need to modify the Queues configured on the rules to apply one or the other.
