Date, Time & NTP

Showing and setting time

In Linux, the system time zone is determined by the symbolic link /etc/localtime”. This link points to a time zone data file that describes the local time zone. The time zone data files are located at either /usr/lib/zone” info or /usr/share/zoneinfo depending on what distribution of Linux you use.

For example, on a SuSE system located in New Jersey the ”/etc/localtime” link would point to ”usr/share/zoneinfo/US/Eastern”. On a Debian system the /etc/localtime” link would point to ”/usr/lib/zoneinfo/US/Eastern”.

If you fail to find the zoneinfo directory in either the /usr/lib or /usr/share directories, either do a find /usr -print | grep zoneinfo or consult your distribution's documentation.

The date command shows the current date and time. For example:
[root@server1~]# date
Sun Jul 14 21:53:41 EET DST 1996

That time is Sunday, 14th of July, 1996, at about ten before ten at the evening, in the time zone called ``EET DST'' (which might be East European Daylight Savings Time). date can also show the universal time:
[root@server1~]# date -u
Sun Jul 14 18:53:42 UTC 1996

date is also used to set the kernel's software clock:
[root@server1~]# date 07142157
Sun Jul 14 21:57:00 EET DST 1996
[root@server1~]# date
Sun Jul 14 21:57:02 EET DST 1996

See the date manual page for more details; the syntax is a bit arcane. Only root can set the time. While each user can have his own time zone, the clock is the same for everyone.

Beware of the time command. This is not used to get the system time. Instead it's used to time how long something takes. Refer the time man page.

date only shows or sets the software clock. The clock command synchronizes the hardware and software clocks. It is used when the system boots, to read the hardware clock and set the software clock. If you need to set both clocks, you first set the software clock with date, and then the hardware clock with clock -w.
The -u option to clock tells it that the hardware clock is in universal time. You must use the -u option correctly. If you don't, your computer will be quite confused about what the time is.

The clocks should be changed with care. Many parts of a UNIX system require the clocks to work correctly. For example, the cron daemon runs commands periodically. If you change the clock, it can be confused of whether it needs to run the commands or not. On one early UNIX system, someone set the clock twenty years into the future, and cron wanted to run all the periodic commands for twenty years all at once. Current versions of cron can handle this correctly, but you should still be careful. Big jumps or backward jumps are more dangerous than smaller or forward ones.

When the clock is wrong

