Dost lidi zajimalo "jak to vlastne funguje", tak se pokusim shrnout co se to tu vlastne snazim nasadit. :wink:   (zkratky uvedene velkymi pismeny v zavorkach jsou druhy algoritmu pouzitych pri implementaci)

Maximimalni rychlost pro spoj[/b]

Zakladem systemu je pevne nastavene maximum pro kazdy (wifi)spoj. Toto maximum momentalne zadavam manualne - podle toho jak dana linka funguje - trebas takova midway-door uz moc "ne"funguje nad 2M celkoveho trafficu (half-duplex). Jako vylepseni planujeme zavedeni dynamicke hranice v zavislosti na pingach. Plati totiz, ze kdyz je wifi na maximu, tak odezvy na pingy jdou zavratne nahoru (cisla v oblastech 500-1500ms nejsou vyjimka) coz v posledni dobe videl snad kazdy.    

Rozdeleni linky[/b]

Linku delim (HTB) na 4 zakladni tridy : 1 servisni + 3 uzivatelske

Servisni trida ma nejvyssi prioritu, ale je omezena na rychlost - takze by nemela jit moc dobre zneuzivat uzivateli. Svistej po ni pingy, dns, ssh, snmp, routovaci protokoly.

3 uzivatelske tridy jsou:

rychle uzivatelske pasmo - smi pouzit 70-100% celkove linky.
stredni uzivatelske pasmo - smi pouzit 20-100% celkove linky.
pomala uzivatelske pasmo - smi pouzit 10-100% celkove linky.

Funguje to tak, ze pasmo ma "jistych" svych 70,20,10% a pokud nektere nepouziva celou svoji kapacitu, tak ho pujcuje ostatnim.

Kazde z techto pasem se dale deli na dalsi podtridy. Deleni probiha zatim podle portu :
- interaktivni - hry + veci, co potrebuji rychlou odezvu
- data - www, ftp, mail
- ostatni.

Priorita klesa od zhora dolu - tridy si deli rovnomerne linku sveho pasma. Ve finale se v kazde teto male "krabicce" rozdeli traffic mezi uzivatele, co do ni spadnou. Deleni bude probihat podle IP adres.(ESFQ) - momentalne je to podle spojeni (SFQ)- vydelavaj no tom ti, co pouzivaj download akceleratory a spol.). Dalsi veci, ktera je ve vyvoji je klasifikace P2P paketu podle obsahu a jejich zarazeni do vlastni skupiny.

Zarazeni do uzivatelskych pasem (rychle, stredni, pomale)

Zarazeni zajistuje program, ktery na routeru sleduje traffic jednotlivych clenu, ktery protece pres tento router. Sledovani se uchovava za cca hodinu zpet - uklada se do "fronty" - takze program vi, kolik toho slo od/k uzivateli za posledni hodinu. (sampluje se to zhruba po 5-10 minutach). Jakmile presahne clen prvni kritickou hodnotu (momentalne 15M) je zarazen do stredniho pasma. Jakmile presahne druhou (50M), tak se dostane do pomaleho.  

Zarazeni do pasem je pro nekoho "nevyhodne" pouze pokud je linka vytizena. Jestlize neni vyuzita kapacita vice priorizovanych skupin, tak samozrejme i nekdo v pomalem pasmu muze vyuzit 100% linky.

Cilem je, aby system bezel na kazdem routeru. Tudiz clenovi bude  limitovana pouze urcita linka (resp. traffic pres urcite AP) - pokud bude mit treba velky traffic ven do netu, tak bude omezen pouze na teto lince ven, ale napr. na jine lokalni AP nebude vubec limitovan.

Implementovane uz to nejak tak nahrubo mam. Ted delam monitoring - aby bylo mozne pres www sledovat, kdo ma kolik nasosano na damem AP.

Uvitam jakekoli pripominky, napady .. proste cokoli by pomohlo tento system zdokonalit.

Skudlik.

Jak můžu zneužít tento systém pokud mám více přidělených IP adres?

Asi nebude problém omezovat to v souladu s nějakou databází členů,
místo podle IP adresy?

Citace: "jo"Jak můžu zneužít tento systém pokud mám více přidělených IP adres?

Asi nebude problém omezovat to v souladu s nějakou databází členů,
místo podle IP adresy?

