Pan J.F. napisał:

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

Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:

# Don't serve time or stats to anyone else by default (more secure)

Dopiero po niej można ustawić upoważnione zakresy adresów.

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

Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.

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

Często RTC o ogóle nie jest potrzebne. Urządzenia przeznaczone do
pracy w sieci szęsto w ogóle nie mają.

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

No i w ogóle średnio jest potrzebny.

--
Jarek