История изменений
Исправление kvpfs_2, (текущая версия) :
Ну одна зацепка всё же есть.
Ведь fq_codel не требует указания bandwidth. Предполагаю, что он делает что-то вроде пересортировки очереди на отправку - если от условного потока №5 пакеты поступают реже, чем от потока №2, то пакеты от потока №5 имеют больший приоритет, уходят сразу при поступлении, обгоняя пакеты потока №2 (которые хранятся некоторое время в буфере).
При этом всеь upload трафик клиентов локалки выходит из WG интерфейса, и имеет предсказуемый src ip (qdisc даже может «размотать» NAT, CAKE умеет). Так вот я подумал, что может есть какой-то qdisc схожий с fq_codel, но которому можно сказать: «смотри, вот тебе подсеть/адрес 192.168.1.0/24, все потоки от каждого хоста из этой подсети воспринимай как один flow, а не множество разных, дальше всё делай как и fq_codel». По идее, это бы решило задачу
Исходная версия kvpfs_2, :
Ну одна зацепка всё же есть.
Ведь fq_codel не требует укзания bandwidth. Предполагаю, что он делает что-то вроде пересортировки очереди на отправку - если от условного потока №5 пакеты поступают реже, чем от потока №2, то пакеты от потока №5 имеют больший приоритет, уходят сразу при поступлении, обгоняя пакеты потока №2 (которые хранятся некоторое время в буфере).
При этом всеь upload трафик клиентов локалки выходит из WG интерфейса, и имеет предсказуемый src ip (qdisc даже может «размотать» NAT, CAKE умеет). Так вот я подумал, что может есть какой-то qdisc схожий с fq_codel, но которому можно сказать: «смотри, вот тебе подсеть/адрес 192.168.1.0/24, все потоки от каждого хоста из этой подсети воспринимай как один flow, а не множество разных, дальше всё делай как и fq_codel». По идее, это бы решило задачу