Forum Debian Users Gang

Mi chodzi o ten zegar w TCP, który jest odpalany w momencie wysyłania pakietów i odlicza jakiś czas na otrzymanie pakietu ACK. W momencie gdy zegar wybije 0 i nie zostanie dostarczone potwierdzenie odebrania pakietu, to ten pakiet jest uznawany za zaginiony i przy tym jest retransmitowany. Z tego co czytam, to chodzi o "ziarnistość zegara", czyli o precyzję, która ma wynosić w linuxach 1000/s, czyli 1ms. Tam w źródłach jest wypisane ile to HZ wynosi, jest podawane 100, 1000, 1024, w zależności od architektury. Nie ma tam jednak podanego HZ w przypadku amd64, stąd moje pytanie jak dokładny jest ten zegar, czyli ile wynosi HZ i czy to HZ z configu zlokalizowanego w /boot/ to ten sam parametr.

HZ zależy od tego co sobie w kernela wkompilujesz a nie od architektury.
Kiedyś było to na sztywno 100, potem dodano możliwość zmiany, potem zmieniono default na 1000.
W AmigaOS była to częstotliwość pionu.

2210

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:23:42)

Może pogrubię:

Nigdzie nie piszę, że zależy od architektury, tylko, że według plików w źródłach kernela, wartość HZ zmienia się w zależności od architektury.

@uzytkownikubunt , ok. xD

A jeszcze taka sprawa, na necie można się natknąć na kern.hz="1000", zadziała to na linuxie?

Ostatnio edytowany przez morfik (2015-09-10 16:00:26)

Nie chce mi się kompilować kernela tylko po to by włączyć/przestawić jedną opcję. xD

BTW, w debianie jest jakieś jajo 4.1.0-2-rt-amd64 . Mniemam, że to rt to jest od realtime, a mimo to tam też jest 250. xD

Ostatnio edytowany przez morfik (2015-09-10 16:17:47)

Ja jeszcze wieczorem postaram się zapytać na stackexchange, może tam ktoś coś podpowie jak ten czas RTO się poprawnie wylicza.

Co do tych zmiennych sysctl, to u mnie nie ma proc/sys/net/sctp/ , a te wszystkie opcje co podałeś, mają tam siedzieć. Z tego co czytam, to to jest jakiś inny protokół. xD

Ostatnio edytowany przez morfik (2015-09-10 16:49:59)

Wyjaśnia się po trochu. Ten HZ to jest ten sam parametr i określa on ilość tyknięć zegara w czasie 1 sekundy.

Przy wartości 250, każde tyknięcie ma 4ms. (1000/250)
Przy wartości 1000 każde tyknięcie ma 1ms. (1000/1000)

Jeśli to podstawić do wzoru HZ/5 , to otrzumamy:

250/5=50
1000/5=200

Te powyższe wartości nie określają czasu tylko ilość tyknięć zegara. By otrzymać czas trzeba pomnożyć je przez te wartości, które otrzymaliśmy na początku i tak otrzymujemy:

50*4=200ms
200*1=200ms

I jak widać, niezależnie od ilości tyknięć ustawionych w HZ, minimalny czas na retransmisję zawsze wyniesie 200ms. Zatem jedna sprawa z głowy. xD

Jeszcze tylko trzeba ustalić czemu retransmisja dokonała się po 1s, a nie po 200ms. xD

Czytając ten post, wszystko teraz wydaje się dość proste. xD

Analizując wyjście ss -i, nie ma połączeń, które mają ustawione RTO na mniej niż 200ms, czyli wszystko się zgada jak dotąd — minimalne RTO=200ms. RTO jest wyliczane na podstawie RTT, czyli czasu jaki potrzebuje sygnał by dotrzeć w obie strony (coś jak ping), dlatego RTO w przypadku wszystkich połączeń się różni i to w paru przypadkach dość znacznie. Natomiast jeśli popatrzymy na przykład wyżej, to tam jest pakiet SYN. I generalnie z nim jest taki problem, bo on rozpoczyna połączenie i druga strona jeszcze nie udzieliła żadnej odpowiedzi, więc nie ma jak ustalić RTO dla pakietu SYN, no bo jak? xD Dopiero po ACK można to zrobić.

Przejrzałem za to ss -i pod kątem pakietów syn i co znalazłem. Wartości RTO są w tym przypadku bardzo dziwne. Mają wielokrotność 1000. Póki co tam widzę, 1000, 2000, 4000, 8000 i 16000, zatem są zwiększane dwukrotnie. Pytanie zatem co wpływa na zmianę i czy domyślna wartość RTO dla pakietu SYN wynosi 1000 a w przypadku np. nie uzyskania potwierdzenia, po 1s jest wysyłany kolejny pakiet SYN z ustawionym RTO na 2000, potem na 4000 itd. Póki co tego nie wiem ale wydaje mi że tak może być. xD

Idąc dalej za ciosem, przeszukałem wartości sysctl w stosunku do pakietu SYN:

net.ipv4.tcp_syn_retries = 4

Zatem mój system jest w stanie wysłać 5 pakietów SYN — jeden oryginalny i 4 retransmisje w przypadku braku potwierdzenia. Zatem chyba mam rację z tymi wartościami 1000, 2000, 4000, 8000 i 16000, bo ich też jest 5. xD

Ostatnio edytowany przez morfik (2015-09-11 13:41:26)

Ja w między czasie przeprowadziłem test i się potwierdziło moje przypuszczenie, tj. że pakiety SYN są traktowane inaczej i w ich przypadku jest to 1s. Potem każdy retransmitowany pakiet ma zwiększaną wartość dwukrotnie aż wybije ilość retransmisji ustawiona w net.ipv4.tcp_syn_retries , więc problem solved. xD