HTB versus HFSC - měření od oka

16.12.2006 02:53 | Přečteno: 2339× | Shaping | poslední úprava: 16.12.2006 12:13

Zajímalo by mě, proč htb omezuje nepřesně, vždy s nějakým úbytkem. Zkoušel jsem měřit jednotlivé rychlosti a odychylky od definovaných hodnot. Omezoval jsem JEN jednu třídu a do ní směroval provoz. Testoval jsem stahování (wget a také přes firefox) 100MB souboru z http serveru na stroji co shapuje. Skutečná hodnota stahování je vždy o 7,4% menší než hodnota definovaná. Takže pokud chci rychlost 1024 kb/s a zadám 1024, dostanu 1024/1,074= cca 953, ale já chci 1024, takže musím logicky těch 1024 vynásobit 1,074 a vyjde mi hodnota kterou musím definovat htb. Dále jsem chtěl zjistit jak je na tom hfsc. Zjistil jsem že úplně stejně, takže nevím co dělám blbě a proč jsou hodnoty odchylek pořád stejná procenta. Pro shaper je 1B přibližně 8,6bitů, takže když si vezmeme vyšší rychlosti, už je tam znát, že nabízené 4096 to určitě nebudou, s vyšší rychlostí je ten propad přirozeně vyšší a to mě štve. Navíc htb při rychlosti 16384 začalo skákat a průměrně byla výchylka mnohem větší než u hfsc. Větší rychlosti jsem vzdal, už to asi nestíhal disk v notebooku do kterého jsem to stahoval, takže by to byly nesmysly. Ale u té 16384 i 8192 kb/s to bylo hezky znát, že htb je rozhozené, četl jsem něco o nějakých parametrech co se musí měnit v závislosti na rychlostech, ale když to hfsc umí bez nich, jedině lépe. Řekl bych že ten test moc o výkonu htb - hfsc nevypovídá, protože je jasné že za jiných podmínek by to asi bylo jinak. Mě šlo primárně o tu výchylku od definované rychlosti.

Hodnoty jsou ty co tam byly skoro stabilně, zaokrouhleno.
Soubor stahován asi 30 vteřin, což na odečtení ustálené rychlosti stačilo
HTB
----
16384 kb/s - 1700 KB/s
8192 kb/s - 910 KB/s
4096 kb/s - 480 KB/s
2048 kb/s - 240 KB/s
1024 kb/s - 120 KB/s 
512 kb/s - 60 KB/s
256 kb/s - 30 KB/s
128 kb/s - 15 KB/s

HFSC
----
16384 kb/s - 1880 KB/s
8192 kb/s - 960 KB/s
4096 kb/s - 480 KB/s
2048 kb/s - 240 KB/s
1024 kb/s - 120 KB/s 
512 kb/s - 60 KB/s
256 kb/s - 30 KB/s
128 kb/s - 15 KB/s

Trápí mě to také proto, že měřáky typu dsl.cz, rychlost.cz jsou pro všechny relevantní a mě ta ručička vždy zůstane viset kousek pod hodnotou co tam má být. Budu tedy muset každou hodnotu naddimenzovat o 7,4%? A co když mám od poskytovatele právě tu horní mez?        

Komentáře

[trekker.dk]

Napadá mě, jestli náhodou to zpomalení nemá nějakou souvislost s přenosem servisních dat (tj. potvrzovací pakety, hlavičky a kontrolní součty v IP paketech apod.)

[agnostic]

Když už vám jde o přesnost tak je to 7.4%
Jinak to vaše pátrání po "ztracených" datech - každý protokol má svoji režiji, prostě kousek uzme pro sebe. Nápad, že měření vynásobíte nejakým koeficientem není moc dobrý - různě velké pakety mají různou režiji, takže nikdy nebudete vědět přesně jak ten koeficient má být veliký.

[LFCIB]

Dobrý den, ten koeficient souhlasí při všech rychlostech. Ukázalo to měření. Je pořád stejný až do doby těch 16Mbitů, pak htb začne blbnout, hfsc drží. Pokud jakoukoliv rychlost naddimenzuji o ten koeficient, při stahování mám pak tu "správnou" rychlost kde jsou B a b ve správném poměru. Myslím, že jsem tím simuloval stahování po http což řeším

