[ntp:questions] Re: Frequency and leapseconds!

Kevin MacLeod kevin-usenet at horizon.com
Sun Feb 20 06:50:45 UTC 2005

In article <mailman.139.1108714484.583.questions at lists.ntp.isc.org>,
erik corell <cii99ec7 at i.lth.se> wrote:
> I have noticed that freq (scaled ppm) in the timex struct from
> ntp_adjtime() stabilize around a non-zero value on my computers.

To be expected; your crystal isn't perfect.

> My questions are:
> Is freq the frequency difference from the true calender time 1 sec/sec
> or is it the difference from a frequency estimation at one point?

I don't understand.  The freq is the difference between the nominal
system clock frequency and the UTC reference.  This is to the best of
NTP's ability to compute it, so of course it's an estimate.

> To put is simple: Does for example freq=27.000 ppm always give the same
> tsc per computer second?

I still don't understand the question.  The freq is the difference
between the operating system nominal clock rate (computed from the
hardware documentation) and the external UTC reference.
(Actually, the sign convention is that freq > 0 means that the
computer clock is naturally slow relative to UTC and is being sped up.)

I'm not sure what "tsc" is.  Is that the Time Stamp Counter available
on x86 CPUs Pentium and beyond?  In that case, it is obviously not
true in general, because NTP runs on non-x86 processors, 486 and 386
processors, and x86 operating systems that don't read the x86 TSC.

Further, the x86 TSC frequency varies over at least a 30:1 range (from a
120 MHz Pentium to a 3.6 GHz Pentium 4), so obviously a correction
of +/-500 ppm (0.05%) can't represent that range.

> If so, is it possible to access this 'base rate'?

In general, no.  Just to give one example that applies to the
hardware and operating system I'm sitting in front of right now:

I'm using a 2.6 Linux kernel on generic x86 hardware that is using
an (emulated in the soutbridge) 8254 PIT to generate timer interrupts.
If you are using, say, OpenVMS on Alpha hardware, or QNX on an embedded
MIPS chip, your system will work very differently.

The 8254 is a programmable timer fed with a clock at a nominal frequency
of 1193181.81818... Hz.  This is usually generated by an oscillator
with a +/- 100 ppm frequency spec, so anything between 1193062.5 and
1193301 is plausible.

However the Linux kernel programs this timer to generate a 1000 Hz timer
interrupt.  Looking through the code...

<asm-i386/param.h> # define HZ             1000
<asm-i386/timex.h> #define CLOCK_TICK_RATE 1193182
<linux/jiffies.h> #define LATCH  ((CLOCK_TICK_RATE + HZ/2) / HZ)
	Thus, LATCH equals 1193.
<linux/jiffies.h> #define ACTHZ (SH_DIV (CLOCK_TICK_RATE, LATCH, 8))
	This is (1193182<<8 + LATCH/2) / LATCH = 256039 (1000.15234 * 256)
<linux/jiffies.h> #define TICK_NSEC (SH_DIV (1000000UL * 1000, ACTHZ, 8))
	This is (1e9 << 256 + ACTHZ/2) / ACTHZ = 999848 nsec/tick.

The upshot is that this would increment exactly 1 s/s if the PIT
frequency were 999848/1193 ns per tick, or 1193181.36356 Hz.

If you want to see what freq does, follow the time_freq variable in
kernel/timer.h as it is used in the second_overflow() routine to
set time_adj, which is used in update_wall_time_one_tick()
(a.k.a. "hardclock" in NTP-speak).  If time_freq is positive, then
delta_nsec is increased past 999848 often enough to make up the

All of this has NOTHING to do with the x86 Time Stamp Counter.
That is used only to interpolate between "hard" ticks like the above,
and so has no effect on the long-term clock rate.

There are other timers that the kernel can derive its timer interrupt
from, and will, depending on some hairy details.

> Also, is there any way an application can get the total amount of leap
> seconds since the start of NTP/UTC epoch? For example via a system call
> or from the NTP server or any other server or from varible long tai in
> ntptimeval.

No.  NTP doesn't keep track of this.
However, there are some ideas for making it do so.  See reference
#3 on http://www.eecis.udel.edu/~mills/ntp.html

Levine, J., and D. Mills. Using the Network Time Protocol to transmit
International Atomic Time (TAI). Proc. Precision Time and Time Interval
(PTTI) Applications and Planning Meeting (Reston VA, November 2000).

Which points out that the list is permanently available from the
NIST time servers via

> And yet one more: The the possibility of ntp resetting my clock troubles
> me when I am meassuring difference time. Not enough though to forbid
> resetting. Is there any way of knowing if the clock was reset during the
> past few milliseconds or seconds? 

Check the log files.  Or use "ntpd -x" to forbid time steps.

More information about the questions mailing list