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