Pri pocitani kolik toho kdo prenesl vychazim z databaze IP jednotlivych clenu (tzn. i kdyz ma nejaky clen vice IP ci subnetu, tak se mu to nascita dohromady). Vlastni deleni uvnitr trid probiha uz jen podle unikatni IP adresy , takze na tom "vydelavaj" ti co jich maji vic ... ale pouze v ramci sveho aktualniho pasma. Skutecny dopad by tak mel byt minimalni. Jakmile totiz nekdo nasosa hodne a linka je vytizena, tak se propadne do pomaleho pasma, a jeho vic IP adres mu pomuze akorat v boji o linku se svymi konkurenty v tomto pasmu.

jo je to hezky, je to dobre ze uz to funguje.

Citace: "Vilik1"jo je to hezky, je to dobre ze uz to funguje.

Takže už můžu vypnout Netlimiter při nějakém větším stahování  :?:

Radeji si ho nech zapnuty...

Zajimalo by me ,jestli ma vyssi prioritu komunikace po LAN (tj. mezi adresami 10.102.*.*) oproti komunikaci s internetem ?
Dale jakou prioritu ma VoIP (jako gamesy nebo http,ftp nebo ostatni) ?

Citace: "fstembera"Zajimalo by me ,jestli ma vyssi prioritu komunikace po LAN (tj. mezi adresami 10.102.*.*) oproti komunikaci s internetem ?
Dale jakou prioritu ma VoIP (jako gamesy nebo http,ftp nebo ostatni) ?

Adresy nesouvisí s tim, jestli je to LAN nebo ne.

Zkouším VoIP, mám Sipuru 2100 a potýkám se s velkou nespolehlivostí, často jde totiž jen o komunikaci ke mně, na druhé straně slyší jen "bublání", jakoby dávkový přenos toho co říkám (a nezávisí to na kodeku). Znamená to, že to mohou být zrovna chvíle, kdy jsem zrovna v pomalém pásmu? Ale mně to nefunguje i ve chvílích, kdy jsem před tím žádné megabajty dat nestahoval (že by kolegové na společné anténě?). Mám dvě IP adresy – nicméně pochopil jsem, že kdybych použil jednu jen pro VoIP a druhou pro přístup na net, tak si stejně moc nepomůžu.
Jaká je tedy možnost vyzkoušet, jestli by pomohla priorizace portů pro RTP pakety – tedy jestli to jde? Možná je to blbost, já do toho zas tak nevidím – ale četl jsem, že telefonování přes SIP se bude do budoucna podporovat ve spolupráci s 802.VOX a pokud RTP pakety budou závislé plus mínus na tom v jakém bude uživatel náhodou pásmu, tak bude zřejmě VoIP nespolehlivé...
Co přiřadit pro VoIP IP adresy s vyšší priorizací? (Dá se ale pak zabránit jejich zneužití např. pro download?)

Priorizace podle sluzeb se v nove verzi traffic shapingu az na systemove vyjimky uplne rusi (moc se to neosvedcilo). Navic porad by kazdy chtel neco priorizovat - takovy stav neni moc unosny (a hlavne vyhledove celkem snadno zneuzitelny, pokud by se zarazovani provadelo pouze podle portu --- staci nastavit P2P klienta aby fungoval na techto portech a veskara priorizace je o nicem).

Nove (bezi to jiz nejakou dobu v testovaci fazi na nekolika routrech) bude mit kazdy jakesi garantovane minimum a take bude mit prisneji dany strop, kdy mu to rychleji nepobezi. Toto reseni je mnohem vice restriktivni nez stavajici system, kdy lze vyuzivat komplet celou linku, ale zatim neznam jine reseni, jak zarucit prave rozumne odezvy prave treba pro telefonii nebo pro hrani her.

Rozepsal jsem clanek na web, kde jsem se to pokousel trosku vysvetlit, ale ted o zkouskovem neni cas, abych to dotahl do konce, tak zatim neni vydan.

Pro zajemce je torzo k nahlednuti na:

https://twiki.klfree.net/twiki/bin/view/Sandbox/JanSechovecSandbox

Citace: "skudlik"

Pro zajemce je torzo k nahlednuti na:

https://twiki.klfree.net/twiki/bin/view/Sandbox/JanSechovecSandbox

Nahlizel jsem. Mas pravdu, asi to fakt jinak nejde nez jedna "po hube"