ad 7.4% - samozřejmě - omluva

[agnostic]

Ono taky velikost paketů většinou tolik nezávisí na rychlosti, ale na použitém protokolu. Zkuste nějaký VoIP software, který používá malé pakety a poměr bude jiný nebo třeba zmenšit MTU. Dobrý software na sledování statistik velikosti paketů je nejspíš iptraf (statistical breakdown, by packet size).

[LFCIB]

MTU mám default 1500. Zkusím to zmenšit a otestovat. Díky

LFCIB

[Michal Kubeček]

Těch 7.4 procenta se mi ale moc nezdá. Při přenášení velkého souboru HTTP nemá režii žádnou (tam je jen hlavička dotazu a odpovědi na začátku a pak už data proudí, jak jsou), TCP i IP hlavička má typicky 20 B (občas o něco víc kvůli rozšířením) a obvyklá hodnota MTU je 1500 B. Takže by to mělo být něco kolem 1500/1460, tj. asi 1.027. Pokud tazateli vychází skoro trojnásobek, má buď výrazně nižší MTU nebo je tam ještě nějaký další efekt.

[agnostic]

To bude tím, že zanedbáváte režiji TCP protokolu...

[Michal Kubeček]

S TCP hlavičkou (typicky 20 B, ze začátku o něco málo víc) jsem počítal, jakou další režii máte na mysli?

P.S.: režie - režii

[agnostic]

Máte pravdu, měl jsem za to, že je to víc. Další věc co by to mohla být reakce na dropnutí nějakého packetu (RED?) a třeba čekání na ACK (to bude asi zanedbatelné), moc do toho nevidím, tak doufám, že moc neplácám

[Michal Kubeček]

Zahozené nebo ztracené pakety by samozřejmě k dalšímu zpomalení vést mohly, ale zdá se mi nepravděpodobné, že by ten poměr byl pořád stejný, a to dokonce i pro různé rychlosti. ACK tady nehrozí, protože jednak ta potvrzení klientovi server posílá přímo ve svých paketech, jednak stejně nemá co potvrzovat, protože u HTTP obvykle během stahování souboru aplikační data běží jen jedním směrem.

[LFCIB]

Dobrý den, mám server v ostrém provozu a přesně se tam projevuje tento úbytek. Sitovky 3com a realtek. Na testovani mam jiný počítač a chová se to stejně. Scripty mám nastavené standardně, žádné extra buřty.

Pokud by měl někdo možnost otestovat také, byl bych vděčný za zpětnou vazbu. Díky

LFCIB

PS: vyzkouším jak se to chová třeba na ftp a napíšu sem výsledky.

[Michal Kubeček]

Mezi FTP a HTTP by neměl být žádný rozdíl, tam se to liší jen na začátku (a na konci), jinak oba protokoly posílají po TCP spojení soubor bez jakýchkoli modifikací. Tedy pomineme-li u HTTP možnost posílat soubor komprimovaný.

[LFCIB]

MTU 100: 53 KB/s
MTU 200: 88 KB/s
MTU 750: 115 KB/s
MTU 1500: 120 KB/s

Dle mých očekávání.

Víc z toho přes MTU nedostanu.

LFCIB

[petr_p]

Jenze v IPv4 se zacnou pakety fragmentovat. Zkuste namisto rychlosti na aplikacni vrstve merit rychlost na sitove vrsteve (tj. payload linkove vrstvy). Nejjednodussi je odecist cislo z vypisu netstat -i.

Vasich 7,4 % pri MTU 1500 B predstavuje 111 B, coz je zhruba rovno 2*(IP+TCP hlavicka). Pro inspiraci se podivejte sem (ale moc jim neverim, protoze ja mam TCP/IPv6 pakety kratsi [40+40+42/S+SA+A] nez TCP/IPv4. [60+60+62])

[LFCIB]

MTU mám 1472(1500)

LFCIB