Network Time Protocol

urls:

http://nist.time.gov/- U.S. times from the National Institute of Standards and Technology (NIST) clock.

http://tf.nist.gov/service/its.htm- directions for getting UTC from NIST.

http://www.eecis.udel.edu/~mills/ntp/clock2a.html- the stratum 2 servers with a link to the stratum-1 servers

http://www.ntp.org/- the offical NTP page.

http://www.sun.com/solutions/blueprints/0901/NTPpt3.pdf - Sun’s blueprint on NTP

http://www.sun.com/solutions/blueprints/0801/NTPpt2.pdf

http://www.sun.com/blueprints/0701/NTP.pdf

 

The clock on a computer's main board is not very accurate, but for most of us, it's good enough for everyday use.  Little by little, it drifts off the correct time, until it is no longer accurate enough for daily activities and must be reset. The process of drift of the clock then starts over.  For other computers, the precise time is crucial.  Computers that track the motion of satellites or missiles must be accurate to within one hundredth of a second at all times. Computers that measure the lifespan of a subatomic particle must be accurate to within a millionth of a second. Even an ordinary business server may need time accurate to within one second for the purpose of time stamping messages. 

 

Computers can be forced to keep accurate time using the Network Time Protocol (NTP).  NTP is a set of standards for time regulation services, and is incorporated into Solaris. NTP allows a host to obtain the precise time on a regular basis from a server, which, in turn, gets the time from an even more accurate and precise server. The client system can then update its system clock and prevent significant drift. Properly configured, NTP can provide nanosecond (one billionth of a second) precision.

 

Setting the time: There are two issues involved in the measurement of time:  1. the value of the "true" time, measured from some agreed upon starting point and 2. the length of a second.  These two issues are intimately connected, but are not exactly the same. There are many different definitions of a second, so even with a single, agreed-upon starting date and time, the resulting time measurement will be different depending on which definition of a second is used to accumulate time. Between the mid-1800s and 1972, the standard starting point for time was taken to be midnight at Greenwich, England on January 1, and the standard reference second was measured by subdividing the length of a solar day, which changes by several 1000ths of a second every year.  The standard thus generated is called Greenwich Mean Time or GMT.  In 1967 a new, far more accurate definition of a second was internationally agreed upon, and on January 1, 1972, time keeping internationally switched to a new time scale based on the new definition of a second: UTC, or Universal Time Coordinated (in this country, UTC is generally translated as Coordinated Universal Time, but is still written UTC). UTC is maintained by the BIPM (Bureau International des Poids et Mesures).  Like Greenwich Mean Time, UTC is the time measured in 24 hour format from midnight (0000 UTC) in Greenwich, England.  Thus, when it is 2 pm in Greenwich, the time in Huntsville, Alabama, and San Francisco, California, and Sydney, Australia is 1400 UTC. Unlike GMT,

 

UTC is counted using seconds whose length was officially defined in 1967 as being based on the natural resonance frequency of one isotope of the cesium atom, Ce-133, rather than on the length of the solar day.  The length of a second in UTC is determined by one of the characteristic resonance frequencies of the cesium atom, in the "cesium" or "atomic" clock.  If you hit an atom of finely ground or vaporized metallic Ce-133 with a pulse of energy, it will absorb the energy, then radiate that energy at a frequency of 9,192,631,770 Hz (cycles per second). The length of time that it takes to count 9,192,631,770 oscillations of this energy is therefore one second. This frequency is continuously measured in various ways to produce extremely precise, 1 second long, "ticks" of the atomic clock.

 

Atomic clocks run in national standards laboratories (in the U.S., at the National Institute of Standards and Technology, NIST), at research universities, and at some private research institutions in most countries with active scientific research programs. The seconds are then accumulated and the difference in the time thus produced is averaged between laboratories, under the direction of BIPM, to generate UTC.  The atomic clocks are extremely precise; the main U.S. clock, NIST-F1, is accurate to within 0.1 nanosecond/day, which means it would take 27.4 million years to lose one second.  In contrast, the non-volatile hardware clock on many SPARC chips is a Mostek M48T59-SRAM-Chip, manufactured by ST (SGS Thomson) Microelectronics. It uses a quartz oscillator operating at 32,768 Hz – far less accurate than the nine billion hertz cesium clock. Incidentally, the 1989 Nobel Prize in Physics was awarded to Norman F. Ramsey for the development of the atomic clock.

 

