ale notak ... privilegovane tridy (ssh, ospf, bgp, inteaktivni gamesy, VoIP, ...) maji pridelena nekolikrat uzsi pasma, nez tridy urcene pro prenos souboru (samba, ftp(s), http(s), imap(s), pop3(s)... ) , takze pustit si na "interaktivnich" portech nejake souborovy sluzby je opravdu hloupy napad, kterym ze sebe prislusny admin udela nejen odpadlika, CZF-skudce (TM) a lamu, neziska zadnou vyhodu v propustnosti.
Podle prohlaseni "prestan teoretizovat, bud dostatecne sexy na vystrceni anteny a zkus si barevnou wifi realitu misto teorie sedivych cisco smerovacu, kde vsechno fuguje, jak ma" je videt, ze tu nekdo videl Cisco jenom z rychliku, i kdyz tim Tacem bych se neohanel s 99,99% chyb ktery tam jsou popsany se v zivote nepotkate....
Ale k veci - ja nevim, co tu tak hrozne slozite resite - vzdyt tohle naprosto elegantne rasi tzv. fair-queueing ala Cisco. Mechanismus jednoduchy - vsechny prochazejici data jsou sledovany jako jenotlive toky (flow) - v podstate totez co UDP nebo TCP session. Pakety v scheduleru jsou prioritizovany nasledovne - cim delsi paket, tim vetsi penalty a cim vice prenesnych dat za nejake primerene kratky cas v dane flow - tedy aktualni (nejlip by se hodil predpritomny cas, ktery ale cestina neumi vyjadrit) prenosova rychlost - tim opet vetsi penalty. Pakety s lepsim skore (minimalni penalty) jsou brany prednostne s tim, ze nejsou brany striktne podle tohodle ohodnoceni, ale proste pakety s horsim skore jsou odesilany primerene mene casto, pokud dojde k preplneni front.
Dusledek je ten, ze male datove toky s kratkymi pakety - typicky telnet, ssh session apod. jsou odesilany prednostne a naopak datove prenosy - typicky dlouhe pakety a velke datove toky jsou odesilany s vetsim spozdenim. Je to absolutne nezavisle na pouzitych portech nebo protokolu vyuziva to proste jen typicke znaky takovych datovych toku, takze to tezko osalite, protoze ten datovy prenos bude minimalne spotrebovavat velke pasmo.
Samozrejme jeste muze byt vhodne nektere tridy provozu specialne prioritizovat s omezenym tokem - napriklad OSPF nebo hlas, ale pak uz se dostavame na CBWFQ pripadne LLQ, coz uz jsou docela slozite algoritmy a nema se cenu s nimi zabyvat, protoze neverim, ze by se nekdy nasel nejaky koncensus nad rozdelenim provozu do trid v celem CZF.
Bohuzel nemam nastudovany vsechny schedulery v Linuxu a jejich moznosti, ale neco podobneho jako WFQ umi podle popisu scheduler SFQ a snad pomoci nejakeho sprazeni se schedulerem CBQ by to mohlo dokazat i neco jako CBWFQ.
fungovani TCP/IP protokolu neni nezavisle na tom, na cem beha - to jsem minil predchozi nepochopenou narazkou na "fungujici CISCA".
Polopaticky - nektere protokoly predpokladaji jiste chovani nizsich vrstev pro svoji optimalni funkcnost. Chova-li se nizsi vrstva jinak, nez jak predpokladano, protokoly na vyssich vrstvach blbnou. Tohle je pricinou vetsiny problemu v rozsahlych wifi sitich jako CZF. RFC-QoS, jez jsem tu popsal, tyto problemy efektivne resi. Nic lepsiho jeste nikdo nenavrhl/nedzkousel.
Jestli chces necim prispet, tak ti nezbyde, nez si to zkusit. Jinak Tve knizeci rady zpusobi akorat veseli mezi ostrilenymi wifi-pardaly
21.07.2003 v 15:40
a lamu, neziska zadnou vyhodu v propustnosti.
