test ztratovosti packetu

[Radim Kolar]

> tomuto neverim, ze svy zkusenosti i z technickych reportu je
> ztratovost do cca 5% vetsinou OK vzhledem k TCP a plynulosti; zavisi to
> samozrejme i na dalsich faktorech. Nad to to uz muze byt velky problem.
5% ve spicce je vicemene ok i kdyz nezkousel jsem to s videem zda se
jiz nezacina trhat, ale 5% plr average plr /den bude znamenat
mininalne 30% plr ve spickach a to uz je nepouzitelny. Web ktery ma
600kbit average potrebuje tak 3Mbit aby vykryl spicky, web traffic je
kratkodobe dost burstable. (dalsi duvod pro nastavovani
maxspareservers alespon na 30)

dnesni dedicated linky maji uz nastesti plr close to zero pokud se
nepresvihne jejich bw a pokud se presvihne tak se koupi rychlejsi
linka, produkcni server na to s prehledem vydela.

Test na dedicated lince ve spicce:

--- old.filez.com ping statistics ---
1033 packets transmitted, 1030 packets received, 0% packet loss
round-trip min/avg/max/stddev = 36.330/37.711/51.913/1.513 ms

pravda s ping -f je plr trochu vyssi:

--- old.filez.com ping statistics ---
1017 packets transmitted, 1012 packets received, 0% packet loss
round-trip min/avg/max/stddev = 35.818/36.988/47.069/1.303 ms

> Neverim ze lag 0.3-5 sekundy ve spojeni muze byt zpusobem ztratou jednoho
> paketu na siti, ktera jinak vrati pozadavek za 1ms. To bude jiny problem.
ne. aplikacni server vrati stranku za < 1 ms, k uzivateli je prumerny
ping tak 38ms-55ms, pokud zrovna neni ve stejnym meste tomu pak ta 1ms
tak odpovida.

Tyhlety pripady se hezky ladi packet analyzerem, ktery pracuje na TCP
urovni a ukazuje kolik packetu se ztratilo/spojeni a lagy na TCP
spojeni zpusobene ztratou packetu. Je to asi jedina moznost jak
spolehlive urcit zda video bude lagovat ci ne a kolik bw je potreba
aby se pokryla spicka, protoze operuje nad realnymi daty.