[ntp:questions] TSC, default precision, FreeBSD

Janusz U. nopsoft at poczta.onet.pl
Sat Sep 5 10:06:27 UTC 2009


Quotes of Dave Mills:
"I can't speak for FreeBSD internals or the data you cite. The system
perecision is deterined by the default_get_precision() routine in
ntp_proto.c, which in turn calls get_systime() in the library. That
routine in turn calls Unix gettimeofday() or whatever routine can
deliver a timespec. It has nothing to do with the frequency, TSC or
anything other than the time it takes to perform the get_systime() call.
I run FreeBSD in a number of machines here and see no difference in
behavior between them and the Solaris machines I also run here. Of
course, 4.1.1 has not run here for a very long time; however, the
routines I cited have not been changed for an equally long time."

"The FreeBSD code was added over my objections and I have no
knowledge of its source. You are completely on your own to research this
issue and I would appreciate it if you would leave me out of subsequent
activities.."

Me:
"Today, from NTP point of view, it is comparable but the fragment code:
>>>>> -#if defined(__FreeBSD__) && __FreeBSD__ >= 3
>>>>> - u_long freq;
>>>>> - size_t j;
>>>>> -
>>>>> - /* Try to see if we can find the frequency of of the counter
>>>>> - * which drives our timekeeping
>>>>> - */
>>>>> - j = sizeof freq;
>>>>> - i = sysctlbyname("kern.timecounter.frequency", &freq, &j , 0,
>>>>> -     0);
>>>>> - if (i)
>>>>> - i = sysctlbyname("machdep.tsc_freq", &freq, &j , 0, 0);
>>>>> - if (i)
>>>>> - i = sysctlbyname("machdep.i586_freq", &freq, &j , 0, 0);
>>>>> - if (i)
>>>>> - i = sysctlbyname("machdep.i8254_freq", &freq, &j , 0,
>>>>> -     0);
>>>>> - if (!i) {
>>>>> - for (i = 1; freq ; i--)
>>>>> - freq >>= 1;
>>>>> - return (i);
>>>>> - }
>>>>> -#endif

seems to change it. It appeared and dissapeared in ntp_proto - no documented
reason or who and when did it. Of course, today the fragment need to be a
little updated but fact of using TSC frequency directly is interesting. And
another think is why NIST has better precision than me? At start I thought
there is a better computer, but not - it is effect FreeBSD6 + NTP4.1.1 and
default_get_precision()... So where is the truth of NTP precision? It is
difficult to compare values which are differently measured..."

Quote of Poul-Henning Kamp:
">>>>>> - i = sysctlbyname("kern.timecounter.frequency", &freq, &j , 0,
>>>>>> -     0);

This is the correct way to get the precision on all FreeBSD versions
after FreeBSD 3.

I have no idea why that code was removed."

Quote of Dave Mills:
"The FreeBSD precision code was removed because it was misguided[...].
By definition in the spec and implementation the
precision is defined as the latency to read the system clock. The
FreeBSD code was an attempt to define the resolution, not the precision.
Now you have an idea why the code and any other like it was removed."

Summary: your choice? NO - "By definition in the spec and implementation the
precision is defined as the latency to read the system clock"

My short explanation:
The key is "PRECISION" word
look at: http://en.wikipedia.org/wiki/Accuracy_and_precision and 
http://www.tutelman.com/golf/measure/precision.php
look at: http://www-users.mat.uni.torun.pl/~gapinski/storage/NTP.pps and 
http://phk.freebsd.dk/pubs/timecounter.pdf

default_get_precision() measures system precision according to definition: 
"the latency to read the system clock". So according to Poul-Henning Kamp it 
is a precision. According to eg. wiki it is an accuracy...
Then, when NTPD have got measured "precision" variable it is used as random 
parameter (extra noise) in time reading function. So then "precision" means 
really precision.

Finally:
current host set to time-a.timefreq.bldrdoc.gov
ntpq> pe
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
*LOCAL(0)        .ACTS.           0 l   52   64  377    0.000    0.000 
0.000
ntpq> rv
assID=0 status=0534 leap_none, sync_local_proto, 3 events, 
event_peer/strat_chg,

version="ntpd 4.1.1b at 1.829 Sat Aug  9 06:44:47 MDT 2008 (20)",
processor="i386", system="FreeBSD6.2-RELEASE", leap=00, stratum=1,
precision=-29, rootdelay=1.300, rootdispersion=2.000, peer=57588,
refid=ACTS, reftime=ce4cb492.66226c44  Sat, Sep  5 2009 11:57:38.398,
poll=4, clock=ce4cb4ca.e66033d8  Sat, Sep  5 2009 11:58:34.899, state=0,
offset=0.000, frequency=0.000, jitter=0.000, stability=0.000

and

ntpq> host time-a.nist.gov
current host set to time-a.nist.gov
ntpq> pe
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
*LOCAL(0)        .ACTS.           0 l    4   64  377    0.000    0.000 
0.000
ntpq> rv
assID=0 status=0534 leap_none, sync_local_proto, 3 events, 
event_peer/strat_chg,

version="ntpd 4.1.1b at 1.829 Sat Aug  9 06:44:47 MDT 2008 (20)",
processor="i386", system="FreeBSD6.2-RELEASE", leap=00, stratum=1,
precision=-29, rootdelay=1.300, rootdispersion=2.000, peer=13300,
refid=ACTS, reftime=ce4cb547.1da2158f  Sat, Sep  5 2009 12:00:39.115,
poll=4, clock=ce4cb54c.ec38d85f  Sat, Sep  5 2009 12:00:44.922, state=0,
offset=0.000, frequency=0.000, jitter=0.000, stability=0.000

and

ntpq> host nist1.symmetricom.com
current host set to nist1.symmetricom.com
ntpq> pe
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
*LOCAL(0)        .ACTS.           0 l    5   64  377    0.000    0.000 
0.000
ntpq> rv
assID=0 status=0534 leap_none, sync_local_proto, 3 events, 
event_peer/strat_chg,

version="ntpd 4.1.1b at 1.829 Sat Aug  9 06:44:47 MDT 2008 (20)",
processor="i386", system="FreeBSD6.1-RELEASE", leap=00, stratum=1,
precision=-29, rootdelay=1.300, rootdispersion=2.000, peer=4092,
refid=ACTS, reftime=ce4cb619.c210dbc5  Sat, Sep  5 2009 12:04:09.758,
poll=4, clock=ce4cb620.31822df1  Sat, Sep  5 2009 12:04:16.193, state=0,
offset=0.000, frequency=0.000, jitter=0.000, stability=0.000

It seems the precision could be not good value. Where is the truth I am 
asking again? Software or hardware solution?

best regards
Janusz Uzycki






More information about the questions mailing list