This page is dedicated to clocks that give the correct time!
This project was prompted by my hatred of clocks which do not indicate the correct time. The coming of the train required the Victorians to synchronise clocks throughout the country. With the advent of computer networks, it was neccessary to repeat the process, but more acurately this time!
With the help of many other people, I have implemented a scheme to sychronise the clocks of all local computers. The primary time source is a GPS clock which provides highly accurate Universal Time (UT) which is then distributed to all other machines.
There have been many attempts to synchronise computers, but the most effective is the Network Time Protocol (NTP) version 3, based on RFC-1305, and for backward compatibility with version 1 and 2 servers, RFC- 1059 and RFC-1119. Unfortunately this does not seem to have been adopted into Unix or other operating systems. It is therefore necessary to add support for NTP to most systems. Local NTP documentation
I compiled NTP version 3.5.90 available from NTP home page which worked straight out of the box with irix 5.3 on an SGI Challenge machine.
The local (RSPP) time synchronisation solutionThe primary time sourse is a Kallisto GPS time reference. This consists of a GPS receiver on an ISA card in a PC running Windows NT Server 4.0. TimeServ - part of the NT Server Resource Kit - provides support for the Kallisto and sets the PC system clock to UT. TimeServ also acts as a server providing time to other computers running Windows 95 and NT.
The NT server also runs a version of xntpd which implements the Network Time Protocol (NTP). This takes the time from the system clock and serves it to NTP clients which request it. In this configuration the NTP server (the PC) is the primary source of time. This differs from the normal NTP implementation which requires that all time is traceable to an absolute time standard with computers seeking time from multiple networked secondary time sources. With the advent of low cost GPS time references providing high accuracy, high reliability time, the need to share expensive time sources is reduced making it practical for sites to provide their own synchronisation schemes without reference to external sources of time. In this scheme xntp on the NT Server is the primary source, in NTP parlance a stratum 1 time reference (in practice it advertises itself as as stratum 4 reference to reflect the accuracy actually achieved).
Ion, our main UNIX server, runs xntpd which acts both server and client. As a client it looks at the NT Server time and synchronises the local clock to the time provided by the GPS receiver. It also acts as a server to provide time to NTP clients within our local network domain. (NTP does not pass beyond our network as it is blocked by the local ethernet bridge.)
User machines (workstations, PCs etc) are able to set their clocks by refering to ion's local clock. The exact method depends on the platform:- SGI workstations - timslave (part of the OS) or xntpd (public domain)
There are a wide range of solutions available for many platforms which will sychronise local clocks with more accurate clocks.
Accuracy and reliabilityNTP is theoretically capable of achieving 230 pico-second accuracy! Dispite my undoubted paranoia about clocks, even I do not think that this level of accuracy is neccessary. In our environment an accuracy of 1 milli-second is quite adequate. This solution is easily capable of achieving this level of accuracy.
We also need to consider what happens if things go wrong. The loss of the the GPS reference would result in the time to rely on the free running NT machine local clock. Whilst this would not provide an accurate time source, it would be adequate for most purposed until GPS time could be restored
The loss of the NT machine itself would result in the ion local clock freewheeling. xntpd would continue to provide somewhat improved time compared to the clock alone since it takes note of the normal clock drift. Breaks of a few hours duration, the likely time to repair or replace the NT service, are unlikely to cause any noticable problems. With the return of teh NTP time source, ion will recover without intervention.
Network breaks, an area requiring major attention in conventional NTP implementations, is not a problem in our environment. Our network, like many others in practice, is a single point of failure. If it breaks, then everything breaks, and the loss of an accurate time reference is the least of our worries! Whilst we have tried to do everything possible to overcome this potential weakness, there is no topology which is entirely satisfactory in this respect. In practice, this type of failure is very rare - normally associated with the loss of power to all machines.
Cost effectivenessOr how much does it cost. Well the solution described here required only an additional GPS time reference card (Kallisto) which is available for a few hundred pounds. The software is all available either in the public domain or as shareware costing surprisingly little.
This solution, therefore, is very cost effective, as well as providing a level of accuracy which is adequate for the needs of most sites. Larger sites, with multiple network segments and domains, might choose to employ several GPS time reference machines distributed geographically to provide resilience to network failures, but the principle would remain the same.
Pointers to software applications which form part of the time synchronisation system:-TimeServ - part of NT Server Resource Kit available from Microsoft
Tardis - available for Win3.1, Win95 and NT (Shareware)
Network_Time_2.0.1.sit.Hqx - Network_Time for Macintosh (Shareware)
Thanks to the many people who have made this possibleJulian for designing the Kallisto and associated software
To Doug Hogarth for adding support to TimeServ for the Kallisto
The many people who have contributed to the development of xntpd
This page has been visited times since 1/7/97 (only external accesses counted)