Frank Bonnet
2011-May-05 05:25 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
Hello I get this warning in dovecot.log the machine is running ntpd so this is a bit strange ...
Charles Marcus
2011-May-05 13:32 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
On 2011-05-05 1:25 AM, Frank Bonnet wrote:> Hello > > I get this warning in dovecot.log > > the machine is running ntpd so this is > a bit strange ...How are you using it? It obviously isn't working correctly if your server isn't staying in time. -- Best regards, Charles
Patrick Domack
2011-May-05 16:07 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
ntp isn't a magical fix. You need a good selection of source servers, or local time sources for it to pick a steady reliable time to use. Also, if the clock in your computer drifts too much, ntp will refuse to correct it or keep it in sync at all. Quoting Frank Bonnet <f.bonnet at esiee.fr>:> Hello > > I get this warning in dovecot.log > > the machine is running ntpd so this is > a bit strange ...
Spyros Tsiolis
2011-May-05 18:45 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
Hello, You say ntpd is running. Is it running as a daemon ? AFAIK, to keep good time on a linux machine inside the network, you need to run "ntpdate" and not "ntpd". I had _exactly_ the same problem and I was running an ntp daemon. I wasn't actually syncing to anything. So,I did some searching and found out that I need to run "ntpdate ntp.server.fqdn", then add this same line to cron. HTH, s. ---- "I merely function as a channel that filters music through the chaos of noise" - Vangelis
Alexander Moisseev
2011-May-06 07:34 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
Are you got this warnings only after OS reboot? -- Alexander Moisseev
Lorens Kockum
2011-May-06 15:14 UTC
[Dovecot] May 05 07:20:21 imap: Warning: Time jumped forwards 16 seconds
I did leave a little almost on-purpose dangling hint that got me an off-list query... Since I'm replying, I might as well reply on-list for the record, even if this is getting off-topic. I've just about exhausted my knowledge on the subject, so further questions will probably find a more attentive audience on some NTP list :-) A reader wrote:> You wrote "probably" but isn't it common to sync against a stratum 1 server > having some GPS clock attached? I assume that most computer centers operate > a stratum 1 time server today and stratum of clients should be between > 2 (!) and 5.Most scientific computing centers maybe, but business people probably don't. In my experience most people who run stratum-1 servers impose limitations on their clients, like asking for permission, registering, signing up for their mailing list, running public stratum-2 servers... or being in the same organization as them, which certainly seems to be your case :-) I suppose the most common reason for restrictions like these would be that with more than n clients, the server will start having problems, bandwidth, latency, whatever. Maybe n is a large number, but then again maybe not, after all we're talking about milliseconds. I'm not sure what it would take to run a stratum-1 service with under one hundredth of second of jitter if that service gets used as the default for new Debian or RedHat installs, but I'm quite certain I don't want to pay for the hardware or the bandwidth! Registering for a mailing list is also important when the service is really really important. You don't need to take my word for it: http://support.ntp.org/bin/view/Servers/RulesOfEngagement As for stratum-2 servers, there are lots of public ones with no restrictions other than running a reasonably well-behaved ntp implementation. The difference being synced to a stratum-1 or a stratum-2 is negligeable; and most people who have reasons for milli-second accuracy want it between their own servers. They will run a set of NTP servers, stratum 1, 2 or 3, and sync all of their other servers to them. For many or even most uses it won't matter if they are a several milli-seconds off with respect to some atomic clock as long as they are internally consistent. It is my opinion that someone like the OP, who wants his servers to be on time but who does not seem professionally interested in running an NTP server or in having milli-second accuracy, should not be peering with a stratum-1 server. That is the reason I wrote stratum-3 and not stratum-2 :-) Just to be complete, on the other side of the spectrum, I think we agree that with such a lot of stratum-2 servers to choose from, it seems unnecessary to have a stratum above 5. You'd be at 5 if you sync to your organization's stratum-4 syncing to your ISP's stratum-3 syncing to public stratum-2s... maybe a multi-site organization would run an NTP service for every site, but then they'd probably sync their main servers directly to stratum-2 servers instead of to their ISP, so that'd cancel out. HTH