Citace: "skudlik"Nove (bezi to jiz nejakou dobu v testovaci fazi na nekolika routrech) bude mit kazdy jakesi garantovane minimum a take bude mit prisneji dany strop, kdy mu to rychleji nepobezi. Toto reseni je mnohem vice restriktivni nez stavajici system, kdy lze vyuzivat komplet celou linku, ale zatim neznam jine reseni, jak zarucit prave rozumne odezvy prave treba pro telefonii nebo pro hrani her.

Co si můžu pod garantovaným minimem představit? Je to laťka, která by nám zoufalcům, co jim VoIP na SIPu funguje/nefunguje pomohla k lepší funkčnosti než nyní?

jde to nastavit dle moznosti v danem miste .. cca 128kbit by nemel byt problem snad nikde.

Citace: "skudlik"... cca 128kbit by nemel byt problem snad nikde.

to je cca 10-16 KB/s ...
... ooo to je zradlo, to je 2x - 3x rychlejsi nez vytacenej modem !!!

Citace: "scorpio"... ooo to je zradlo, to je 2x - 3x rychlejsi nez vytacenej modem !!!

Chtel si VoIP, tak na reziji kodeku ti tohle staci, ne? :)

Citace: "scorpio"to je cca 10-16 KB/s ...
... ooo to je zradlo, to je 2x - 3x rychlejsi nez vytacenej modem !!!

No jak jsem psal .. je to garantovane minimum. Ono pro jeho vypocet staci fakt docela jednoducha matematika [asi se uz docela opakuju]. Jsou AP (a neni jich malo), kde na jednom wifi sektoru/vsesmeru jede 30-40 lidi.

Klasicka wifina dokaze rozumne bez narustu odezvy dat cca 2Mbity na download (v zarusenych oblastech ani tohle ne). Tahle kapacita se samozrejme MUSI NEJAK ROZDELIT mezi pripojene lidi. Kolik vychazi na jednoho clena ? ... Kdyz vecer bude aktivnich cca polovina z pripojenych lidi (celkem normalni stav). Tak 2048k / 20 = ? :D .. Tezko muzu "garantovat" vic nez mam k dispozici. Na tyhle rychlosti "by se to melo" rozdelit v pripade, ze bude sosat tech 20 lidi soucasne (bohuzel realita byva jina).

Druha vec kterou muzu nastavit je strop = omezeni maxima ktery nepujde prekrocit. Tady je to o hodne slozitejsi nez v predchozim pripade. Tuhle vec je potreba nastavovat prave z duvodu toho, ze se wifi nechova v zadnem pripade idealne (ruseni, klienti se spatnym signalem, odrazy = alchymie). V idealnim pripade by mohl byt strop prave ty 2Mbity aby se rozdelilo vsecko co mam k dispozici. Jenze ono to zdaleka idealni neni.

Takhle se chovala predchozi verze shaperu, ktera se snazila rozdelit veskerou dostupnou kapacitu. JENZE bezne se stava, ze pak to nekdo muze "smazit" skoro full speedem a ostatni si neskrtnou. Duvedem je to, ze lidem napr. s horsim signalem muze v pripade vytizeni narust ztratovost paketu a pak jim to nebezi proste z tohodle duvodu a shaper, kterej je o uroven vejs (vi kolik kdo prenasi dat a podle toho ho omezuje) uz do toho vicemene nezasahuje, protoze z jeho pohledu tenhle clovek proste neprenasi data, tak nema cenu limitovat ty co zrovna sosaj. Naopak jim rozda to co ti se spatnym signalem nevyuziji.

Co bych chtel vyzkouset, je dynamicky upravovat limity napr. podle toho kolik je v soucasne chvili aktivnich lidi (inspiraci mi byl system zavedeny ted nove v Unhosti). Novy shaper byl kritizovan hlavne z duvodu toho, ze omezuje (maximem) priliz i v situaci kdy rekneme ve 3 rano chtej sosat 2 stahovaci ze 40ti lidi na AP. Ted je serizne na "relativne" nizkou hodnotu. Uz se tu naslo par jedincu, kteri toto nebyli schopni akceptovat. Ze jim to proste ani v noc nebezi vic jak treba 600kbit/s (viz pro znale kauzy Uplet, Arigato - rozbabravat to tu nebudu).. Zavedeni prizpusobovani se poctu aktivnich lidi by tohle "mohlo" zlepsit .. je to ale potreba otestovat. Zase hrozi situace, ze dojde k pretizeni a jsou mezi nama take ti co po nocich hrajou treba online hry .. a mit ping 500+ms je urcite nepotesi ... Tezko rozhodnout, jestli podporovat "dobrotive stahovace", kteri treba s ohledem na ostatni pres den omezuji/vypinaji stahovani, nebo "nocni hrace"  co si chtej po narocnem dni zahrat nejakou odreagovacku po netu a potrebuji na to rozumny ping..... O telefonistech radsi nemluvim :))) ty potrebujou rychle odezvy porad ..

