On Thu, 8 Jun 2006, Pailloncy Jean-Gerard wrote:
> > > > Jun 8 09:47:46 r001 ntpd[23319]: adjusting local clock by 0.875716s
> > > > Jun 8 09:51:26 r001 ntpd[23319]: adjusting local clock by 0.816038s
> >
> > Note that the time shown is *not* the time being adjusted,
> > but the difference from true time.
> >
> > I.e at first the offset is 0.87s and later it is only 0.81s so it is
> > slowly getting there.
> Ok. Sorry to misunderstand the numbers.
You are misinformed. Time adjustments are fixed in rate. For
adjustments < 1s, the rate is +/-40us per 10000us. That boils down to
about 1s per 4min. For adjustments larger than 1s, the rate is
+/-400us/10000us.
There are a couple of reasons why you can see alternating
positive/negative adjustments:
1. Your time reference is wobbling.
2. Your clock is wobbling.
3. In some cases ntpd overcompensates. This is especially true for
large adjustments.
I committed a diff to ntpd last week to fix the overcompensating.
Note that this need a recent kernel as well.
Without extra data you cannot tell what is happening here.
If you see continuous positive or negative adjustments, it just means
you clock is too slow or too fast. Currently, ntpd does not compensate
for such a systematic clock error.
Small adjustments (<128ms) are not logged, that's why the log looks
very empty on some systems. This does not mean ntpd does not do
adustments.
> I do some calculation in spreadsheet.
I think the calculations are based on misunderstanding the way
adjtime(2) works. You also do not take into account that your clock
might be wobbling.
-Otto
