Jak mogę zmierzyć i zapobiec znoszeniu zegara?

15

Na kilku platformach produkcyjnych zaobserwowaliśmy objawy, które wydają się sugerować, że zegar czasu okresowo przeskakuje do przodu lub do tyłu. Skoki trwają zwykle około 1 sekundy, zazwyczaj anulują (skaczą do przodu, a potem bardzo szybko potem do tyłu) i zdarzają się około 50 razy dziennie. To przesunięcie jest najbardziej zauważalne w okresach szczytowego użycia aplikacji oraz w okresach operacji we / wy na wysokim dysku, takich jak codzienne kopie zapasowe. Te zmiany wpływają na naszą miękką aplikację wrażliwą w czasie rzeczywistym.

Systemami są serwery Oracle Netra X4250 i Netra X4270 z systemem SLES 11SP2 z domyślnym jądrem 3.0.58-0.6.6.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Wyłączyliśmy NTP , ale nie miało to żadnego wpływu na dryfy. Czy istnieją narzędzia mierzące przesunięcie zegara w ciągu dnia? Jak możemy tego uniknąć?

Są to platformy produkcyjne i nie możemy odtworzyć problemu w naszych laboratoriach, więc moja zdolność do eksperymentowania jest ograniczona. Jeśli zostawię to własnym urządzeniom, napiszę narzędzie do pomiaru dryfu i być może eksperymentuję ze źródłem zegarowym HPET.

linux sles clock

— Brett
źródło

5

Wyłączenie NTP powoduje, że zegary są znacznie bardziej niestabilne ... jedyny powód, dla którego widzę, że NTP nie utrzymuje zegara w linii, jest taki, że zegar nie działa, a NTP odmawia jego aktualizacji (patrz ntpdate(8)lub ntpd(8)).

— vonbrand,

1

NTPD śledzi i koryguje przesunięcie zegara, ale to, co masz, nie jest dryfowaniem. Dryf jest konsekwentnie w tym samym kierunku o mniej więcej tę samą ilość w czasie. Jeśli losowo przeskakuje do przodu i do tyłu, nie ma możliwości przewidzenia tego i przystosowania się do tego.

— Patrick

1

To, co @Patrick powiedział, jest słuszne, problem, który opisujesz, to nieciągły skok w czasie do przodu i do tyłu, wiele razy dziennie. NTP działa dobrze na drifcie, ale nie pomoże ci w tym zbytnio. Prawdopodobnie coś resetuje datę systemową do zewnętrznego źródła czasu, które może mieć tylko 1 sekundową rozdzielczość. Jeśli twoje serwery to x86 *, sprzętowe RTC może być źródłem, a niektóre zadania crona winowajcy. Jeśli chodzi o pomiar przesunięcia zegara, odpowiedź ntpdate Bratchleya jest rozsądnym podejściem, pod warunkiem, że zastosuje się dobre odniesienie zegara warstwy 1: uruchom raz na minutę i uzyskaj wynik dla zdjęcia.

— duanev

1

Przejrzałem ocenę NTP podczas uruchamiania na nowym serwerze ( drdobbs.com/embedded-systems/… ). Nauka nowego kryształu zajmuje godziny NTP. W przypadku naprawdę złych kryształów NTP będzie musiała wielokrotnie „krokować” znaczną ilość czasu podczas treningu (patrz Ryc. 4 i 5 w tym artykule). Końcowa wartość w ntp.drift wynosząca 118 ppm to 10 sekund dziennie lub 208 ms co 30 minut. Chociaż nie tego widział PO, NTP może początkowo powodować zauważalne skoki w czasie.

— duanev

8

Czy istnieją narzędzia mierzące przesunięcie zegara w ciągu dnia?

Jedyne znane mi narzędzia to narzędzia NTP, które powinny wystarczyć. Nie musisz tak naprawdę konfigurować ntpd do synchronizacji z danym źródłem zegara, możesz po prostu użyć -dopcji, ntpdateaby pobrać obliczone przesunięcie.

Przykład:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d jest opcją debugowania, która działa NTP bez faktycznego dotykania zegara systemowego.

Wszelkie porady, w jaki sposób możemy tego uniknąć?

Nie jestem zbyt zaskoczony, że nie jesteś w stanie odtworzyć tego w środowisku programistycznym / testowym, ponieważ prawdopodobnie jest to spowodowane zegarem sprzętowym. Jeśli masz z kimś wsparcie sprzętowe, postaram się oddać twoje maszyny do serwisu. Jedną z możliwości jest zamiana jednej z maszyn deweloperskich dla tej maszyny produkcyjnej, naprawa wcześniejszych systemów PROD i ponowne wprowadzenie jej jako maszyny programistycznej w celu zastąpienia tej, która jest teraz w PROD.