Uff .. no sem se zase trosku rozepsal :)) kazdopadne jsem rad za jakykoliv namet do diskuze.

Rad bych k tomu napsal vic, ale dostanu se k tomu lip az vecer.

Nicmene, s tema hrama je to fakt, smazim na Rebece II (Rebus, vsesmer rebeca.south WiFi) skoro kazdej vecer Raven Shield a nekdy jsou ty odezvy HROZNY ...

Ale, na druhos stranu, zrovna RS ustoji az minutovou odmlku serveru, takze uplny vypadnuti mam hodne zridka ... ale obcas me to "surove" vrati o kus zpet, nebo chcipnu a nevim "za co" ... pac jsem ho ani nevidel  :shock:

Pro IP "telefonii" pouzivam GoogleTalk - coz je jen 1:1 sound chat, a to jede celkem dobre i pri spatny lince ... potrebuje kolem 3.5 KB/s up/down.
TeamSpeak uz trpi mnohem vic ... o cupals a prenosu obrazku z webkamery nemluve  :roll:

Taky jsem se prerozepsal ... vic vecer ...

Citace: "scorpio"Pro IP "telefonii" pouzivam GoogleTalk - coz je jen 1:1 sound chat, a to jede celkem dobre i pri spatny lince ... potrebuje kolem 3.5 KB/s up/down.
TeamSpeak uz trpi mnohem vic ... o cupals a prenosu obrazku z webkamery nemluve  :roll:

Taky jsem se prerozepsal ... vic vecer ...

No, v Česku bych za seriózní IP telefonii považoval jen SIP protokol s kodekama G.711, 726-32, 729, 723...  , takže je potřeba trošku víc než 3.5KB...
Běžně potřebuje člověk veřejné telefonní číslo a většinou tedy nějakého "operátora".
Nemyslím si, že SIP je nějaká "výhra", ale VHS-ka taky kdysi zvítězila a ne kvalitou... , jasně že se dá použít proprietární řešení, ale to si pokecám zase jen většinou s tím, kdo má stejný SW... Ani "vychvalovaný" Skype není žádné super řešení se svými INy a OUTy (až mi zajistí bezproblémové finanční transakce, číslo, na které se z venku dovolá jako na české a telefonování bez zapnutí pecka, tak možná...)
Jo, zrovna mi volali zvenku přes HA-vel, mám tam G.729 a zase jsem slyšel jen já a druhá strana prd...

Citace: "skudlik"Priorizace podle sluzeb se v nove verzi traffic shapingu az na systemove vyjimky uplne rusi (moc se to neosvedcilo). Navic porad by kazdy chtel neco priorizovat - takovy stav neni moc unosny (a hlavne vyhledove celkem snadno zneuzitelny, pokud by se zarazovani provadelo pouze podle portu --- staci nastavit P2P klienta aby fungoval na techto portech a veskara priorizace je o nicem).

Je jiste, ze by to asi slo zneuzit, ale nevim, jestli se VOIP bez priorizace obejde.
Ja nemam problem se sirkou pasma nebo odezvou (stahovani bezi treba 150 kBps), ale stejne si nezavolam. RTP pakety nejak neprojdou (i kdyz zrovna nestahuji). Takze nevim, jestli by nejaka garantovana sirka pasma pomohla.
Leda ze by RTP porty byly v soucasne verzi shapingu znevyhodneny (jak uz jsem psal jinde, jsou to aspon u mne porty mezi 16384 a 16482).
Mohl bys, prosim, napsat, jak to s temito porty dneska je? Jsem na Vezaku.

nejsou nijak priorizovany .. tudiz maji pomyslne nejmensi moznou prioritu.

Citace: "skudlik"nejsou nijak priorizovany .. tudiz maji pomyslne nejmensi moznou prioritu.

"Chudáci porty... :-(". A co to u někho, komu to nefunguje vyzkoušet s tou garantovanou šířkou pásma a taky s priorizací, co z toho zafunguje?