General-purpose computers (like a PC or Mac) do not generally have a very accurate clock. However they can be corrected by referring to an external clock. The most common method of correction is Network Time Protocol (NTP), and the most common external clock is an atomic clock over the internet. NTP gives excellent long term accuracy. But is this correction sufficient to give you accurate times for a Head race?
There are two main factors to consider when correcting the computer time with NTP:
NTP works by obtaining the time from a network or internet time server, and correcting the computer clock. The time comes ultimately from a caesium atomic clock. Every time you correct the clock, the time will be accurate to a very high degree. NTP is generally considered to give an accuracy to within a few milliseconds in the right circumstances.
In between synchronisations the computer clock runs at its normal level of (in)accuracy. So it is highly accurate every once in a while, and drifts off in between. The overall accuracy depends on how often it is corrected, and how far it wanders between corrections.
Windows by default will synchonise the clock once per week. This is sufficient for most computer operations but is far too infrequent for timing. You can use NTP software (on Windows, Mac, Linux, Android etc.) to manage the NTP process much more closely. The NTP project produces the source code, which is then compiled into different applications. Meinberg, who are specialists in precision timing hardware, provide a free NTP Windows client.
There is no fixed rule for how often to correct. We do not want a jump in time greater than one tenth of a second, and preferably (if possible) not greater than one hundredth if we are using video timing. An interval of 5 minutes seems about right. If the frequency is too high we might get blocked by the time server. If the frequency is too low we can expect bigger jumps each time the computer clock is corrected. See the test results below for an impression of how the corrections apply.
The variation in accuracy of NTP time correction comes from the network used to connect to the NTP time server. Assuming we are connecting to an internet time server, such as time.microsoft.com, then we might connect over: a high speed commercial internet connection; a broadband or cable connection; or over a mobile network. These will have very different latency characteristics. Latency is the time it takes to make a request to a time server and receive the reply.
NTP uses algorithms to check and correct the time received from a time server. For example, you might use several time servers. If they disagree you need to choose. Another example is the correction method. When correcting, you can either jump straight to the correct time, or you can merge in with it by correcting a small amount at a time.
To account for the network delay the basic algorithm is to halve the round trip time. For example, if you make a time request to an internet time server, and it takes 100ms to receive the reply, you can take 50ms from the time you receive it, and assume that this was the time when it was sent.
This works if the latency is symmetrical. But the internet is not symmetrical. There is no reason to assume that a message going to the time server takes the same amount of time as the message coming back, since there is no reason to assume they would take the same path. So in the case of the 100ms round trip time, you might assume that there could be a margin of error in the algorithm of perhaps 50ms i.e. the message might get there in 25ms but take 75ms to get back. You have no way to know for sure.
The higher the latency, and the greater the lack of symmetry, then the larger the margin of error. Over a mobile network you might have an average latency of 500ms, and sometimes as high as 1 second. In this case the margin of error might be several tenths of a second. Sometimes the request might time out altogether, and so the time will be uncorrected. This level of accuracy would be unacceptable for Head race timing.
There are plenty of studies showing the accuracy of NTP at the place the study was conducted. It is harder to test the accuracy of your own NTP connection, and the accuracy of your computer clock, without scientific equipment. Essentially you need two things:
Here is a simplified test of NTP accuracy. I have used a utility that: obtains the time from a time server; corrects the local clock; and measures the offset at each correction. I have measured the offset over a cable internet connection using wired ethernet; the same using a wireless connection; and using a mobile internet connection.
Caution: this test is using one NTP time server to correct the Windows clock, using the Windows Time Service. More accurate implementations of NTP are possible by: using more than one time server with an algorithm to select the most likely time; using a full NTP client with a more controllable clock, for example on UNIX or Linux.
In this simple test, although we cannot know the actual time at the measurement points we can see several interesting things:
The data is presented in a spreadsheet. A summary is:
NTP correction by wired ethernet over cable broadband
NTP correction by wireless ethernet over cable broadband
NTP correction by mobile internet
The accuracy of NTP time correction can be increased in several ways:
Alternatives to NTP are:
These options are described for reference. They may not offer a practical alternative for a Head race.
A new protocol, Precision Time Protocol (PTP) provides greater accuracy than NTP. PTP uses a network card to timestamp the incoming and outgoing time messages on client and server. It can therefore correct for network delay. However it requires a PTP server, and a software application on the client with the right network card drivers to use the precision time. Here is an example of a PTP network card from Symmetricom.
The computer clock will still need to be corrected, and will still be relatively inaccurate between corrections. However a PTP correction should keep the computer to roughly 5 milliseconds accuracy.
Another option is to have a local time server, using either GPS or radio as a time source. You would need one at each timing point. The computer would still use NTP to connect to the local time server. An example is the LANTIME M200 from Meinberg.
You could use a different clock, instead of the built in computer clock. The computer would output a request for time to one of these clocks, and receive back the precise time, obtained by synchronisation to GPS. An example of an external clock is the GPS170 from Meinberg.
Network Time Protocol (NTP) Project