>>>But Windows provides a function, GetSystemTimeAsFileTime(), that
>>>allows you to query the system time in 100 nanosecond intervals. 
 
>>What you mean is that the function returns time with a theoretical
>>resolution of 100ns. However it would appear likely that the actual
>>times returned have a resolution of 10ms.  [rearranged slightly]
>>Write a program that busy loop calls this function and saves the results
>>over say 1000 calls.

>I wrote a program that retrieved 10,000 unique values from the
>GetSystemTimeAsFileTime() function, then analyzed the delta between
>consecutive times. Out of 9,999 deltas, 9,974 of them were 10.144
>milliseconds. 

Does anyone have code available to do this for Linux?

Drk,

See the jitter.c program in the NTP software distribution. Please also
reprise recent messages to this group on this topic.

Dave

Drk Ryan wrote:
> 
> >>>But Windows provides a function, GetSystemTimeAsFileTime(), that
> >>>allows you to query the system time in 100 nanosecond intervals.
> 
> >>What you mean is that the function returns time with a theoretical
> >>resolution of 100ns. However it would appear likely that the actual
> >>times returned have a resolution of 10ms.  [rearranged slightly]
> >>Write a program that busy loop calls this function and saves the results
> >>over say 1000 calls.
> 
> >I wrote a program that retrieved 10,000 unique values from the
> >GetSystemTimeAsFileTime() function, then analyzed the delta between
> >consecutive times. Out of 9,999 deltas, 9,974 of them were 10.144
> >milliseconds.
> 
> Does anyone have code available to do this for Linux?

ryandrk@hotmail.com (Drk Ryan) wrote in message news:<de98eac0.0309081038.363f4d33@posting.google.com>...
>
> Trying to use the jitter.c program I get:
> 
> 
> Compiling...
> jitter.c
> c:\ntp-4.1.1a\util\jitter.c(11) : fatal error C1083: Cannot open
> include file: 'sys/time.h': No such file or directory
> Error executing cl.exe.
> 
> jitter.exe - 1 error(s), 0 warning(s)
> 
> How do I fix this error? I can't understand the command lines for the
> Build Log in jitter.html

The compiler can't find the standard system header file time.h.  Check
you operating system documentation to determine how to populate the
standard files required to compile C programs.


roy
-- 
The suespammers.org mail server is located in California.  Please do
not send unsolicited bulk e-mail or unsolicited commercial e-mail to
my suespammers.org address or any of my other addresses.  These are my
opinions, not necessarily my employer's.

Drk,

Can't help you; the problem is system dependent. You will have to figure
out where that include file is.

Dave

Drk Ryan wrote:
> 
> "David L. Mills" <mills@udel.edu> wrote in message news:<3F5A3890.D5E8F5AD@udel.edu>...
> > Drk,
> >
> > See the jitter.c program in the NTP software distribution. Please also
> > reprise recent messages to this group on this topic.
> >
> > Dave
> >
> 
> Trying to use the jitter.c program I get:
> 
> Compiling...
> jitter.c
> c:\ntp-4.1.1a\util\jitter.c(11) : fatal error C1083: Cannot open
> include file: 'sys/time.h': No such file or directory
> Error executing cl.exe.
> 
> jitter.exe - 1 error(s), 0 warning(s)
> 
> How do I fix this error? I can't understand the command lines for the
> Build Log in jitter.html

"David L. Mills" <mills@udel.edu> wrote in message news:<3F5D41B4.AF8D8D8B@udel.edu>...
> Drk,
> 
> Can't help you; the problem is system dependent. You will have to figure
> out where that include file is.
> 
> Dave


I think this is it:
C:\ntp-4.1.1a\ports\winnt\include\sys\time.h

However, including this path gives me an error saying that ntp_types.h 
cannot be found.

ryandrk@hotmail.com (Drk Ryan) writes:

> >>>But Windows provides a function, GetSystemTimeAsFileTime(), that
> >>>allows you to query the system time in 100 nanosecond intervals. 
>  
> >>What you mean is that the function returns time with a theoretical
> >>resolution of 100ns. However it would appear likely that the actual
> >>times returned have a resolution of 10ms.  [rearranged slightly]
> >>Write a program that busy loop calls this function and saves the results
> >>over say 1000 calls.
> 
> >I wrote a program that retrieved 10,000 unique values from the
> >GetSystemTimeAsFileTime() function, then analyzed the delta between
> >consecutive times. Out of 9,999 deltas, 9,974 of them were 10.144
> >milliseconds. 
> 
> Does anyone have code available to do this for Linux?

