[Dovecot] Time moved backwards

[Bill Cole]

At 12:48 PM +0400 5/13/08, Eugene wrote:
>Hello,
>
>From: "Quentin Garnier" <cube at cubidou.net>
>>I'm not the one having trouble reading, here.  The proper way to start a
>>system is to run ntp*date* (as early as possible) and then ntpd.
>
>That's what you say, and it is far from being officially accepted.

There is nothing 'official' in regards to how you start up your 
system that should carry more influence than having it start up 
correctly.

>NTP project clearly deprecates ntpdate for several reasons.

I think that is an incorrect statement, and to the degree that it is 
correct, it still does not mean that it is reasonable to have an 
unstable clock.

The practice of running ntpdate as a cron job rather than a ntp 
daemon certainly is deprecated and always has been, but even that is 
not so much because of how well it works (on most systems it is 
perfectly functional) but rather because it does not scale across the 
net: the public NTP infrastructure gets what Dr. Mills  calls "little 
fireballs of congestion" as the cron jobs fire, and that has bad 
impacts on everyone's NTP-based time accuracy.

On the other hand, ntpdate run once at boot still serves a purpose, 
even if you are running the latest ntpd with the initial stepping 
functionality rolled in and enabled, and it is helpful to note Per 
Hedeland's succinct and practical counterpoint in the FAQ immediately 
following Dr. Mills' long explanation of the various edge cases 
involved in choosing when to step and when not to.


>In addition, "the clock should not be stepped until a consistent 
>offset has been observed for a sanity interval, currently 15 
>minutes". So ntpd may in principle step time again.
>http://www.ntp.org/ntpfaq/NTP-s-config.htm

You are misreading and/or misrepresenting the context of the piece 
you quote. A good NTP daemon is properly quite conservative about 
stepping the clock at times  *other than* at boot, and should take 
precautions against trusting clocks that seem wrong once it has what 
should be a trustworthy synchronization and characterization of its 
own local clock.




-- 
Bill Cole                                  
bill at scconsult.com