Time transmission: The laboratories which house the cesium clocks usually have more than 10 individual clocks each of whose output is averaged to produce their own atomic time, which is then averaged under the direction of BIPM to produce UTC.   They provide a signal which is sent out over phone lines (in the continental U.S. (303) 499-7111, accurate to within 30 milliseconds due to delays on long distance telephone lines), transmitted over radio waves (in the U.S. WWV at 2.5, 5, 10 and 15 Megahertz and WWVB at 60 kilohertz, accurate to within one millisecond,) and from the GOES weather satellites (468 MHz, accurate to within 100 microseconds).  It is possible to set your computer's time using a special radio receiver that picks up NIST's transmissions, or over a modem from NIST.

 

UTC is also available from the Internet Time Service. The correct time is transmitted from the laboratory's atomic clock, which is called a stratum-0 server, to computers associated with the laboratory, which are called stratum-1 servers.  In the U.S. the stratum-1 servers are run by NIST itself in Boulder, CO; by Microsoft, Abovenet and AOL, as well as by other government labs and by universities. Stratum-2 servers then use NTP applications over the Internet to obtain the time from the stratum-1 servers. Any server which, in turn, gets its time over the internet from a stratum-2 server is a stratum-3 server, and so on. The stratum-1 servers have the most accurate time after that kept by  the clock itself, while stratum-2 servers are still less accurate, and servers below stratum-3 are not considered adequate for any application requiring precise time.  Part of the reason that the stratum-1 servers are not as accurate as the stratum-0 servers is "jitter." When any signal is sent out over a wire, it gets somewhat stretched out, or otherwise varies.  Since the true time is sent as a pulse from the stratum-0 server, over a wire to the stratum-1 server, that pulse will be somewhat distorted by crosstalk, EM interference and other effects, and will thereby lose precision. 

 

The stratum-1 servers are overloaded, and unless you have a reason to need extremely accurate time, you should not attempt to use one as your time server over the Internet Some do allow general use, but most will not respond.  The stratum-2 servers get their time from the stratum-1 servers, and are good enough for all but the most precise scientific and military uses. 

 

Unless you are doing military or scientific work, you will probably want to use your ISP's server to set your clock.  This is important for security troubleshooting, where the timestamp on packets can allow you to coordinate your security efforts with those of your ISP. 

 

How NTP works: At boot time  the script /etc/rc2.d/S74xntpd starts the daemon xntpd if the file /etc/inet/ntp.conf exists. This file can be configured for either a typical client or a typical server. A client may be configured to be only a client, but servers are generally also clients of a higher stratum server. Thus client and server configuration files overlap somewhat. The daemon reads the file and configures itself accordingly. A client may operate in broadcast/multicast client or server-client mode. Typically, a client operates in server-client mode where the client is configured with the IP address or name of an NTP server(s), which it polls for the correct time. One (or more) servers responds with its correct time. The client re-polls the server(s), and gets more responses.  The client uses the requests and replies it gets to figure out how long the response was in transit. When it has enough  (3+) responses to calculate a transit time that is within its tolerance for error, it sets the time. This can take 5 or more minutes. The statement "server <IP address of server>" in the ntp.conf file configures this state. Additional servers require separate lines.

 

Solaris will not reset a time that is more than 60 seconds in error. This is a Solaris feature, and not part of the NTP standard, which allows you to determine how large an error you are willing to let NTP automatically correct. In Solaris, an error of more than 60 seconds generates a system error message, and must be manually reset with the "ntpdate" command. I know of no keyword that allows you to reset the amount of time that will be automatically reset, and that you must manually reset. The 60 second value appears to be built into Solaris.  There are two limits in the NTP standard:

 - If the error between the client system clock and its servers exceeds 3600 seconds, NTP gives up and dies.

 - If the error exceeds 128ms, the correction of the system clock is stepped; otherwise  it's slewed.

 