Drk,

call gettimeofday() twice and subtract. If you won't believe in the
method, describe what you are expecting as result.

Regards,
Ulrich

P.S: If you are lazy:
ntpq> rl
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.1.1@1.786 Tue Feb  4 16:39:46 UTC 2003 (1)",
processor="i586", system="Linux2.4.19-4GB", leap=00, stratum=2,
precision=-18, rootdelay=44.226, rootdispersion=275.741, peer=23695,
refid=lanczos.maths.tcd.ie,
reftime=c30861df.02caab8a  Tue, Sep  9 2003 16:27:43.010, poll=7,
clock=c308624c.95697f1f  Tue, Sep  9 2003 16:29:32.583, state=4,
offset=23.011, frequency=-15.395, jitter=15.000, stability=25.487

Precision means 2^-18 seconds...

ryandrk@hotmail.com (Drk Ryan) writes:

> "David L. Mills" <mills@udel.edu> wrote in message news:<3F5A3890.D5E8F5AD@udel.edu>...
> > Drk,
> > 
> > See the jitter.c program in the NTP software distribution. Please also
> > reprise recent messages to this group on this topic.
> > 
> > Dave
> > 
> 
> Trying to use the jitter.c program I get:
> 
> 
> Compiling...
> jitter.c
> c:\ntp-4.1.1a\util\jitter.c(11) : fatal error C1083: Cannot open
> include file: 'sys/time.h': No such file or directory
> Error executing cl.exe.

QUOTING YOURSELF: ``Does anyone have code available to do this for
Linux?''

Does cl.exe run with Linux???

Ulrich

> 
> jitter.exe - 1 error(s), 0 warning(s)
> 
> How do I fix this error? I can't understand the command lines for the
> Build Log in jitter.html

Ulrich,

For whatever good or bad come come of it, the actual ntpd precision is
calculated by calling get_systime(), which reads the system clock with
the highest resolution syscall available. So, what ntpd calls precision
is actually the time to cycle through the kernel and read the clock, not
the inherent resolution of the clock counter, which can be much less
than the precision. For instance, a Sun Blade 1000 has a clock counter
resolution of a bit more than a nanosecond, but a precision of about 400
ns. But, the actual resolution when reading the Blade clock is rounded
up to the next nanosecond.

While the procedure reads the clock several times, it is a bit more
tricky than first apparent. Some kernels (nanokernel/microkernel at
least from here) require Lamport's happens-before relation be rigorously
defended, so if the clock counter is really gross, like old Sun 500
microseconds, and the clock is read several times during that clock
tick, the time advances by une unit (nano or micro) for each read.
Unless detected and avoided, this could mislead the results. Time is so
fickle and intricate.

Dave

Ulrich Windl wrote:
 
> Drk,
> 
> call gettimeofday() twice and subtract. If you won't believe in the
> method, describe what you are expecting as result.
> 
> Regards,
> Ulrich
> 
> P.S: If you are lazy:
> ntpq> rl
> status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> version="ntpd 4.1.1@1.786 Tue Feb  4 16:39:46 UTC 2003 (1)",
> processor="i586", system="Linux2.4.19-4GB", leap=00, stratum=2,
> precision=-18, rootdelay=44.226, rootdispersion=275.741, peer=23695,
> refid=lanczos.maths.tcd.ie,
> reftime=c30861df.02caab8a  Tue, Sep  9 2003 16:27:43.010, poll=7,
> clock=c308624c.95697f1f  Tue, Sep  9 2003 16:29:32.583, state=4,
> offset=23.011, frequency=-15.395, jitter=15.000, stability=25.487
> 
> Precision means 2^-18 seconds...

"David L. Mills" <mills@udel.edu> writes:

> Ulrich,
> 
> For whatever good or bad come come of it, the actual ntpd precision is
> calculated by calling get_systime(), which reads the system clock with
> the highest resolution syscall available. So, what ntpd calls precision
> is actually the time to cycle through the kernel and read the clock, not
> the inherent resolution of the clock counter, which can be much less
> than the precision. For instance, a Sun Blade 1000 has a clock counter
> resolution of a bit more than a nanosecond, but a precision of about 400
> ns. But, the actual resolution when reading the Blade clock is rounded
> up to the next nanosecond.

Dave,