Poza tym zmiana źródła zegara sprzętowego to wszystko, co możesz zrobić. Jeśli nie możesz lub nie możesz zrobić zamiany, sugeruję, abyś wybrał trasę hpet. Możesz sprawdzić, czy zmiana źródła zegara miesza się z usługami systemowymi, a następnie wdrożyć do produkcji jako gradobicia.

— Bratchley
źródło

Przez „pomiar dryfu zegara” nie miałem na myśli dryfu z referencyjnego źródła czasu, takiego jak NTP. Miałem na myśli narzędzie, które może wykrywać „skoki” w czasie dnia w ciągłym zakresie czasu. Na przykład pobieraj próbki dobowe co 50 ms i zgłaszaj, czy różnica od ostatniego próbkowania jest zbyt duża od 50 ms. Takie narzędzie pokazałoby, że z jakiejkolwiek przyczyny zegar czasu odchodzi od zegara sprzętowego.

— brett

1

Czy obecność takiej interwencji nie spowodowałaby większego pogorszenia wydajności, niż można się spodziewać? Najprawdopodobniej jest to problem sprzętowy, więc będziesz musiał oddać sprzęt do serwisu lub użyć źródła zegara bez tego problemu. tscjest oparty na procesorze, więc ma sens, że wyższa aktywność procesora i tak spowodowałaby problem z zegarem sprzętowym. Jeśli hpet jest dla Ciebie wystarczająco szybki, być może będziesz musiał po prostu spróbować, uzyskać serwis lub zrobić zamianę. To jedyne opcje, które mogę dla ciebie zobaczyć.

— Bratchley,

3

Jednym z rozwiązań jest użycie HPET

Zobacz także High Precision Event Timer

Aby ustawić go jako parametr rozruchowy, użyj

clocksource=hpet

Na starszym sprzęcie TSCczęsto był niestabilny i był wyłączany przez jądro.

Wraz z pojawieniem się wielordzeniowych / hiperwątkowych procesorów, systemów z wieloma procesorami i hibernującymi systemami operacyjnymi, nie można polegać na TSC w celu zapewnienia dokładnych wyników ...

Wikipedia: Licznik czasu

W systemie produkcyjnym wykazującym objawy fluktuacji zegara przestawiłem źródło zegara na hpet. Nie miało to wpływu na obserwowane objawy drgań zegara.

— brett

HPET jest zewnętrznym zegarem sprzętowym i nie może drgać. To rozwiązanie wydaje się być złą drogą. Wystąpiło wiele problemów z synchronizacją ze starszym sprzętem, szczególnie podczas korzystania z wirtualizacji. Czy sprawdziłeś to również w innym oprogramowaniu?

1

Napisałem bardziej szczegółowe narzędzie do korelowania pomiarów zegara z objawami opóźnień wykazywanymi przez naszą aplikację. To narzędzie wydaje się wykluczać to, co wcześniej podejrzewałem o fluktuację zegara czasu Linuksa.

Tak krótko mówiąc, moja początkowa hipoteza była nieprawidłowa. Ale wiele się nauczyłem o zegarach Linuksa z odpowiedzi i linków, więc dziękuję wszystkim, którzy odpowiedzieli!

— Brett
źródło

3

(...) moja początkowa hipoteza była nieprawidłowa. Czy możesz nam zatem powiedzieć, jaka była prawdziwa przyczyna?

— Piotr Dobrogost

0

Czy zegar nie powinien być monotonna, chyba że ktoś go zmieni? Skoki do tyłu nie powinny być możliwe. Musi być coś, co ustawia zegar - zadanie crona lub jakiś inny demon (na przykład wezwanie do hwclock --adjust). Pamiętam, że sam NTTP aktualizuje statystyki dryftu i rutynowo kompensuje to, a jeśli nie uruchomisz ntp przez długi czas i uzyskasz ogromne przesunięcie, to mierzy czas na kilka dni po nim, jeśli nie zresetujesz/etc/adjtime . Możesz mieć coś takiego - coś, co okresowo dostosowuje dryf czasu (i powoduje skoki).

ntp ma właściwie przeciwdziałać temu problemowi.

— orion
źródło

Tak też myślałem. Moje czytanie źródeł zegara sprzętowego sugeruje, że licznik powinien monotonicznie wzrastać. Gdyby tak było, w najgorszym przypadku powinniśmy obserwować zmienne częstości tykania, ale nigdy nie cofają się. W systemie wieloprocesorowym rozumiem, że tsc musi być zsynchronizowany między procesorami - być może to powoduje skoki wstecz?

— brett