| Let's assume that there was only one clock in the world that gave the correct time, and that this clock is 100 percent accurate, 100 percent of the time. We'll call this our "reference clock." Obviously, if we only had the one reference clock it would soon become overloaded as everyone tries to determine the correct time from it. We would need some way of balancing this load across more clocks. Now let's say that we only allow 10 clocks to query our reference clock, and that everyone else has to get the correct time from one of these. The overloading would be vastly reduced because we have increased the number of clocks that can be queried. These new clocks would probably not be quite as accurate, but would be good enough for most purposes. If these 10 clocks also get overloaded, we can apply the same rule again: 10 new clocks per existing one, which would provide us with 100 "time access points." We can see that we have created a hierarchy of clocks here, each level providing more access points, although this is at the cost of some accuracythe further we move away from the main "reference" source, the less accurate the new clock becomes. This example is the basis of NTP (although the numbers involved are very different). The levels that we've described are known within NTP as "stratum levels." It uses stratums to assign a value to a clock that represents its distance away from the top-level sourcein other words, its accuracy. Stratum Levels The available stratums are 0 for the best available source (such as a radio clock), followed by 1 through to 15, with 16 being used as an unknown source (this is often seen for a server that has been set up on a broadcast network, or one that has not yet synchronized). Stratums are assigned to a server automatically by the NTP software (although this can be altered, as we'll see later). Stratum-0 servers are the NTP equivalent of the 100 percent accurate clock we described above. They must be connected to a machine, since they cannot be interrogated directly by the NTP software. A machine will always be one level lower than its server. The reason for this is that it is "further" away from the server it is getting its time from. In other words, a stratum-0 hardware device feeds a machine that becomes a stratum-1 server, which feeds another machine that becomes a stratum-2 server, and so on. The outcome of this is that, as far as NTP is concerned, the best available source is a stratum-1 serverthat is, the machine running NTP that is connected to a stratum-0 hardware device. The idea is that there are a few level-1 servers, feeding more level-2 servers, feeding lots of level-3 servers, and so forth. Most systems should try to connect to stratum-2 servers; this leaves the stratum-1 servers free to feed the stratum-2s. The difference in accuracy between the two will be negligible for most users, especially after any network delays have been taken into account. One thing we need to be aware of when dealing with stratum levels is that it's possible to assign a different stratum level to a particular server by using the "fudge" keyword in the NTP configuration file. This is useful in certain situationsin fact, we use it in our internal system described later. The downside of this is that it's possible to connect to something advertising itself as a stratum-1 server, when in fact it has a highly inaccurate clock and its stratum has been altered manually. Delays, Offsets, and Dispersion So now that we have a highly accurate server that we can connect to, the next thing we need to be concerned about are network issues. For example, let's assume it takes 10 seconds for the server to respond to our queryby the time we've received the reply, it will be incorrect. However, if we take this a step further and calculate that the network delay to this server is always 10 seconds, we can work out what the correct time will be when we receive the server responsethis should be 5 seconds out (half the roundtrip across the network). Adding this calculated delay to the returned time will give us the correct value. Let's look at an example of this. Figure 19.1 shows an example of an NTP data packet being sent by a client to a server. Figure 19.1. Client-server network delays. 
We can see here that it takes 7 seconds from sending the client request to receiving a response back from the server (this is grossly exaggerated, but makes things easier to see!). We can also see the times at which the packet was either sent or received by both machines. NTP places time stamps into the NTP packets at these points, which are as follows: When the client sends the request When the server receives the request When the server sends the response When the client receives the response
Once we have the time stamps, we can make a few calculations; two of the important ones are known as "delay" and "offset." "Delay" refers to the time taken to send the packet to the server and get a response, ignoring any machine processing times (in other words, the network portion only). We can calculate this as follows: (T4 T1) (T3 T2) "Offset" is the estimated time difference between this system and the server, and is calculated as follows: 0.5 [(T2 T1) + (T3 T4)] Calculating these values for the times shown in Figure 19.1 gives us the following: delay = (10:27 10:20) (10:24 10:22) = 5 secs offset = 0.5 [(10:22 10:20) + (10:24 10:27)] = 2.5 secs Now when the NTP client receives the time back from the server, it knows the offset that it needs to add to determine the "correct" time. However, if the local clock is wildly inaccurate, it could produce a highly incorrect value. The problem we may see here is that after adding the offset to it, it is even further out. To overcome this, we use a value known as "dispersion." This is an estimate of the maximum error seen between the local clock and the server. By adding the dispersion value to the local time we can place limits around its inaccuracy. Servers The earlier example assumes that one server has been used, whereas in reality NTP prefers to work with a number of serversat least three are recommended. The reason for this is that the software will compare each of the servers against the others to see which is providing the best results. This method of calculation gives preference to lower stratum clocks that have the smallest roundtrip time. We've referred to servers as "hardware devices" in earlier examples and explanations. In reality there are various types of servers available; let's look at them in more depth now. An NTP server is something that responds to requests from a client, and can be either a system or a hardware reference device. If it is another system, its IP address will be used, while a reference device would be allocated a loopback address. This is described in more detail below. Reference Devices Table 19.1 is generated from the sample NTP configuration file supplied with Solaris, /etc/inet/ntp.server. It shows the device numbers that have been allocated to some standard reference devices by the NTP software. Each device is allocated an address and treated as if it was simply another machine. The address is generated by combining the loopback network with the Xtype reference number from Table 19.1 and the instance number of the device, to give an address of 127.127.<Xtype device number>.<instance number>. For example, if you wanted to use the IRIG Audio Decoder device (Type 6 in the table below), and it was the first instance of the device connected to this system, it would be allocated an IP address of 127.127.6.0. Using this method of treating hardware devices as IP addresses makes it very simple to alter a device for a higher-level server at a later date. Table 19.1. NTP Reference DevicesXType | Device | Name | Description |
|---|
1 | (none) | LOCAL | Undisciplined Local Clock | 2 | trak | GPS_TRAK | TRAK 8820 GPS Receiver | 3 | pst | WWV_PST | PSTI/Traconex WWV/WWVH Receiver | 4 | wwvb | WWVB_SPEC | Spectracom WWVB Receiver | 5 | goes | GPS_GOES_TRUE | TrueTime GPS/GOES Receivers | 6 | irig | IRIG_AUDIO | IRIG Audio Decoder | 7 | chu | CHU | Scratchbuilt CHU Receiver | 8 | refclock- | GENERIC | Generic Reference Clock Driver | 9 | gps | GPS_MX4200 | Magnavox MX4200 GPS Receiver | 10 | gps | GPS_AS2201 | Austron 2201A GPS Receiver | 11 | omega | OMEGA_TRUE | TrueTime OM-DC OMEGA Receiver | 12 | tpro | IRIG_TPRO | KSI/Odetics TPRO/S IRIG Interface | 13 | leitch | ATOM_LEITCH | Leitch CSD 5300 Master Clock Controller | 14 | ees | MSF_EES | EES M201 MSF Receiver | 15 | gpstm | GPS_TRUE | TrueTime GPS/TM-TMD Receiver | 17 | datum | GPS_DATUM | Datum Precision Time System | 18 | acts | NIST_ACTS | NIST Automated Computer Time Service | 19 | heath | WWV_HEATH | Heath WWV/WWVH Receiver | 20 | nmea | GPS_NMEA | Generic NMEA GPS Receiver | 22 | pps | ATOM_PPS | PPS Clock Discipline | 23 | ptbacts | PTB_ACTS | PTB Automated Computer Time Service |
Public Time Servers These are servers that provide an accurate time signal for general use. A number of these are available and their details can be found by searching for "public time servers" on most search engines. Anyone who advertises a time server will normally provide information similar to the following: ntp2a.mcc.ac.uk (130.88.202.49) Location: University of Manchester, Manchester, England Synchronization: NTP secondary (S2), Sun/SunOS Service Area: UK Access Policy: Open Access Contact(s): timelords@mcc.ac.uk Note: Please use DNS for address, subject to change We can see that this particular system advertises itself as a stratum-2 server and has an open access policy, meaning we can simply connect to it as required. Other systems may ask you to mail them your contact details so they are aware of who is using their service. Bear in mind that we don't really know how accurate any public time server is because it may have been assigned a higher value than it should have by using the "fudge" keyword we mentioned earlier. This means that if you are going to use a public time server, it is always worth checking the accuracy of its clock beforehand. And, if you are setting one up, always make sure you are advertising the correct stratum level. | 
