HTB versus HFSC - měření od oka (diskuse)

[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