Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>>> Linux. Tez ten ntp drift ogladalem, ale chyba w innym
>>>> pliku/patrzylem na aktualne dane.
>>> A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
>>> I wcale nie było łatwo o publicznie dostępny serwer czasu.
>
>> Skoro wymyslili NTP, to chyba bylo latwo :-)

>Jedno nie implikuje drugiego. Protokół wymyślono dawno, publiczne
>serwery pojawiły się dużo później.

Watpie. Skoro wymyslono protokol, to i serwer musial byc, do
przetestowania :-)

W kazdym badz razie z serwerem nie mialem klopotow.

>> Juz nie pamietam dokladnie jak to robilem, ale zainteresowala
>> mnie stabilnosc wewnetrznego kwarcu.
>> Wiec synchronizowalem z jakim zewnetrznym serwerem NTP,
>> i patrzylem jak sie zmienia wyliczony dryft.
>
>> No i wychodzilo tak sobie.

>Ale co wychodziło tak sobie? Komputer zsynchronizowany z serwerem
>tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
>zbyt częste.

Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.

>>> Jak wspomniałem, zmienia się rzadko. W miare łatwo jest
>>> wyprodukwać
>>> kwarc wysokiej jakości, o dobrej stabilności, w tym
>>> temperaturowej.
>>> To się trzaska jedno po drugim na linii produkcyjnej.
>> Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
>> Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.
>A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
>zrobić to precyzyjnie według wyliczeń, to będzie stabilny.

O grubosc mi chodzi.
Jak sp* kat ciecia na poczatku, to bedzie niestabilny,
jak sp* potem grubosc - to bedzie niedokladny, ale stabilny - o ile
najpierw dobrze wycieto.

No chyba ze gdzies przy szlifowaniu sie bardziej docisnie z jednej
strony, skos sie zrobi - i wyjdzie tak, jakbys na poczatku krzywo
wycial.

>>> Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
>>> przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
>>> w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
>>> z rtc przy starcie (zero z definicji) i po określonych odcinkach
>>> czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
>
>> Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi
>> stabilnosc
>> niezbyt dobra.

>Nie mierzyłem, to nie będe się spierał. W praktyce problem
>synchronizacji
>czasu uważam za rozwiązany.

W komputerze z linuxem, z czestym dostepem do internetu i rzadko
wylaczanym.
A my tu o zegarku bez dostepu :-)

>> Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
>> nie znalazlem - on chyba RTC nie obsluguje ?

>Z RTC nie ma nic wpólnego. Z *przesunięciem* czasowym też nie. To
>jest
>stan wirtualnego trymera, czyli korekta *częstotliwości*, tak w
>skrócie.

Czyli do RTC trzeba osobny program :-)

>> Dodatkowa trudnosc - w pececie ten zegar ma sekundowa
>> rozdzielczosc.
>> Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
>> "moment" zmiany.
>A skąd, mikrosekundowa dokładność dostępna jest nawet dla programu
>sleep (który śpi z taką dokładnością). Programy związane z ntp też
>podają dokładną różnicę czasu.

RTC w pececie nie ma takiej rozdzielczosci !
Stad, aby sprawdzic jego dryft, trzeba go odczytac wiele razy az
zmieni sekunde, wtedy odczytac dokladny czas systemowy, i mamy
wzglednie dokladnie zmierzony czas w RTC.
Im czesciej odczytujemy, tym dokladniejszy pomiar, ale tez procesor
bardziej zajety przez te srednio pol sekundy.
Nawet wielordzeniowy moze byc przyblokowany, bo dostep do rejestrow
RTC dlugo trwa, przynajmniej kiedys tak bylo.

No i ja sie bawilem chyba jeszcze gdy "microsecond timer" nie byl
dostepny, kernel sam sobie sobie go organizowal, i co przerwanie
dodawal wlasnie tych 10000us do zmiennej timera. Czyli niby
"microsecond" a naprawde 10ms ..

A tak swoja droga ... to jak sobie teraz radza ?
Jest sprzetowy "time stamp counter", z rozdzielczoscia nawet jakby
lepsza niz nanosekunda, ale napedza go zegar systemowy.
Jak sie chce skorzystac i przeliczyc na UTC, to trzeba dosc ambitnie
przeliczac, z ryzykiem cofania czasu .

J.