problem with Time in Dapper

Daniel Pittman daniel at
Thu Oct 26 02:26:13 BST 2006

Richard Johnson <nixternal at> writes:
> On Wednesday 25 October 2006 02:44, Daniel Pittman wrote:
> [snip]
>> I hate to say it Richard, but this is a pretty bad solution to keeping
>> time stable on any machine.  It will work, but it is very hard on the
>> software and system overall.
> What is so hard on it? 

Because it causes the time to jump suddenly, both backward and forward,
which causes confusion among other software packages that pay attention
to the clock.

> It runs the simple command every hour to update the time. I have a
> million things going at once, and never notice ntpdate use any
> resources. As a matter of fact, I just used "top" and run it during
> the ntpdate process, and guess what?  It doesn't even show up. 

No.  Perhaps I wasn't clear: running ntpdate itself is not a problem.  
The problem is the way that ntpdate updates the system clock.


>> Now, for an "off by an hour" machine that is probably the right thing
>> to do.  For one that is almost right, though, this is a pretty bad
>> solution -- software doesn't like time jumping about, and can react
>> pretty badly.[1]
> I have been doing this for at least a good 5+ years, and never once
> had a problem.

Well, I am glad to hear that.

I have been running systems for similar periods and I can assure you
that this /does/ cause real problems, and that it can cause system
failure in extreme enough cases.

On a desktop where all the infrastructure (mail, web proxy, etc) is
operated by a third party then, yes, perhaps you have nothing that would
notice the clock changes.[1]

>> Oh, and your suggestion uses a single server, so if ever
>> has the wrong time your machine will slavishly follow suit and have the
>> wrong time as well.[2]
> That is a downfall, but a script can be created to fix that, if it
> ever becomes an issue.

I can't imagine a script, simple or otherwise, that is capable of
determining if the time on is incorrect.

A human could certainly note the discrepancy and either run some script
to fix it or alter your ntpdate calls, but that isn't automated in any
particular fashion.

>> Anyway, running the ntp daemon is much nicer.  It has very good
>> properties for keeping the clock in sync.  It never jumps the clock, but
>> rather corrects it carefully so nothing ever sees a sudden change.
> Well, my setup is never more than 1 second off per hour. ntpd is
> constantly polling at regular intervals, every few seconds. If your
> clock is an hour off every hour, then ntpd would be the way to go, but
> if it is only a second off, who cares.

Actually, the ntpd is configurable, and is not nearly so frequent as you
suggest.  During the initial startup it will make frequent requests to
rapidly converge time with the upstream system, but beyond that it
scales out to very infrequent queries.

Secondly, if your clock is so inaccurate that it drifts by an hour per
hour (stands still, perhaps?) then nothing is going to help you.  That
is sufficiently broken that nothing can fix it.

For a drift of a second an hour or so, which isn't all that uncommon
with the cheap clocks used in modern desktop computers, ntpd will
correct for that very efficiently, transparently, and without any
jumping at all.

>> It pays serious attention to the properties of the clock in your
>> computer, so that it can correct for things like drift and accuracy
>> errors.
> This is done by constantly polling, if this was the case then setting
> ntpdate to run every 10 seconds would do the same thing. 

Well, by a process of synchronising with your clock peers and running a
very complex set of loops to ensure that the local clock and the remote
clock converge, yes.

Running ntpdate every ten seconds would *not* do the same thing.  It
would jump the time every ten second -- no correction to the rate of
time, just a jump.

> ntpd doesn't allow bursts which could of course cause issues,
> especially when using sudoers. 

I presume by "bursts" you mean "jumps in time" -- and, yes, it could be
an issue with sudo keys, or any other process that is dependent on a
coherent view on time; there are many of those.

> However, if you have the issue where you clock is more than 15 or so
> minutes, ntpd will exit out anyways and stop running. ntpdate in my
> script won't.

If your clock is more than 15 minutes out then something is odd with
your system.  Perhaps it is half an hour out because your local clock is
broken or something abused it.

The recommended practice, by the way, is to fire off ntpdate or
equivalent once at boot time, to perform any requisite gross correction,
if your hardware requires it -- for example, hardware that lacks a
real-time clock, or if you have a seriously broken clock.

>> It carefully checks the time coming in from the server and, if it is
>> low quality, refuses to use it.  Given multiple servers it even
>> checks them against each other and rejects any that are not connected
>> to reality.
> That it does.
>> So, while your suggestion will work it will have a host of other
>> problems.  On a single user desktop you may never notice them, but it
>> isn't a good thing to configure as a general rule.
> So, since my machines are my working desktops, all in good running
> order, my simple little addition is more than adequate. 

Well, I am glad you have something that meets your needs.

> My servers that are constantly blasting away with mirrors, building
> packages, hosting and what not, yes I run ntpd on them.

Why?  By your own statement running ntpdate would be more than adequate
wouldn't it?

> Plus I like the fact that each of my time updates are logged, so I can
> review the logs and seek discrepencies.

The logs kept by ntpd are significantly more useful and informative than
the brief record of ntpdate corrections.  They can show you the drift of
your clock, of your peers, and even the rate of change of clock drift
with a little work.

> So far the biggest update in my log in 2 years is, 3.3s. Most are
> under 1s. So, I would have to say my way isn't right or wrong, and
> your way isn't right or wrong. They both work, 

Well, they both work assuming that you don't happen to run any software
that behaves incorrectly in the presence of a jump in time, and you
don't care about accurate time recording in logs, etc.

> granted ntpd is preferred in a heavier environment, such as servers
> doing lots of work. 

ntpd is preferred anywhere that accurate and effective time correction
is desired.  It is a vastly higher quality time management tool.

The level of work being done by the machine is really not that relevant,
except indirectly through the logs and software perhaps being more
critical to people.

> ntpd is just one more service I don't need starting up as it is with
> the hundreds that already do.

Fair enough.  No one can compel you to maintain high quality timekeeping
on your machine, or to notice the problems that jumps in time cause.

Advising others to follow suit without explaining to them exactly what
trade-off they are making seems somewhat unfair to the recipient of your
advice, though.  

They, after all, may never have thought about any of this, so may not
know what circumstances determine a need for good, skip-free time on the
machine and which allow them to get away without it.


[1]  Well, your web browser might if you have a local cache enabled, but
     even then it will usually clean up after a reload of the page.

Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at

More information about the kubuntu-users mailing list