| SUSE LINUX – Administration Guide Chapter 14. Linux in the Network / 14.11. Time Synchronization with xntp | ||||
|---|---|---|---|---|
 | 14.10. DHCP | Chapter 15. The Apache Web Server |  | |
| SUSE LINUX – Administration Guide Chapter 14. Linux in the Network / 14.11. Time Synchronization with xntp | ||||
|---|---|---|---|---|
| 14.10. DHCP | Chapter 15. The Apache Web Server | | |
Keeping track of the exact current time is an important aspect in many processes in a computer system. Computers have a built-in clock for this. Unfortunately, this clock often does not meet the requirements of some applications, like databases. This problem is usually solved by repeatedly correcting the time of the local computer by hand or over a network. A computer clock should, at best, never be set back and the amount it gets set forward should not exceed a certain time interval. It is relatively simple to occasionally correct the time kept by the computer clock with ntpdate. This, however, results in a sudden jump in time that may not be tolerated by all applications.
An interesting approach to solving this problem is offered by xntp. xntp continuously corrects the local computer clock by following statistically gathered correction data. It also constantly corrects the local time by querying time servers in the network. The third correction method offers accessing local time normals, like radio-controlled clocks.
The default setting of xntp in SUSE LINUX is that of only respecting the local computer clock as a time reference. The most simple possibility to access a time server in the network is the declaration of server parameters. For example, if a time server is available with the name ntp.example.com, add this server to the file /etc/ntp.conf in the format server ntp.example.com.
Enter additional time servers by inserting additional lines with the keyword server. After xntpd has been started with the command rcxntpd start, the application waits for one hour until the time has stabilized before creating the drift file for the correction of the local computer clock. The drift file offers the long-term advantage of predicting, right after booting the computer, by how much the hardware clock will be off over time. The correction becomes immediately effective, which ensures a high stability of the computer time.
The name of the time server in your network does not need to be known if it is also available by broadcast. This can be reflected in the configuration file /etc/ntp.conf with the parameter broadcastclient. However, some authentication mechanisms should be activated in this case to prevent a faulty time server in the network from changing the time on your computer.
Any xntpd in the network can also commonly be accessed as a time server. To run xntpd with broadcasts, activate the broadcast option:
broadcast 192.168.0.255
Adjust the broadcast address to your specific case. It should, however, be ensured that the time server really serves the correct time. Time normals are well-suited for this.
The program package xntp also contains drivers that allow connection to local time normals. A list of supported clocks is provided in the package xntp-doc in the file /usr/share/doc/packages/xntp-doc/html/refclock.htm. Each driver has been assigned a number. The actual configuration in xntp is done over pseudo-IPs. The clocks are registered in the file /etc/ntp.conf as if they were time servers available over the network.
These clocks are assigned special IP addresses that follow the pattern 127.127.t.u. The value t is assigned from the previously mentioned file with the reference clocks. The value u is the device number that only then deviates from 0 if more than one clock of the same type is connected to the computer. For example, a “Type 8 Generic Reference Driver (PARSE)” clock has the pseudo-IP address 127.127.8.0.
The various drivers usually have special parameters that describe the configuration in more detail. The file /usr/share/doc/packages/xntp-doc/html/refclock.htm provides links to the corresponding driver page describing these parameters. It is, for instance, necessary to provide an additional mode that specifies the clock more accurately. The module “Conrad DCF77 receiver module”, for example, has mode 5. The keyword prefer must be specified to make xntp accept this clock as a reference. The complete server entry for a Conrad DCF77 receiver module therefore is:
server 127.127.8.0 mode 5 prefer
Other clocks follow the same pattern. Find xntp documentation in the directory /usr/share/doc/packages/xntp-doc/html after the installation of the package xntp-doc.
