Vlákno názorů k článku
Jak na řízení času pod Linuxem
od vandrovnik - ntpdate bych použil jen pro jednorázové srovnání času...
-
ntpdate bych použil jen pro jednorázové srovnání času po startu počítače. ntpd umí korigovat čas "hladce", tj. nestane se, že by se některé aplikace hroutily jen proto, že se "podívají na hodinky", za chvilku se "podívají znovu", a ono je méně hodin! Konkrétně dovecot tohle nesnáší a občas spadne, když používáte ntpdate.
-
MilanK (neregistrovaný)
No ona je chyba i v tom Dovecotu. Je zbytečné, aby aplikace spoléhala na to, že reálný čas bude "monotónní", přestože to k ničemu nepotřebuje. Typicky jsou to síťové servery, které používají různé časovače. Stačí, když se použije časovač, který není odvozen od hodin reálného času (ale je také méně přesný): stejně v těch protokolech nezáleží na tom, jak přesně je "ta minuta timeoutu" změřena.
Dříve jiffies, na které ale už v nových jádrech není spolehnutí, takže aktuálně používám clock_gettime(CLOCK_MONOTONIC, ...).
-
MilanK (neregistrovaný)
Mas pravdu. Ted jsem (teprve) cetl http://wiki.dovecot.org/TimeMovedBackwards a vidim, ze ty upravy by byly opravdu hodne narocne (ne-li nemozne, napr. to testovani "dotlock files' staleness", ktere zavisi na semantice jinych aplikaci, takze s nim Dovecot tezko neco zmuze). Vychazel jsem z toho, ze mnou navrhovane upravy zafungovaly v nekolika jinych pripadech (napr. demon pro dynamicke smerovani na routeru, ktery nema RTC chip: router nabehne s casem roku 1970 a teprve po spusteni dynamickeho smerovani si vytvori cestu k NTP serveru a synchronizuje se s nim, NTP demon pak zacne skokem v case, protoze je rozdil casu prilis velky; tento skok musi smerovaci demon ustat)...
Svym puvodnim prispevkem jsem chtel zminit, jak se problemy se skokovou zmenou realneho casu daji taky (casto) resit. Normalne misto ntpdate pouzijete ntpd, ale treba u tech malych routeru bez RTC to nepomuze.
