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
[root@server1~]#
|
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
[root@server1~]#
|
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
[root@server1~]#
|
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:
# --- GENERAL CONFIGURATION ---
server 127.127.29.0
server 127.127.1.0
fudge 127.127.1.0
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 127.127.1.0). 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 172.24.0.0 mask 255.255.0.0 nomodify
# Allow the following unrestricted access to ntpd
restrict 172.24.0.254
restrict 127.0.0.1
|
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 ntp0.usno.navy.
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 132.236.56.250
13 Nov 14:43:17 ntpdate[29631]: ntpdate 4.1.1c-rc1@1.836 Thu Feb
13 12:17:20 EST 2003 (1)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
receive(132.236.56.250)
transmit(132.236.56.250)
server 132.236.56.250, port 123
stratum 2, precision -17, leap 00, trust 000
refid [192.5.41.209], 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 132.236.56.250 offset 0.001020 sec
|
If you want
actually watch the system synchronize you can use ntptrace.
# ntptrace 132.236.56.250
cudns.cit.cornell.edu: stratum 2, offset -0.003278, synch
distance 0.02779
truetime.ntp.com:
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 132.236.56.250
13 Nov 14:56:28
ntpdate[29676]: adjust time server 132.236.56.250 offset -0.003151 sec
|
"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.
ReplyDelete"
Linux Training Institute in India | Linux Training in India a
ReplyDelete