🚀 go-pugleaf

On 25.06.2012 11:56, Slawek Kotynski wrote:
> Po wpięciu byłych klientów Astera do sieci UPC irytuje
> mnie jakość łącza
> (tym bardziej gdy UPC bombarduje reklamami "do 100Mbps!")
> bo po przejściu przez parę hopów UPC dokądkolwiek, normą
> jest 20% strat pakietów ICMP.
Straty pakietów ICMP echo nie są wyznacznikiem niczego poza wartością 
strat pakietów ICMP echo. Straty wszystkich pakietów wpływają oczywiście 
na straty ICMP echo ale to jest _implikacja_, a nie _równoważność_.

>
> Postanowiłem sobie rozwiązać następujące zadanko:
>
> Mamy do przesłania n pakietów TCP, z których każdy składa się z k
> pakietów IP (dla
> uproszczenia wszystkie są jednakowej wielkości).
TCP skaluje fragment size tak aby pasował do MTU, żeby nie spowalniać 
sprzętu sieciowego fragmentacją i nie generować niepotrzebnych retransmisji.

Tak więc pomysł jest ok, ale został już rozwiązany.

> 1. Czy nie popełniam w tym rachunku jakiegoś błędu?
Na oko rachunki wyglądają ok.

> 2. Czy procent strat pakietów ICMP można uważać za miarę
> strat w pakietach IP?
Nie.

> 3. Jakiej wielkości są typowe pakiety TCP w przypadku
> transmitowania średniej strony WWW
Jak generowanej skryptem to często po kilkaset bajtów.

> np. z grafiką
> lub flashem typu 100KB?
Zazwyczaj w rozmiarze MTU czyli ~1500.

Tylko weź pod uwagę, że "z" jest tu nie na miejscu, bo każdy obiekt na 
stronie jest przesyłany jako osobny byt.

> 4. Jakie są typowe pakiety w sesji terminalowej SSH?
Jak pracujesz interaktywnie to koło 100B.

-- 
Pozdrawiam
Michoo

Użytkownik "Slawek Kotynski"  napisał w wiadomości
Postanowiłem sobie rozwiązać następujące zadanko:
>Mamy do przesłania n pakietów TCP, z których każdy składa się z k 
>pakietów IP (dla uproszczenia wszystkie są jednakowej wielkości).
>Częstość gubionych pakietów IP wynosi p.
>O ile razy wzrośnie objętość całej transmisji?

Nie tak znow duzo, zeby marnowac czas na liczenie :-)
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 :-)

>Razem z moim rozwiązaniem znajduje się tutaj
>http://w3.askar.com.pl/PUBLIC/GubionePakiety.pdf
>Odp: 1/(1-p)^k
>1. Czy nie popełniam w tym rachunku jakiegoś błędu?

Raczej w zalozeniach.  Pakiety TCP, a w zasadzie IP rzadko sa 
rozkladane na mniejsze. Tylko w niektorych sieciach.
Wiec raczej powinienes sie skupic na wplywie na retransmisje w TCP - 
jak zginie jeden pakiet, to trzeba go powtorzyc, ale powtorka tez moze 
zginac .. i potwierdzenie tez moze zginac, ale ping mierzy juz wynik w 
obie strony zbiorczo.

Jak bardzo chcesz to policz jak wplynie na transmisje bitowa stopa 
bledow, np 1e-6, gdy sporo pakietow liczy 1500 bajtow.

>2. Czy procent strat pakietów ICMP można uważać za miarę
>    strat w pakietach IP?

Nie. Gdyby to byly kwestie zaklocen, to owszem, ale czesto jest to 
wycinka/priorytety na routerach, i wtedy moze byc roznie.
No i dlugosc pakietow jest rozna - ping jest krotki, ale mozna 
wydluzyc.

>3. Jakiej wielkości są typowe pakiety TCP w przypadku
>    transmitowania średniej strony WWW np. z grafiką
>    lub flashem typu 100KB?

Jak w komputerach  jest ethernet, to smiem twierdzic ze ~1500 bajtow 
tam gdzie jest wiecej do przeslania. Z tym ze obrazki i pliki moga 
miec rozna dlugosc i ostatni pakiet bedzie juz rozny. A jak dominuja 
male obrazki i krotkie pliki, to tych ostatnich pakietow jest sporo.

>4.  Jakie są typowe pakiety w sesji terminalowej SSH?

No ba, naciskasz klawisz, to jest do przeslania naprawde 1 bajt. Po 
ubraniu we wszystkie naglowki robi sie kilkadziesiat.
A odpowiedz .. zalezy jakie klawisze wczesniej naciskales, czy np 
"echo x" czy "cat kernel"

J.

> Mamy do przesłania n pakietów TCP, z których każdy składa się z k pakietów 
> IP (dla
> uproszczenia wszystkie są jednakowej wielkości).
> Częstość gubionych pakietów IP wynosi p.
> Jeśli zginie jeden pakiet IP, to trzeba wykonać retransmisję całego 
> pakietu TCP.
> O ile razy wzrośnie objętość całej transmisji?

Po co ci to, zwykłe programy do np. ściągania pliku biorą to pod uwagę.

-- 
(tekst w nowej ortografi: ó->u, ch->h, rz->ż lub sz, -ii -> -i)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. http://ortografia.3-2-1.pl/

W dniu 2012-06-28 21:05, Stokrotka pisze:
>
>
>> Mamy do przesłania n pakietów TCP, z których każdy składa się z k
>> pakietów IP (dla
>> uproszczenia wszystkie są jednakowej wielkości).
>> Częstość gubionych pakietów IP wynosi p.
>> Jeśli zginie jeden pakiet IP, to trzeba wykonać retransmisję całego
>> pakietu TCP.
>> O ile razy wzrośnie objętość całej transmisji?
>
> Po co ci to, zwykłe programy do np. ściągania pliku biorą to pod uwagę.
>

A pobierający opłaty za GB transfer też?

miab

W dniu 2012-06-26 20:18, J.F pisze:
> Użytkownik "Slawek Kotynski"  napisał w wiadomości
> Postanowiłem sobie rozwiązać następujące zadanko:
>> Mamy do przesłania n pakietów TCP, z których każdy składa się z k
>> pakietów IP (dla uproszczenia wszystkie są jednakowej wielkości).
>> Częstość gubionych pakietów IP wynosi p.
>> 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ę?

> 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ę?

mjk

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.