[ntp:questions] Frequency Error

David Woolley david at djwhome.demon.co.uk
Sat Jun 2 08:47:03 UTC 2007


In article <BAY117-F176E08DF21285258CF8E64B72E0 at phx.gbl>,
sebestyenrobert at hotmail.com (robert sebestyen) wrote:

> The frequency error is the difference between system-time and hardwaretime 
> (RTC)

Normal implementation of ntpd do not touch the RTC time.  Frequency error is
the difference between the best current estimate of UTC time, as determined
by a combination of the the servers and directly attached reference clocks,
and the time in the software clock maintained by the OS and adjusted by ntpd.
Depending on what you are actually looking at, it may also include an excess 
correction intended to make the phase error converge to zero.

> due to the fact that CPU´s are never equal.

For people using normal laptops and desk tops, the CPU has no impact on
clock frequency (see TSC caveat at end).  The clock frequency used by the
software, including ntpd, is determined by a crystal oscillator, elsewhere
on the motheboard.  (Some embedded systems, and most microcontrollers
may have the electronics for the oscillator on the main chip;  I'm only
aware of microcontrollers having all of the timing circuitry on chip.)

> But one server is showing 21.5 in average, the other one 39.6
> I would like to decrease these values, somewhere around ZERO (if possible)

Why????   As long as there is some head room between the error and 500ppm, 
ntpd will keep just as good time.

> I installed a cron-job making every 3rd hour a hwclock --systohc
> (Cron-job is suppossed to run for more than 24hrs)

If you were to use Linux (you don't seem to say what you are actually using),
the system would do this for you every 11 minutes!

> I edited in a startupscript following:
> /usr/sbin/hwclock --adjust

--adjust is incompatible with ntpd, as there are two different things trying
to set the clock.  In this case, you seem to be doing it before ntpd is started,
but --adjust will assume that the hardware clock has been drifting at the same
rate both when the system is running and not running.  However, your cron job, 
and if you were using Linux, the kernel, would have been compensating for the
hardware clock drift when the system was running, and therefore invalidating
that assumption.

> Is that a possible way to solve my problem?

No.  If you want the frequency error to read zero in ntpd you need to do
two things:

- make sure that your upstream time sources accurately reflect UTC.
- trim the motherboard crystal used for the CPU clock to be exactly on 
  frequency.  As many crystals will be packaged, with no ability to
  trim them, you will probably have to replace the crystal oscillator 
  package on the motherboard (will require a soldering iron, and probably
  skill in doing surface mount re-work).

> Does anybody have experience how to handle frequency error in practice?

If they are less than 50ppm, you let ntpd correct them, which it seems
to be doing perfectly well, already.  If they are more than about 450ppm,
you should:

1) try to get the motherboard replaced under warranty;
2) failing that, use tickadj, or whatever does the same job on your OS, to 
   provide a coarse correction.  Typically this will allow you to get within
   50ppm.

If they are in the range between 50ppm and 450ppm, you can ignore or coarse
compensate depending on how big a transient you want to be able to handle 
without end stopping the frequency compensation.

As your stability seems good, I haven't discussed lost interrupts or variations
in TSC rates.

If you don't have a true UTC reference, an error of 450ppm is not sufficient
cause for a warranty claim, as it may be all the other machines that are wrong.




More information about the questions mailing list