ekrajnak Z bakalárky som sa naučil, že nie je problém rezať a prioritizovať, ale klasifikovať traffic. To je alfa a omega. Bez toho robiť QoS nemá zmysel.
jj, suhlasím, obacně se teď těsím na reélné výsledky nftables, protože mají hash tabulku na classify 🙂 .
map shaper {
type ipv4_addr : classid
elements = { 192.168.15.2 : 1:502, 192.168.15.3 : 1:503,
192.168.15.4 : 1:504, 192.168.15.5 : 1:505,
192.168.15.6 : 1:506 }
}
ekrajnak Ak by som robil shaper na prívode (pri vstupe tranzitu do siete) tak by som musel vytvoriť tree podľa prvkov v sieti, rádii, ... ale čo ak rádio znížilo moduláciu? Čo ak sa prepla nejaká záložná trasa s nižšou kapacitou? To sú reálne problémy.
fakt jo 😃 ale zbytečně si nemysli, že tohohle si nejsem vědom. Tohle jsou syntetické testy pro demonstrování funknosti, tak si to uvědom. Snad každýmu je to jasný. Pokud bych byl hodně pečlivý, tak na záložní trasu posadím 1SQ s PCQ aby se neucpala do totálních sraček. Nic není dokonalé, ale taky nic není černobílé.
ekrajnak A ďalšia vec. Pekná funkcie PCQ. Nastavím IP pool sektora, nastavím selektor na dst-address (download) a čakám že mám rozdelenú šírku pásma. Problém ale je, že každá interná fronta v PCQ je FIFO. To by chcelo PCQ s internou frontou SFQ. Vtedy budú môcť deti sťahovať hry a rodičia popri tom Skypovať bez dropov. Navýšenie latencie je len vecou buffera, to je prispôsobiteľné.
A to je přesně to, čeho se mi s SFQ nedaří plnohodnotně dosáhnout. Když se podíváš na ty videa s propustnostími testy za 1 SFQ třídou na natovanou přípojku, tak když ji někdo sežere z domácnosti, tak dalšímu za natem dá SFQ sice slušnou latenci, ale taky třeba jen tok 3Mbps. Na MK toho lze dosáhnout třeba tak, že do SQ stromu narveš koncové třídy s obráceným(balancuješ download podle ip z netu) PCQ nebo pak ten mnou popisovaný tc-cake. Do htb stromu na MK jsem kombinaci htb+pcq nezkoušel.
