Traffic shaping = rizeni provozu

[skudlik]

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 = ? .. 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.

[scorpio]

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 ...

[yaro]

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...

[Radekb]

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.

[skudlik]

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

[yaro]

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?