In broadcast /multicast client mode, the client does not poll a server, but instead listens for the server broadcasts and sets the time from those. The statement "broadcastclient " or "multicastclient <optional multicast address>" (without the quotes) in the file /etc/inet/ntp.conf configures this state. Servers must be configured to send broadcasts or multicasts. This does not happen by default. A broadcasting or multicasting  NTP server sends out the correct time every 64 seconds. The entry "broadcast 124.0.1.1" (yes, that is "broadcast" not "multicast") in the file /etc/inet/ntp.conf (without quotes) configures this multicasting to occur, while broadcast 255.255.255.255 configures broadcasting to occur. Other multicast addresses can be used as a way to select the clients receiving the time from any particular server. The clients must have the optional multicast address appended to the multicastclient keyword in /etc/inet/ntpd.conf in that case.

 

The first time a client uses the multicast or broadcast service, it must exchange a set of packets with the server to determine the latency of the network. It figures out how long the packets took from the round trip time required to exchange packets. For that exchange, the client runs in server-client mode. Multicast or broadcast mode will therefore always be somewhat less accurate than client-server mode.

 

It is also possible for hosts on a network to poll each other about the time and correct their time from those responses. This is called symmetric active mode, and it generally is used to force NTP servers to synchronize with each other.  It is set up with the keyword "peer" in place of the keyword "server," but otherwise works just like the server keyword does, except multiple systems look to each other.  If you set up a higher-level server as a peer, that server will attempt to peer with your system, unless it has "nopeer" set (which all publically available high-stratum NTP servers do!).

 

Setting up NTP: NTP is automatically started at boot time if the file /etc/inet/ntp.conf exists.  It may also be started or stopped manually using the start script: /etc/init.d/xntpd, once the file /etc/inet/ntp.conf is set up.

 

To set up an NTP server:

1)  copy the file /etc/inet/ntp.server to /etc/inet/ntp.conf.

2) In /etc inet/ntp.server , next to the keyword "server", put the address of a stratum-2 (or other) server, your ISP's time server, or whatever computer you want to use as the reference for the server you are currently configuring.  In /etc/inet/ntp.server you will usually comment out the line containing the keyword "fudge".

 

You will have  to use the server's own undisciplined internal clock (the system clock, for which there is no control) as the authoritative source of time by changing the entry after the keyword "server" in /etc/inet/ntp.conf to 127.127.1.0.  The values 127.127 are used to indicate an NTP service. The third octet of this IP address indicates the type of clock being used. For example, 1 is the local clock, which we will use. 3 is a 1010/1020 WWV/H Receiver radio transmitter. The last octet indicates the stratum of the service. If you are using your own time server in this way as the top level time server, be aware that the time on the computers in your network may not bear much resemblance to UTC. If you have more than one server listed in this file, place the word "prefer" next to the server whose time value you want given priority.

 

The "fudge" value is only used when you do not want your own NTP server to look to a higher-level server for time. It is used if you are using your local clock, or if you get time from a modem or radio receiver. By default, your own server will treat its local clock as a stratum 4 server. That will prevent any other host on your network that is also a stratum 5 or higher server from looking to your server as a higher stratum server (assuming it is broadcasting). Your server may look to other servers that broadcast, however, if they believe they are higher than stratum 4. To prevent that, you must make your server believe that it is a stratum-0 server by putting "127.127.1.0 stratum-0" next to the keyword "fudge." For radio receivers and modems, the value "time1" and a time in seconds is appended to the word fudge. That indicates the amount of time to add to the supplied value, because of the delay over the phone lines or radio waves.

 

3) Create the file /var/ntp/ntp.drift. The "drift" file records changes in the internal clock of the computer by comparing it to the correct time values sent by the NTP server.  Over a period of time, the drift file acquires enough measurements of this difference for NTP to calculate an algorithm describing this drift. The algorithm is then used to correct the time on a regular basis for drift, thus improving the accuracy of the time.

 

4. Start the daemon xntpd by rebooting or running its start script. It may take as much as ten minutes to start.  Use ps –ef  to see it starting. 

 

To set up an NTP client, the file /etc/inet/ntp.client must be copied to /etc/inet/ntp.conf.  The file contains the following statements:

server <IP or name of server>

server <IP or name of second server>

etc.

 

The time provided by all servers is used equally unless the word "prefer" is appended to one of the server lines. IN that case, that server's time will be used unless it is very different from that of the other servers. To set up a client of a broadcasting or multicasting server, the line

 

broadcastclient 255.255.255.255

OR

