Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!TRANSARC.COM!Craig_Everhart
From: Craig_Everhart@TRANSARC.COM
Newsgroups: comp.protocols.time.ntp
Subject: Re: precision
Message-ID: <EcHu9vz0BwwOJmUFt7@transarc.com>
Date: 7 Jun 91 15:12:59 GMT
References: <18313@celit.fps.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 54

I believe that the ``precision'' concept is used only to create an
envelope around a given clock reading.  On a 50Hz clock, say, a given
microsecond reading can be good only to the nearest(?) 1/50'th second. 
On a real microsecond clock, it is possible to be precise to the
microsecond.  This is a useful concept when you're reading a remote
clock multiple times, and comparing it against your own clock; you use
the precision of the remote clock and that of your own clock to help you
interpret the differences.  For example, if your clock and some other
clock are both precise only to 50Hz, any reading of either of them could
be off by 20 milliseconds.  If you read your clock and the other clock
at the same time, up to 40 milliseconds of their difference could be
attributable to their imprecision.

Precision is different from accuracy.  Venturing definitions here,
accuracy represents how close a value is to truth; precision is instead
like the number of significant figures in a value.  A temperature value
of 98.95923331 (deg. F.) for my body temperature is very precise, but
it's probably accurate only to half a degree.

There was a program floating around that made a good guess as to the
precision of your local clock by making calls to gettimeofday() and
looking at the smallest difference in microsecond values that it got. 
There was a bit of trickiness at high precision, since lots of
gettimeofday() routines remember the last result returned, and make sure
that each successive call got a unique value--generally by adding 1 to
the microsecond counter.  Of course, even if one program on a system
calls gettimeofday() in a tight loop, there are other callers of the
same kernel routine, so the values you get back could increment by 2 or
3 or 5 or more even if there's no real extra precision there.  The
program interpreted successive microsecond values of
    n, n, n, n, n+20000, n+20000,
	-> 50Hz precision
    n, n, n, n, n+16666, n+16666,
	-> 60Hz precision
    n, n, n, n, n+1000, n+1000,
	-> 1000Hz precision
as well as the tricker
    n, n+1, n+2, n+3, n+1000, n+1001,
	-> 1000Hz precision
    n, n+1, n+4, n+5, n+500, n+502,
	-> 2000Hz precision
and it's just plain tricky to calculate:
    n, n+1, n+3, n+4, n+7, n+8, n+14, n+15, ...
	-> very precise clock or very busy gettimeofday() routine???

Given all this, you can probably set your precision value based on the
smallest possible meaningful difference between gettimeofday() calls. 
If you really have a microsecond crystal behind your gettimeofday()
call, it sounds like you could reasonably claim that your precision is
-20 (1000000Hz ticker).

		Craig