Correct Time at UW
Why worry about time?
To varying extents, time is important to all of us. To an individual, it's
important to get to classes and appointments on time. For computers, it can be
important to have accurate times to properly synchronize logged events such as
attempts to violate security policies. Experiments that are computer-controlled
may need very accurate time to correlate observed events. Because time is
important, we need a method to accurately obtain time, to set time on computers,
and to keep it accurate.
IT's solution
In order to provide time service to the UW campus, IT has purchased an accurate
time source which is based on the Global Positioning System (GPS). The time server
itself will normally maintain proper time (Universal Coordinated Time, UTC) to
within about 20 microseconds. This is called a primary time source, or
"stratum 1" time server within the terminology of network time services.
The server is a TymServe 2100 from Datum Incorporated.
This server provides time to several secondary systems which comprise secondary
(stratum 2) servers. These servers query our primary, as well as other network
time servers, and normally maintain time to within 10 or 20 milliseconds of UTC.
Within IT, these systems are chosen based on their high availability and
reliability. The time is then hierarchically distributed to less-critical systems.
What is NTP?
Network Time Protocol (NTP) is a network protocol, as are Telnet and FTP.
It allows systems to exchange time, including corrections for network delay.
The essentials of NTP are rather simple but the implementation is quite complex
due to the amount of processing required to maintain and correct time on the local
system. See http://www.ntp.org for an
introduction and other information.
NTP is a continuous protocol. It doesn't simply ask a server for the time and
jam that into the local computer. Instead, it repeatedly queries a server to build
up a behavior profile of the network and the local clock, and only if the time has
a high "quality" will NTP start making adjustments to the local clock.
If the clock is wrong by a huge amount (e.g. well over an hour) NTP will
frequently refuse to make adjustments (and quietly die), as a sort of "sanity
check." If the clock is wrong by a moderate amount (over 1/2 second) then the
local clock is usually "stepped" to the correct time. If the clock is
wrong by a small amount (less than 1/2 second) then NTP attempts to gently nudge
it to the correct time by causing it to run slightly fast or slow, as needed. This
last step is continuous, as NTP polls the source periodically and keeps making
adjustments (no clock is perfect, so there will always be a drift in one direction
or the other, which can even change direction based on temperature). If the local
clock is very poor, NTP may not be able to cope with it.
NTP has been shown to be a poor performer if the local clock is more than about
.01% to .02% fast or slow to begin with. NTP has evolved over many years, and the
current level is version 4 (no RFC has been published, but version 3 is described
in RFC-1305).
A subset of NTP is Simple NTP, or SNTP. It dispenses with the complexities of
estimating network delays, and is good enough to set local clocks to an accuracy
of about a second. SNTP clients should never attempt to serve their time to other
systems. SNTP is described in RFC-1361. Much more information on NTP and available
clients is at http://www.ntp.org.
What about non-NTP solutions?
There are older protocols such as the Daytime Protocol (RFC-867), and the Time
Protocol (RFC-868, often implemented via the rdate command in UNIX). IT servers do
support these protocols as well as NTP.
What about NTP broadcasts?
Some NTP servers can be configured to broadcast time across an entire network
or subnet. The clients then just listen for these broadcasts. IT does not support
broadcast NTP.
How do I keep my system clock accurate?
This depends on the type of system you have: desktop PC, UNIX workstation, or
large server, and the operating system you're running. It also depends on your
needs.
Desktop PCs running Windows 98, NT, 2000, with access to IT servers
The basic approaches are:
At a command line prompt, enter one of the following
net time /domain:uwyo /set /y (Windows NT)
or
net time \\ranger /set /y (Windows 98)
This will set your time according to the UWYO domain controller, which is in turn a stratum-2 server. However, it will only set
the clock, it will not maintain it. In other words your clock will drift without
compensation, as before.
Windows XP and 2000 systems that are part of a domain will automatically synchronize
their clock to the domain controller so no setup is required. However, if your
system is not part of a domain, you are in the same situation as above but need
to use the command
If you wish to periodically set your PC's time, you can schedule the above
command to execute periodically (daily, for example).
Automatic scheduling is built in to Windows NT, Windows 98, and Windows 2000.
Another alternative is to put the command in a batch file, create an icon, and
double-click it whenever you feel like it.
Other packages exist, but IT has no experience with them. Use at your own
risk, for example:
UNIX workstations and small servers
For these systems, the standard implementation of NTP is called "xntp"
(version 3) or “ntp” (version 4) which is available via ftp.udel.edu. Check your operating system
documentation; there may be an NTP client included as a standard network
application (e.g. Solaris 2.6 and up).
Which server should you point NTP at? IT’s preferred stratum-2 servers are
called time1, time2, time3, and time4 (note these are aliases (DNS CNAME
records) so when you put these in your ntp configuration file, ntp will display
the systems’ true names in the output of commands such as “ntpq –p”). If
your own department or college has chosen to serve time to its systems, please
refer to that server instead.
Large servers and departmental/college time servers
Such systems may have NTP built-in, or you may need to acquire ntp as above.
In this case, we suggest accessing the stratum-1 server in IT as well as
several other public servers. We heartily discourage other users from directly
accessing these stratum-1 servers, in order to keep load on them to a point
where they can continue to supply highly accurate time. They should be used only
when very accurate time is justified for a system, for example if it will serve
in turn as a stratum-2 server.
Critical needs
If you feel your need for time is genuinely critical, you might want to
consider purchasing your own stratum-1 time source. The TymServe 2100 starts at
about $6,000 and can supply time via NTP (version 2 or 3), IRIG-B, 1 PPS output,
and an accurate frequency source. Datum also sells a less expensive model 2100L.
Truly critical time should be based on several sources (four minimum) with
diversity of method. By this we mean four of the same make/model primary source
is a bad idea, as was discovered on January 1 2002 when most TrueTime servers
jumped ahead by over 20 years.
Daylight Savings Time (DST)
This is actually not the business of the time server, or of NTP. It is up to
the client systems to handle this. In the case of UNIX, time is maintained
internally in UTC, and converted to local time using rules that include DST.
Microsoft systems also automatically compensate for DST.
Leap seconds
Since UTC is based on observed solar time, and the planet Earth is slowing
down, occasionally UTC needs to have leap seconds inserted as a correction. NTP
takes this into account, and can propagate a warning to clients when a leap second
is about to occur. How this is handled is up to the client. When a leap second is
inserted, there will be 61 seconds in the last minute of the last hour, meaning a
time of 23:59:60 which is otherwise never seen. Though possible, a leap second
could also be subtracted from the timescale; this has not happened yet.
