Pan Grzegorz Niemirowski napisał:

>> Ale przecież o to chodzi, by *nie* synchronizować "kiedy ktoś chce",
>> tylko żeby zawsze było zsynchronizowane.
>
> I to jest wykonywane za pomocą okresowego kontaktu z serwerem NTP.
> Masz na myśli coś bardziej zaawansowanego, w rodzaju wspomnianego
> pomiaru odchyłu lokalnego RTC i stałe korygowanie na podstawie tego
> pomiaru?

Tak, to mam na myśli. Tyle że nie nazywam tego "zaawansowanym" -- po
prostu przyzwyczaiłem się, że tak jest. A jest tak samo odkąd pamiętam.
Gdy pierwszy raz zetknąłem się z tą metodą synchronizacji, Windows (95)
w ogóle takimi fanaberyami się nie przejmował. Potem był jakiś dodatek
(może to już w 98), który pozwalał na synchronizację na żądanie. Teraz
to już nawet jakieś płynne regulacje zrobili, czy inne bajery. Dla mnie
to jest niepojęte, że w Redmond przez dwadzieścia lat drobnymi krokami
dochodzą do tego, co już raz dawno temu zostało wymyślone. Boją się
gwałtownego skoku w czasie, czy co?

>> Ile to jest "duża różnica czasu" (nie mam w tej chwili dostępu do WWW)?
>> Najwyżej kilka lat temu to było, kliknąłem w jakiś przycisk "synchronizuj"
>> czy podobny -- przestawił wskazówki i poinformował, że synchronizacja
>> zakończona. Różnica nie była wielka, taka jak może się zdarzyc przy
>> rozjechanym RTC.
>
> To nie jest stała wartość.
> In order for W32Time to set the computer clock gradually, the offset
> must be less than the MaxAllowedPhaseOffset value and satisfy the
> following equation at the same time:
>|CurrentTimeOffset| / (PhaseCorrectRate*UpdateInterval) < SystemClockRate / 2

Nadal niewiele mi to mówi. Ale nie przejmuję sie tym, nie będę próbował
zrozumieć. Przyzwyczaiłem się do tego, że się uruchamia program, który
jest klientem, serwerem, albo jednym i drugim -- i wszystko działa.
Co tu jest do konfigurowania? Ma być czas dokładny, no to jest.

--
Jarek