multicastclient <multicast address>   is added.

 

The multicast line is already in the file by default. It must be commented out if you set up a specific server.

 

The file is then saved, and the daemon started with /etc/init.d/xntpd start

 

 The daemon can then be started either directly or by rebooting. No NTP server need be specified.  The multicast request for the correct time will be picked up by all NTP servers on the network.    

 

NTP management:  NTP is managed by a group of logging and viewing tools.  First, NTP sends messages out via the syslog utility at the level daemon.notice.  They can be viewed at wherever such messages are logged (usually /var/adm/messages).  Changes of the local system clock are logged by NTP to this utility.  The daemon xntpd can be queried directly usuing the xntpdc utility.  When invoked via the command

"xntpdc," an interactive session starts.  The menu of available commands can be displayed with ? at the xntpdc prompt.  ? <command> gives more detail on the use of that command.   xntpdc is available only in Solaris 8. For Solaris 7, use ntpq, which works approximately the same as does xntpdc.

 

Acronyms:

BIPM -Bureau International des Poids et Mesures – the international oversight body for UTC.

NIST – National Institute of Standards and Technology – the main U.S. government laboratory which measures UTC.

NTP – Network Time Protocol – a protocol which allows computers to synchronize their time to that of time servers, which in turn get their time from hundreds of cesium (Ce) time clocks in national standards laboratories.

PPS – Pulse Per Second 0 keeps computer's internal clock in line between 64 second time stamps.

UTC – Universal Time Coordinated. The time based on the Cesium clock. It differs from Greenwich Mean Time in that it is based on the Cesium timer and not an astronomical timer.

Definitions:

strata – levels of accuracy for time servers – stratum 1 is most accurate.

stratum 0 server – the actual reference clock. These are in universities, national laboratories and some corporations with research institutes.

stratum 1 server – a server associated with a laboratory having a reference clock.

jitter – the variation in a pulse that occurs as it travels across the wire from the sender to the destination.  The pulse is generated to set the time, so these slight changes affect the quality of the time.

accuracy – the difference between the time set on a system and the time set on a stratum-1 time server.

reliability – how long a system clock is accurate to within some specified range.

wander – the variation in the time on an internal clock from the average.  Wander is a back and forth variation around the average.

drift file - /etc/inet/ntp.drift – the file that holds the frequency offset of the local system clock.

drift – the average rate of variation in an internal clock from the actual time. Drift is a one way variation from the true time.

xntpd – ntp daemon – works on port 123/UDP

fudge – a keyword on the server that adjusts the driver for the type of clock used.

oscillator – an object which oscillates at a known frequency. The basis of all clocks.

discipline – the process of keeping the computer's internal clock in line with the reference clock.

undisciplined local clock – the internal clock on a computer – 127.127.1.0

counter chip – the chip which counts ticks sent from the kernel to keep time.

reference clocks – stratum 0 servers.

resolution – smallest time increments for which a host can provide accurate time.

precision – smallest increment of time that is usable by the computer.

Commands:

xntpdc – ntp query program (Solaris 8 and 9  only)

ntptrace – traces ntp host chain

ntpq – ntp query program (Solaris 7 to 9)

ntpdate <ntpserver1> <ntpserver2> … – set date and time via ntp based on servers listed.  This command must be used if the offset from the timeserver is greater than 30 seconds.

Files:

/var/ntp/ntp.drift – records drift and adjusts frequency based on drift measurements.  Helps to keep the computer's clock accurate between time settings.

/var/adm/messages - where error messages from NTP are sent

/etc/rc2.d/S74xntpd – start script for NTP if /etc/ntp.conf exists.

/etc/inet/ntp.server -  ntp server template to copy to /etc/inet/ntp.conf.

/etc/inet/ntp.conf – ntp configuration file for server and client.

/etc/inet/ntp.client – ntp client template.

 

Misc:

Starting NTP: server:

1. Copy ntp.server to ntp.conf

2. Change server line to 127.127.1.0 and comment out fudge

3. Touch /etc/inet/ntp.drift or /var/ntp/ntp/drift.

4. Start NTP: /etc/init.d/xntpd start

 

Starting NTP: client:

1. Copy ntp.client to ntp.conf 

2. Change server line to name of server

2. Start the daemon: /etc/init.d/xntpd start