The Linux software clock is not always accurate. It is kept running by a periodic timer interrupt generated by PC hardware. If the system has too many processes running, it may take too long to service the timer interrupt, and the software clock starts slipping behind. The hardware clock runs independently and is usually more accurate. If you boot your computer often (as is the case for most systems that aren't servers), it will usually keep fairly accurate time.
If you need to adjust the hardware clock, it is usually simplest to reboot, go into the BIOS setup screen, and do it from there. This avoids all trouble that changing system time might cause. If doing it via BIOS is not an option, set the new time with date and clock (in that order), but be prepared to reboot, if some part of the system starts acting funny.
Another method would be to use either ”hwclock –w” or “hwclock –systohc” to sync the hardware clock to the software clock. If you want to sync your software clock to your hardware clock then you would use ”hwclock –s” or ”hwclock –hwtosys”. For more information on this command read ”man hwclock”.

NTP – Network Time Protocol

Much of the terminology associated with computer time synchronization and NTP servers can be quite obscure. This section attempts to explain in simple language some of the terminology used in computer timing applications.

NTP: NTP is the short hand name given to the Network Time Protocol; it is a standard protocol for distributing time around the internet and computer networks. Precise time is passed from accurate time references to network time clients for the purpose of synchronizations.

NTP Server: A NTP Server is a device that obtains precise time from an external timing reference such as GPS and provides a precise timing resource to computer networks.

When it comes to time synchronization and using Network Time Protocol (NTP) to ensure accuracy on a computer network, it is important to understand the hierarchy of NTP and how it affects distance and accuracy.

NTP time servers work by receiving a single time source and using this as a basis for all time on the network, however, a synchronized network will be only as accurate as the original time source and this is where stratum levels come in.

Stratum: The Stratum or level of a NTP time server denotes its position in the network timing hierarchy. A stratum 1 NTP server obtains time from an external timing reference. Stratum 2 devices obtain time from stratum 1 devices and pass timing information to the next level and so on.

And atomic clock, either one sat in a large scale physics laboratory, or those aboard GPS satellites, are stratum 0 devices. In other words these are the devices that actually generate the time.

Stratum 1 devices are NTP time servers that get their source of time directly from these stratum 0 atomic clocks. Either by using a GPS receiver or a radio referenced NTP server, a stratum 1 device is as accurate as you can get without having your own multi-million dollar atomic clock in the server room. A stratum 1 NTP time server will typically be accurate to within a millisecond of the atomic clock time.

Stratum 2 devices are the next step down on stratum level chain. These are time servers that receive their time from a stratum 1 device. Most online time servers, for instance, are stratum 2 devices, getting their time from another NTP time server. Stratum 2 devices are obviously further away from the original time source and therefore are not quite as accurate.

The stratum levels on an NTP network continue on, with devices connecting to devices going all the way down to stratum 10, 11, 12 and so on - obviously the more links in the chain the less accurate the device will be.
Dedicated stratum 1 NTP time servers are by far the most accurate, reliable and secure method of synchronizing a computer network and no business network should really be without one

Jitter: The jitter associated with a timing reference indicates the magnitude of variance, or dispersion, of the signal. Different timing references have different amounts of jitter. The more accurate a timing reference, the lower the jitter value. Jitter is usually measure in milliseconds.

Offset: Offset generally refers to the difference in time between an external timing reference and time on a local machine. The greater the offset, the more inaccurate the timing source is. Synchronized NTP servers will generally have a low offset. Offset is generally measured in milliseconds.

Delay: Delay in a NTP server describes the round-trip delay or latency of a timing message passed from client to server and back again. The time delay is generally measured in milliseconds and is used to calculate adjustments required to account for network delays.

Reference Clock: A NTP reference clock is an external hardware clock that a NTP server utilizes for accurate time synchronization. GPS and radio time and frequency broadcasts are commonly used as NTP reference clocks. The NTP distribution, which is available for LINUX, provides source code to operate a large number of external reference clocks.

MSF: MSF is the call sign of a UK time and frequency radio broadcast, which is available throughout Britain. The MSF signal is broadcast at 60 kHz from Anthorn, Cumbria. Many NTP servers utilize the MSF time broadcast as a precision timing reference. The term MSF is the call sign of the radio broadcast.

DCF-77: The DCF-77 radio time signal is broadcast from Frankfurt, Germany at 77.5 KHz. The signal is a time and frequency broadcast that can be received throughout Germany and much of Western Europe. The broadcast is used by many stratum 1 NTP server systems as a precision timing reference.

GPS: The Global Positioning System (GPS) is primarily intended as a global navigation system. However, GPS also provides a highly accurate precision timing reference that can operate worldwide. The GPS system is widely used as a timing reference for GPS NTP time server equipment.

To conclude, most of the terminology used in computer timing can be confusing and vague. However, most of these phrases are used to describe a relatively simple concept.

Basic NTP Configuration

The NTP program is configured using either the /etc/ntp.conf” or ”/etc/xntp.conf” file depending on what distribution of Linux you have. I won't go into too much detail on how to configure NTP. Instead I'll just cover the basics.

An example of a basic ntp.conf file would look like:

fudge stratum 10

# Drift file.
driftfile /etc/ntp/drift

The most basic ntp.conf file will simply list 2 servers, one that it wishes to synchronize with, and a pseudo IP address for itself (in this case The pseudo IP is used in case of network problems or if the remote NTP server goes down. NTP will synchronize against itself until the it can start synchronizing with the remote server again. It is recommended that you list at least 2 remote servers that you can synchronize against. One will act as a primary server and the other as a backup.
You should also list a location for a drift file. Over time NTP will "learn" the system clock's error rate and automatically adjust for it.
The restrict option can be used to provide better control and security over what NTP can do, and who can effect it.

For example:
# Prohibit general access to this service.
restrict default ignore

# Permit systems on this network to synchronize with this
# time service. But not modify our time.
restrict mask nomodify

# Allow the following unrestricted access to ntpd

It is advised that you wait until you have NTP working properly before adding the restrict option. You can accidental restrict yourself from synchronizing and waste time debugging why.

NTP slowly corrects your systems time. Be patient! A simple test is to change your system clock by 10 minutes before you go to bed and then check it when you get up. The time should be correct.

Many people get the idea that instead of running the NTP daemon, they should just setup a cron job to periodically run the ntpdate command. There are 2 main disadvantages of using this method.

The first is that ntpdate does a "brute force" method of changing the time. So if your computer's time is off my 5 minutes, it immediately corrects it. In some environments, this can cause problems if time drastically changes. For example, if you are using time sensitive security software, you can inadvertently kill someone’s access. The NTP daemon slowly changes the time to avoid causing this kind of disruption.

The other reason is that the NTP daemon can be configured to try to learn your systems time drift and then automatically adjust for it.

NTP tool kit

There are a number of utilities available to check if NTP is doing its job. The ntpq -p command will print out your system's current time status.

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
*cudns.cit.corne  2 u  832 1024  377   43.208    0.361   2.646
 LOCAL(0)        LOCAL(0)        10 l   13   64  377    0.000    0.000   0.008

The ntpdc -c loopinfo will display how far off the system time is in seconds, based upon the last time the remote server was contacted.

# ntpdc -c loopinfo
offset:               -0.004479 s
frequency:            133.625 ppm
poll adjust:          30
watchdog timer:       404 s

ntpdc -c kerninfo will display the current remaining correction.

# ntpdc -c kerninfo
pll offset:           -0.003917 s
pll frequency:        133.625 ppm
maximum error:        0.391414 s
estimated error:      0.003676 s
status:               0001  pll
pll time constant:    6
precision:            1e-06 s
frequency tolerance:  512 ppm
pps frequency:        0.000 ppm
pps stability:        512.000 ppm
pps jitter:           0.0002 s
calibration interval: 4 s
calibration cycles:   0
jitter exceeded:      0
stability exceeded:   0
calibration errors:   0

A slightly more different version of ntpdc -c kerninfo is ntptime

# ntptime
ntp_gettime() returns code 0 (OK)
  time c35e2cc7.879ba000  Thu, Nov 13 2003 11:16:07.529, (.529718),
  maximum error 425206 us, estimated error 3676 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -3854.000 us, frequency 133.625 ppm, interval 4 s,
  maximum error 425206 us, estimated error 3676 us,
  status 0x1 (PLL),
  time constant 6, precision 1.000 us, tolerance 512 ppm,
  pps frequency 0.000 ppm, stability 512.000 ppm, jitter 200.000 us,
  intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.

Yet another way to see how well NTP is working is with the ntpdate -d command. This will contact an NTP server and determine the time difference but not change your system's time.

# ntpdate -d
13 Nov 14:43:17 ntpdate[29631]: ntpdate 4.1.1c-rc1@1.836 Thu Feb 13 12:17:20 EST 2003 (1)
server, port 123
stratum 2, precision -17, leap 00, trust 000
refid [], delay 0.06372, dispersion 0.00044
transmitted 4, in filter 4
reference time:    c35e5998.4a46cfc8  Thu, Nov 13 2003 14:27:20.290
originate timestamp: c35e5d55.d69a6f82  Thu, Nov 13 2003 14:43:17.838
transmit timestamp:  c35e5d55.d16fc9bc  Thu, Nov 13 2003 14:43:17.818
filter delay:  0.06522  0.06372  0.06442  0.06442
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000036 0.001020 0.000527 0.000684
         0.000000 0.000000 0.000000 0.000000
delay 0.06372, dispersion 0.00044
offset 0.001020

13 Nov 14:43:17 ntpdate[29631]: adjust time server offset 0.001020 sec

If you want actually watch the system synchronize you can use ntptrace.

# ntptrace stratum 2, offset -0.003278, synch distance 0.02779 stratum 1, offset -0.014363, synch distance 0.00000, refid 'ACTS'

If you need your system time synchronized immediately you can use the ntpdate remote-servername to force synchronization. No waiting!

# ntpdate
13 Nov 14:56:28 ntpdate[29676]: adjust time server offset -0.003151 sec

To know about the courses CLICK HERE..!!

Contact US CLICK HERE..!!

1 comment:

  1. "Nice post. You just post the right content i was searcing for. Good Job. Linux Courses in India | Linux Server Training Institute in India training company SSDN Technologies, and become a well versed software professional.