Pan J.F. napisał:

>>>>> 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 :-)

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

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

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

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

Mogli tak zrobić, to przypomina idee NTP, było na czym się wzorować.

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

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

Widziałem takie rozwiązanie. Można sprawdzać na przykład co godzinę
i *nie* korygować RTC. Czas wyłączenia znany jest od razu po uruchomieniu
-- różnica między czasem bieżącym a czasem ostatnirgo zapisu pliku
z odchyłką.

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

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

--
Jarek