🚀 go-pugleaf

Dnia Wed, 04 Jul 2012 19:20:22 +0200, Slawek Kotynski napisał(a):
> W dniu 2012-06-26 20:18, J.F pisze:
>>> O ile razy wzrośnie objętość całej transmisji?
>> Nie tak znow duzo, zeby marnowac czas na liczenie :-)
> 
> No właśnie wydaje mi się, że czasem ma znaczenie dużo większe, niż
> by się na pierwszy rzut oka zdawało.
> 
> Michoo wcześniej napisał:
> "TCP skaluje fragment size tak aby pasował do MTU", ale możemy
> wziąć "IP" w cudzysłów, i jeśli problem dotyczy gubienia pakietów
> w warstwie fizycznej (jakieś optyczne ATM na przykład) to są one
> dzielone na dużo mniejsze kawałki, więc jeśli straty wynikają
> z przeciążenia fizycznego łącza, to moje widzenie problemu
> chyba ma sens, i chyba widać, że przy dociążeniu kanału
> problem narasta kaskadowo - gwałtowny wzrost prób retransmisji,
> dobija kanał dokumentnie ... mylę się?

Mylisz sie. Jesli sie pakiet zgubil, to TCP przestaje transmitowac.
Na chwile, ale jednak przestaje - musi chwile zaczekac bo pakiet moze
jeszcze nadejdzie. Ten czas jest zreszta zmienny i dobierany do lacza.

Przeciazony kanal niekoniecznie oznacza gubienie pakietow, moga one po
prostu czekac na swoja kolej gdzies w buforze po drodze. TCP wtedy powinno
zwolnic nadawanie, gdyz i potwierdzenia przychodza wolniej. 
Jesli czas opoznienia pakietow w kolejkach jest mniejszy niz czas timeoutu
z poprzedniego akapitu, to efektywna predkosc jest jednak wieksza niz w
kanale z bledami. 
Ale tu zaleznosci sa bardziej skomplikowane i to nie musi tak pieknie
dzialac. No i jak w routerach zabraknie pamieci na kolejki pakietow, to
zaczynaja one ginac, tak jak w kiepskim kanale - i niekoniecznie
przeciazonym.


>> Problem jest inny - poki lacze jest bezbledne, to nawet powolne dziala w
>> miare sprawnie ( ile oczywiscie nie uprzemy sie gigabajtow przez modem
>> przepychac).
>> Jak sie zgubi jeden pakiet, to zanim TCP sie zdecyduje na retransmisje,
>> to mija pewien czas. I na ten czas transmisja zamiera, glos milknie,
>> obraz staje, w quake giniesz i nie wiadomo dlaczego :-)
> 
> No ale to ma znaczenie tylko przy wymogach "czasu rzeczywistego".
> Przy dużych transferach raczej bez znaczenia.
> 
> Sprawa mnie męczy, bo trudno ją gdzieś znaleźć dobrze rozpracowaną,
> a z doświadczenia wiem, że jeśli pojawiają na trasie straty ICMP
> typu 20% to czas przesyłania kilkunastu megabajtów może wzrosnąć
> dobre kilka razy. Może ktoś podać inną teorię?

To jest ta sama teoria - TCP jest tak pomyslane ze wysyla pakiety w miare
na okraglo, bez przerw. Ale wystarczy jeden zgubiony pakiet, zeby trzeba
bylo poczekac przez zalozony czas - a on jest z reguly dosc dlugi, i
lacznosc na chwile przystaje.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

J.