QoS linux

[Peter Surda]

On Mon, Aug 12, 2002 at 01:08:19PM +0200, Martin 'MegaSoft' Mokry wrote:
> > > A ako sa potom vysporiadat s prilisnym downstreamom ? Teda okrem obmedzenia
> > > napr. na  urovni squidu. Ako na ine protokoly ? 
> > Bud regulujes upstream a dufas ze to pomoze (mam s tym dost dobre skusenosti
> > ale treba sa v tom vyznat), alebo QoS nakonfigurujes na strane providera.
> A nepomohlo by regulovat aj upsteam aj downstream na routeri?
Nie.

> Ked sa QoS nakonfiguruje aj na eth0 aj eth1 tak by to mohlo pomoct ... totiz
> TCP v pripade ze sa mu stracaju packety spomali ich odosielanie ...
Pakety sa nestracaju, len "laguju". V praxi to vyzera tak, ze router na strane
provajdera by ti mal posielat viac ako kapacita linky, takze si to napcha do
bufra, ktory standartne funguje ako FIFO. Podla velkosti buffra a inych
parametrov pretazena linka znamena ze mas zhruba 1 az 3 sekundy
round-trip-time kazdeho paketu, ktory ide cez linku. Dropovat zacne az ked je
buffer plny, potom zacne pri TCP retransmissia cim sa linka zatazi este viac
:-)

> t.j ak obmedzim rychlost prenosu packetov na internetovom rozhrani, tak by
> mal aj remote server dodrzat danu rychlost
Uvedom si, ze interne rozhranie rutra aj tak nikdy neposiela viac ako limit,
jednoducho lebo tolko ani nedostane. Ako som uz spomenul, odstranit pretazenie
mozes bud na strane, z ktorej to vychadza (provajder), alebo limitovanim
streamu opacnym smerom (netrivialne).

> .. vsak na tom principe funguju speed limity v programoch ako wget, getright
> a podobne ... 
Ano, ked mas jedno spojenie tak to tak teoreticky funguje, ked ich mas par
tisicov ako u nas tak je to naprd. Staci ked co i len jeden paket je
poziadavka o nove spojenie a uz ti budu chciet posielat viac ako linka zvlada.
A to sa bude kumulovat, lebo ked niekto nedostane odpoved, posle dalsi
request, atd.

> je to len teoreticky dohad, este som to neskusal.
Mladicka nerozvaznost :-). Pred rokom som si to myslel tiez.

> Prave idem skusit nakonfigurovat QoS na nasom vyskumnom ustave, moj prvotny
> napad je taky ze male packety (SYN, SSH, TELNET, ...) budem pustat prakticky
> bez obmedzenia a zbytok sa bude triedit do 5 classov po 20% prenosovej
> rychlosti + prepoziciavanie pasma (vysledkom by imho malo byt pasmo od 20%
> do 100%).
Dolezite je triedit to tam, kde je to prepchate. Ak mate prepchaty downstream
(typicky priklad), jedine riesenie je obmedzit ho. Ako som spominal, v praxi
sa to robi dost tazko ked provajder nechce kooperovat.

> Triedit packety chcem zatial pomocou markovania v iptables ... Este som QoS
> nikdy nenastavoval, tak ak hovorim hluposti tak ma opravte ...
Ako teoria to znie pekne, ci to pomoze si neodvazujem odhadnut lebo nepoznam
vasu situaciu. Skor nie :-(.

> A ked sa tu uz o tom hovori tak mam aj ja par dotazov:
> 
> Je na QoS nejaky nastroj na styl iptables-load, iptables-save,
> /etc/init.d/iptables ... ?
Zaujimalo by aj mna, ja som si na to napisal jednoduche skripty.

> Prezije markovanie v INPUTe maskaradu ?
Nezabudni ze sa markuje v tabulke mangle a ta INPUT nema. Markuje sa v
PREROUTING a OUTPUT, najlepsie spravis ked spravis zvlast cejn a ten pridas aj
do PREROUTING aj OUTPUT. Potom to pojde aj z maskaradou (odskusane).

> Megac
Bye,

Peter Surda (Shurdeek) <shurdeek na panorama.sth.ac.at>, ICQ 10236103, +436505122023

--
          "One world, one web, one program"  -- Microsoft promotional ad
         "Ein Volk, ein Reich, ein Fuehrer"  -- Adolf Hitler
         "Ein Auto, ein Computer, ein Mann"  -- Knight Rider
------------- další část ---------------
A non-text attachment was scrubbed...
Name: [žádný popis není k dispozici]
Type: application/pgp-signature
Size: 232 bytes
Desc: [žádný popis není k dispozici]
URL: <http://www.linux.cz/pipermail/linux/attachments/20020812/9ecc924e/attachment.sig>