Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>>>> Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
>>>>> dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
>>>> Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
>>>> bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
>>>> kolejnej synchronizacji, zmienic dosc istotnie.
>>> Ale w jakim systemie?
>
>> 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 :-)

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.

>>> Zegar systemowy jest skorygowany przez doświadczalnie
>>> wyznaczony parametr. Tak maszynka, która sobie kilka dni
>>> pochodziła w sieci, nawet po odcięciu od niej zachowuje się
>>> o wiele lepiej od komputera z Windows.
>> Od komputera z Windows zapewne. Tym niemniej ten wymagany
>> wspolczynnik korekcji sie zmienial dosc istotnie.
>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.

Co prawda na reku mam zegarek Casio, ktory jest pierunsko dokladny,
ale inne casio juz takie nie sa.
A kwarc tam chyba inny (tuning fork) niz w procesorze.
Moze teraz sa lepsze kwarce, ale do komputera to sie zasadniczo nikt
nie przejmuje - najtanszy jest najlepszy :-)
Tak czy inaczej - zapamietalem sobie, ze stabilne te kwarce nie byly.

>Ale kalibracja
>tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
>pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
>urządzeniu.

Tak nawiasem mowiac, jak patrze na ten zegarek, ktory potrafi miec
sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
programowej w zegarku.
Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
obliczyc o ile i zapamietac poprawke.
Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?

>> No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
>> komputer zimny i sie dopiero nagrzewa ...

>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.

>Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
>to przy syncronizacji. A po niej robi się zapis system --> RTC.

Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
Tylko - czy tak sie robi ?
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift, nie
znalazlem - on chyba RTC nie obsluguje ?

Dodatkowa trudnosc - w pececie ten zegar ma sekundowa rozdzielczosc.
Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
"moment" zmiany.

J.