[ntp:questions] Re: Frequency and leapseconds!
cii99ec7 at i.lth.se
Wed Mar 9 01:12:15 UTC 2005
Thanks a lot Kevin for your reply!
I have now done meassurements on the computer frequency in terms of TSC (clock cycle counter) and found some annoying things. It turns out that when the clock is unsynced (ntp_adjtime() returns 5), the meassured clock frequency follows the (nominal frequency)+(skew from ntp_adjtime) exactly. However, when the clock is feeling alright the skewing is veird. If I or the NTPD sets the skew to 400 ppm for example this result in a correct frequency change at first. After only a little while though the meassured frequency skew starts to move down much faster than the skew from ntp_adjtime. See for your self.
Note the difference between column B and C below.
A: Frequency meassured in terms of computer nanoseconds/TSC cycle with repeated gettimeofday() and TSC readings with sleeps in between.
B: Skew from nominal frequency given from freq in ntp_adjtime()
C: Estimated real skew from nominal frequency.
Nominal frequency: 1.6752428945
16 secs between rows
NTP polling rate 16 secs.
The "default skew" is about 27 PPM on this machine.
A B C
1.6753108606 39.43089 41
1.6753107645 39.19969 40
1.6753106240 38.94756 40
*[ntptime -f 400 sets the skew to +400 PPM]*
1.6758960721 400.0000 401
1.6757398998 397.3787 297
1.6756331461 394.6032 234
1.6754730843 386.4843 137
1.6754097199 381.0005 99
1.6753613307 375.1088 71
1.6753249189 368.9386 49
1.6752478486 333.8764 29
This is done on Linux but meassurements on freeBSD show the same thing.
Does anyone know what's wrong and/or how to get around it?
I desperately want to know the clock frequency in terms of TSC cycles without meassuring it all the time. I dont need rocket science precision only like +/- 50 PPM.
From: questions-bounces at lists.ntp.isc.org on behalf of Kevin MacLeod
Sent: Sun 2/20/2005 7:50 AM
To: questions at lists.ntp.isc.org
Subject: [ntp:questions] Re: Frequency and leapseconds!
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
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.
questions mailing list
questions at lists.ntp.isc.org
More information about the questions