[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
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>...
>>>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