> 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. -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