for practical use: Does it make any difference? The only way to
observe the system clock is by making system calls. If you see just
nanoseconds or multiples of it, you may assume the clock has no better
resolution. Did I think wrong?

> 
> While the procedure reads the clock several times, it is a bit more
> tricky than first apparent. Some kernels (nanokernel/microkernel at
> least from here) require Lamport's happens-before relation be rigorously
> defended, so if the clock counter is really gross, like old Sun 500
> microseconds, and the clock is read several times during that clock
> tick, the time advances by une unit (nano or micro) for each read.

For my hardware this has never been a problem, because you cannot
execute two system calls within the same nanosecond. Even for a
microsecond you need a really fast machine. Still, the
time-compression is only temporary, right? I mean the amount is
returned to the user but the system clock doesn't get that amount
added.

Regards,
Ulrich

> Unless detected and avoided, this could mislead the results. Time is so
> fickle and intricate.
> 
> Dave
> 
> Ulrich Windl wrote:
>  
> > Drk,
> > 
> > call gettimeofday() twice and subtract. If you won't believe in the
> > method, describe what you are expecting as result.
> > 
> > Regards,
> > Ulrich
> > 
> > P.S: If you are lazy:
> > ntpq> rl
> > status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> > version="ntpd 4.1.1@1.786 Tue Feb  4 16:39:46 UTC 2003 (1)",
> > processor="i586", system="Linux2.4.19-4GB", leap=00, stratum=2,
> > precision=-18, rootdelay=44.226, rootdispersion=275.741, peer=23695,
> > refid=lanczos.maths.tcd.ie,
> > reftime=c30861df.02caab8a  Tue, Sep  9 2003 16:27:43.010, poll=7,
> > clock=c308624c.95697f1f  Tue, Sep  9 2003 16:29:32.583, state=4,
> > offset=23.011, frequency=-15.395, jitter=15.000, stability=25.487
> > 
> > Precision means 2^-18 seconds...

Ulrich Windl <Ulrich.Windl@RZ.Uni-Regensburg.DE> wrote in message news:<m33cf4vgmn.fsf@pc5234.klinik.uni-regensburg.de>...
> "David L. Mills" <mills@udel.edu> writes:
> 
> Dave,
> 
> for practical use: Does it make any difference? The only way to
> observe the system clock is by making system calls. If you see just
> nanoseconds or multiples of it, you may assume the clock has no better
> resolution. Did I think wrong?
> 
> > 
> > While the procedure reads the clock several times, it is a bit more
> > tricky than first apparent. Some kernels (nanokernel/microkernel at
> > least from here) require Lamport's happens-before relation be rigorously
> > defended, so if the clock counter is really gross, like old Sun 500
> > microseconds, and the clock is read several times during that clock
> > tick, the time advances by une unit (nano or micro) for each read.
> 
> For my hardware this has never been a problem, because you cannot
> execute two system calls within the same nanosecond. Even for a
> microsecond you need a really fast machine. Still, the
> time-compression is only temporary, right? I mean the amount is
> returned to the user but the system clock doesn't get that amount
> added.
> 
> Regards,
> Ulrich
> 
> > Unless detected and avoided, this could mislead the results. Time is so
> > fickle and intricate.
> > 
> > Dave
> > 

It's worse than that. The topic subject has no real meaning. You cannot
measure ACTUAL resolution. You can only estimate it with some error range.
Moreover the act of measuring interferes with what is being measured.
See Heisenberg's Uncertainty Principle for details. Things like standard
deviation are important here. Standard CPU clocks can also fluctuate in
their 'tick'. CPU manufacturers have to test that before they ship the
chip. That doesn't mean that they won't ship chips that wildly vary. There
was a recent discussion of this issue. Jeff Mogul, who has more information
that I do had responded to that discussion.

Danny

>"David L. Mills" <mills@udel.edu> wrote in message 
> 
> See the jitter.c program in the NTP software distribution. 


How are the results of jitter.c interpreted?

What does Last rank refer to?

Drk,

That program is a hack and never intended as a teaching tool. Its
function is revealed in the source code. I did comment on the results in
an earlier message to this group. The results can be interpreted any way
you find useful for statistical analysis, algorithm design or just plain
curiousity.

Dave

Drk Ryan wrote:
> 
> >"David L. Mills" <mills@udel.edu> wrote in message
> >
> > See the jitter.c program in the NTP software distribution.
> 
> How are the results of jitter.c interpreted?
> 
> What does Last rank refer to?