Re: Any samples for NTP/SNTP client code?

On Dec 2, 7:03 am, da...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (David
Woolley) wrote:
In article <68f4c629-f605-40ff-8e02-2ca1deb0f...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,

guu...@xxxxxxxxxxx wrote:
In article <90967f07-83ca-4d79-8acb-1c3056ce3...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,

guu...@xxxxxxxxxxx writes:
Does anybody know of any *practical* samples on how to
implement NTP/SNTP client?. The goal is to provide accurate

From your description, NTP is not an option, as implementing NTP requires
implementing most of the relevant (draft) RFC. What you are discussing is
only SNTP.

Existing packages set the PC system/CMOS clock, and my application
would have to read it which is not very reliable approach.

If Vista still doesn't interpolate between clock ticks, it is unlikely
that your application is going to have precise enough scheduling delays for
things to really matter. The real problem is you've chose an HCI platform
for use in a timing critical application.

On a platform that does interpolate clock ticks, you should expect a one to
two orders of magnitude better time by reading the system clock, synchronised
by NTP, as compared with doing a one off SNTP exchange. If the clock ticks
aren't interpolated, you need a very good understanding of the scheduling
and interrupt latencies in your system, which will probably make extracting
the SNTP packet details from the NTP or, better, SNTP specifications, trivial.
I don't think Vista has been around long enough for such information to become
available, and most IT managers seem to be avoiding Vista like the plague, so
it may be some time before someone interested in accurate time makes the
measurements.


You seem to assume the ticks used by the PC system time, e.g. you get
them
with GetTickCount(). Most if not all new PC's have an extra hardware
chip called
high-performance counter (probably located in the processor itself,
maybe even
use the cycle rate of the processor clock). You read such a counter
with
QueryPerformanceCounter() directly off the hardware. Windows
scheduling has no impact here, the drawbacks of tick counts do not
apply here.
The high-performance counter has frequency 5-20MHz depending on the
PC model,
i.e. you get resolution of less than 1 microsec/count, directly off
the hardware.
The issue here is what is the drift of this counter. Once I code my
SNTP client
I will check it, ans also I will compare to PC ticks.



WinZip, which most power users of Windows seem to have, can handle this.
Also, to the best of my recollection, gzip compiles easily on Windows and
there ought to be Windows builds of it around on the net.

The problem with any "free" utilities for Windows is that I have to
spend the time to
decide which one of them is safe enough to install on my PC.
Nowadays, most of them
are infested with viruses and crapware. I plan to use my very old PC,
now packed in a box.



.

Relevant Pages

  • Re: Windows wont settle
    ... W32TIME is an implementation of SNTP rather than NTP. ... Then again, Windows being Windows, you may not. ...
    (comp.protocols.time.ntp)
  • Re: Any samples for NTP/SNTP client code?
    ... On a platform that does interpolate clock ticks, you should expect a one to ... as compared with doing a one off SNTP exchange. ... the SNTP packet details from the NTP or, better, SNTP specifications, trivial. ...
    (comp.protocols.time.ntp)
  • Re: ntp not synchronising
    ... The time constraints for Windows are based on the requirements for the ... public Stratum 2 server. ... seconds off from WWV and WWVH radio when using the built in SNTP service. ... I was never successful at getting a third party NTP ...
    (comp.os.vms)
  • Re: Windows wont settle
    ... It has slowly drifted from -2 ms right after starting NTP up to -69 ms now. ... Machine 1 is still running Windows time service (Microsoft's questionable implementation of SNTP), and is performing quite well right now. ...
    (comp.protocols.time.ntp)
  • Re: NTP Time Server in 2000
    ... Windows 2000 uses SNTP where as Windows 2003/Unix use NTP. ... > or the SNTP port. ...
    (microsoft.public.win2000.networking)
Loading