[ntp:questions] Re: Question about synchronizing client and server clock

Richard B. Gilbert rgilbert88 at comcast.net
Tue Jan 6 04:01:10 UTC 2004

Well, you could start by downloading the NTP-4.2.0 distribution from 
www.ntp.org and reading the documentation.  There is a Windows port of 
the code but I have never built, installed or configured it.  The 
Windows Time Service meets my very modest needs.

My own, very limited, experience with NTP suggests that you are going to 
encounter great difficulty synchronizing the clocks of two machines to 
within one microsecond even if both are located in the same room. One 
millisecond is probably attainable without too much effort.

Consider the following scenario:

You have machines A, B, and C.  A is your server B is your client and C 
is your NTP server; A and B are both NTP clients.  You have two sites 
connected by a Wide Area Network (WAN).  A and C are located at one 
site, C is located at the second site, three hundred miles away.

An NTP Client timestamps a request packet and sends it to the server.  
The server adds its own timestamp to the packet and returns it.  The 
client timestamps the packet again with the time of receipt.  The client 
assumes symmetric timing for the request and its return and calculates 
how much time to add to or subtract from its own clock.  The transit 
times, of course, are almost never exactly symmetrical; all that the 
client can be certain of is that the server's timestamp occurred 
somewhere between the departure or the request and the return of the 
packet from the server and probably somewhere near the middle of that 
interval.  The error is, as the Professor says, bounded by the round 
trip time for the packet.  It can't be any worse than that, and we can 
hope for better.

The client adjusts both the time and the tick rate of its own clock to 
bring both closer to the server's time and tick rate.  Over a day or 
two, the time and tick rates of the client should converge to match 
those of the server.

We aren't done yet, however.  The client's clock is subject to drift 
with age, temperature, the phases of the moon and the whims of the 
gods.  So the client continues to bounce packets off the server, 
correcting it's errors as it goes.  Are your server A and your client, B 
going to agree on the time?  They will be close, probably within 
milliseconds but agreement within, say, 100 microseconds is unlikely.

Now suppose you equip A and B with good quality GPS timing receivers.   
They are still 300 miles apart.  Those GPS receivers will see different 
satellites and probably compute slightly different times.
The clocks will be better synchronized with each other but will still 
not agree.

Windows is not what I would call a real-time system and its interrupt 
latencies will probably affect your results adversely.  If Windows 
sometimes needs two microseconds to respond to an interrupt and 
sometimes needs three-and-a-half microsends, you have a 1.5usec 
uncertainty in your results.

See RFC1305 (www.ntp.org has a link to it) for details of how NTP 
works.  Get Windows to timestamp a series of one pulse per second ticks 
on  the DCD line of the serial port.   If the 1 PPS signal  is generated 
by a GPS receiver, the interval between ticks  should be 1.000000 
plus/minus 50 to 100 nsec.  What  interval does  Windows report and how 
consistent is it?   Get 50,000 samples and analyze them statistically.   
The interval that Windows measures will almost certainly not be 1.000000 
seconds.  The important measure is the consistency of the interval 
measured by Windows.  That will tell you how accurately Windows can 
timestamp events.  Try it while Windows is connected to the LAN;  does 
LAN traffic affect the results?

I think you may be in for a very interesting and educational 
experience!  If you are a graduate student, you might even get a 
Master's thesis out of the project.

Atri Mandal wrote:

>Thanks all of you for your comments and suggestions.
>I understand that you suggest the use of NTP to get both the client and server programs to
>follow the same time (of the server). I also looked at the functions ntp2nt() & nt2ntp() which
>have no documentation in MSDN;
>but I don't understand how to make the client and server programs point to the same server
>time using these 2 functions because these functions have no information about the server
>address; once I have synchronized them I can use ntp2nt() in both the programs seperately and
>calculate the time as you said.
>Can one of you please explain in more detail how to set up NTP; i.e. make the client and
>server agree on a specific time first after which I can use the ntp2nt() function calls.
>Danny Mayer wrote:
>>Atri Mandal <mandala at ics.uci.edu> wrote in message news:<3FF8F54B.31B9AF5F at ics.uci.edu>...
>>>Hi ,
>>>I am writing a client server code using WINSOCK 2.0 in which I have to
>>>calculate the exact time required by a piece of message to go from the
>>>client to the server or vice versa.
>>>i.e Suppose I have a client server model in which A is the client and B
>>>is the server.
>>>Let's say A has to send a message M to B by socket communication. I want
>>>the exact time taken by M to go from A to B.
>>>Currently I'm sending the message from A to B and then sending an
>>>acknowledgement from B to A(ack having the same size as original
>>>message) and then calculating the total time T taken for the round
>>>trip(this is easy because I just need  2 timer function calls
>>>within the client). Then I'm assuming that the time taken for A-B is
>>>T/2. This is however not precise because it might take a longer time to
>>>go from A-B rather than B-A.
>>>So is there any way I can calculate the exact one way communication time
>>>(with the precision at microsecond level or better) ?
>>>I think the best way is to use a synchronized clock for the client and
>>>server - Can anyone in this group please tell me how to implement this
>>>or give me pointers to example source code. I am quite new to this
>>Well this is exactly what NTP does. If you want to do timing experiments
>>like this, set up ntp on both client and server, disabling Windows time
>>service which would otherwise muck up the time as well. This will
>>synchronize the time on both systems. If you point both to the same
>>servers you will likely get both systems to agree on the time. Now you
>>can write your code to send and receive messages on the sockets to
>>calculate the time. If you do it right, you will include a timestamp
>>of the sending system with it's current time in the message, and the
>>server will return that along with its own timestamp. Now when you get
>>it back you add a third timestamp and you can save and analyze the time
>>taken in each direction. You will need to do this as many times as necessary
>>to get a good statistical average (there is no such thing as an exact time)
>>to smooth out activity on the network between the two systems.
>>If you are using Windows, I might suggest looking at two functions
>>SystemTimeToFileTime() and FileTimeToSystemTime(). Do your calculations
>>using FileTime which provides 64-bit integers though you have to copy
>>it to a ULARGE_INTEGER structure to do that. If you want to use ntp code
>>itself there is are two undocumented Win32 API functions in the IPHLPAPI DLL
>>called NTPTimeToNTFileTime() and NTTimeToNTPTime(). Unfortunately I don't
>>know the arguments to the calls.

More information about the questions mailing list