[SOLVED] Weird time changes, correct time and date but wrong hour

metaschima · 08-02-2014, 03:16 PM

That's a lot of info. I set it to UTC now and will continue to do so.

Why is it recommended to have only 3 NTP servers ?

I use 'ntpdate' to set the time if it is way off, because ntpd refuses to if it is way off, in fact it errors and quits. I have ntpd setup properly and it runs every boot.

GazL · 08-02-2014, 03:33 PM

If you have 2 servers and they disagree about the time, then how do you know which one is correct? By having 3, hopefully 2 of them will be in agreement and you've got a good indication of which one is wrong. Its just a reliability measure. You can get away with just using one if you really want, but you'll be vulnerable to an incorrectly timed server.

If you specify more than 3, then you're wasting bandwidth, and creating unnecessary load on the ntp servers.

BTW, I know troy' disagrees with me on this, but I prefer to remove the 127.127.1.0 server and fudge lines from the config file: I've found that they prevent ntpd from making its initial time step, which can be an issue if your time is a long way out of step when ntpd starts.

metaschima · 08-02-2014, 03:52 PM

Well, on ntp.org they always seem to list 4 servers whenever they list them. I mean every single page and part of the world has 4 servers listed. I think I'll leave it at 4 for now. If it would cause unnecessary load, then why wouldn't they list 3 on the site instead of 4 ? It clearly says ' To use this pool zone, add the following to your ntp.conf file:' and always lists 4 servers.

tronayne · 08-02-2014, 04:03 PM

It's pretty common to have three servers listed in /etc/ntp.conf (more that three is kind of overkill). NTP evaluates the servers and selects the best one for you. If one of them goes off line, it will throw that out and select another from the pool of servers (and it evaluates available pool servers for the "best" ones to use to begin with and as time goes on -- best here means electrically close to you as well as stability and other factors).

Having the

Quote:

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
#
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10

is precisely what it says it's for: when you Internet or other time source connection goes away, NTP will synchronize with itself until the connection comes back. Then it will evaluate the existing list of servers, perhaps throw out one or all three and select new servers from the pool.

That local server is never used for synchronization otherwise (that's why it's a stratum 10).

As mentioned, ntpdate is going to go away (nobody knows when exactly, but it will eventually). The replacement is ntpd which can be used for a one-time set-the-clock before NTPD is started.

Hope this helps clean up any confusion.

metaschima · 08-02-2014, 05:09 PM

So I can use 'ntpd -q' instead of 'ntpdate' and it will work the same ?

GazL · 08-02-2014, 05:29 PM

My experience is that "ntpd -q" doesn't work if you include the 127.* server/fudge lines in the config file. It's the same issue I see with the initial step problem that I described above (regardless of the comments in the config file). But don't take my word for it, try it for yourself by setting the time a couple of hours out and then trying "ntpd -q" first with 127.* server/fudge lines, and then without (You'll probably want to use '-g' too, to enable a large jump).

Personally, I'd use "sntp" rather than either "ntpd -q" or "ntpdate", for a one-off time adjustment. But each to their own.

Xsane · 08-02-2014, 07:57 PM

True, except it's not little.

Quote:

Originally Posted by tronayne

Here's a nice, confusing little treatise

False

Quote:

Originally Posted by tronayne

The system clock is software managed by the kernel with interrupts (pretty much).

False

Quote:

Originally Posted by tronayne

Now, NTP, when synchronized, keeps your system clock on time (it doesn't mess with the hardware clock).

False

Quote:

Originally Posted by tronayne

there's some movement afoot in kernel development to default all hardware clocks to UTC...

False

Quote:

Originally Posted by tronayne

NTP will keep your system clock on time(they're notorious for drifting all over the place).

If all unnecessary things were deleted the World would be a sad place.

Quote:

Originally Posted by tronayne

delete the iburst from them (they're not really necessary).

False

Quote:

Originally Posted by tronayne

If that time drifts, you most likely have a bad battery

1k seconds is not drift, it's something broken.

Quote:

Originally Posted by tronayne

it should not have drifted more than 1,000 seconds

Quote:

Originally Posted by tronayne

Having the

Code:

Undisciplined Local Clock ...

is precisely what it says it's for:

Quote:

Originally Posted by Undisciplined Local Clock man page

Synopsis

Address: 127.127.1.u
Reference ID: LOCL
Driver ID: LOCAL
Description

Note: We recommend against using this driver.

tronayne · 08-03-2014, 12:17 PM

From the NOTES section of man clocks:

Quote:

Clocks in a Linux System
There are two main clocks in a Linux system:

The Hardware Clock: This is a clock that runs independently of any control program
running in the CPU and even when the machine is powered off.

On an ISA system, this clock is specified as part of the ISA standard. The control
program can read or set this clock to a whole second, but the control program can
also detect the edges of the 1 second clock ticks, so the clock actually has virtu‐
ally infinite precision.

This clock is commonly called the hardware clock, the real time clock, the RTC, the
BIOS clock, and the CMOS clock. Hardware Clock, in its capitalized form, was
coined for use by hwclock because all of the other names are inappropriate to the
point of being misleading.

So for example, some non-ISA systems have a few real time clocks with only one of
them having its own power domain. A very low power external I2C or SPI clock chip
might be used with a backup battery as the hardware clock to initialize a more
functional integrated real-time clock which is used for most other purposes.

The System Time: This is the time kept by a clock inside the Linux kernel and
driven by a timer interrupt. (On an ISA machine, the timer interrupt is part of
the ISA standard). It has meaning only while Linux is running on the machine. The
System Time is the number of seconds since 00:00:00 January 1, 1970 UTC (or more
succinctly, the number of seconds since 1969). The System Time is not an integer,
though. It has virtually infinite precision.

The System Time is the time that matters. The Hardware Clock's basic purpose in a
Linux system is to keep time when Linux is not running. You initialize the System
Time to the time from the Hardware Clock when Linux starts up, and then never use
the Hardware Clock again. Note that in DOS, for which ISA was designed, the Hard‐
ware Clock is the only real time clock.

It is important that the System Time not have any discontinuities such as would
happen if you used the date(1L) program to set it while the system is running. You
can, however, do whatever you want to the Hardware Clock while the system is run‐
ning, and the next time Linux starts up, it will do so with the adjusted time from
the Hardware Clock. You can also use the program adjtimex(8) to smoothly adjust
the System Time while the system runs.

A Linux kernel maintains a concept of a local timezone for the system. But don't
be misled -- almost nobody cares what timezone the kernel thinks it is in.
Instead, programs that care about the timezone (perhaps because they want to dis‐
play a local time for you) almost always use a more traditional method of determin‐
ing the timezone: They use the TZ environment variable and/or the /usr/share/zone‐
info directory, as explained in the man page for tzset(3). However, some programs
and fringe parts of the Linux kernel such as filesystems use the kernel timezone
value. An example is the vfat filesystem. If the kernel timezone value is wrong,
the vfat filesystem will report and set the wrong timestamps on files.

hwclock sets the kernel timezone to the value indicated by TZ and/or
/usr/share/zoneinfo when you set the System Time using the --hctosys option.

The timezone value actually consists of two parts: 1) a field tz_minuteswest indi‐
cating how many minutes local time (not adjusted for DST) lags behind UTC, and 2) a
field tz_dsttime indicating the type of Daylight Savings Time (DST) convention that
is in effect in the locality at the present time. This second field is not used
under Linux and is always zero. (See also settimeofday(2).)

That is, there is the hardware clock and the (software) system clock. NTP synchronizes the system clock.

From http://support.ntp.org/bin/view/Servers/NTPPoolServers:

Quote:

The NTP Pool DNS system automatically picks time servers which are geographically close for you, but if you want to choose explicitly, there are sub-zones of pool.ntp.org. The "continent" ones are:

Area: HostName:
Worldwide pool.ntp.org
Asia asia.pool.ntp.org
Europe europe.pool.ntp.org
North America north-america.pool.ntp.org
Oceania oceania.pool.ntp.org
South America south-america.pool.ntp.org

There are also sub-zones for many countries. Click on your continent to see which country-zones are available there.

This means that, if you specify pool.ntp.org, NTP will pick one for you. If you specify 0.pool.ntp.org, 1.pool.ntp.org (and so on for as many as you want), the same thing happens, NTP picks them for you. If you pick, as I do:

Code:

server	0.us.pool.ntp.org
server	1.us.pool.ntp.org
server	2.us.pool.ntp.org

NTP will pick three US-based servers that are close. It will also, if later one is unreachable, throw out that server and obtain another. If you enable logging (in, say, /var/log/ntp.log):

Code:

# Log file
logfile /var/log/ntp.log
# Log file config
logconfig=+clockall +peerall +sysall +syncall

in /etc/ntp.conf, you can see when and why this happens (so you server pool will change over time).

Over the 20-odd years that I've been using NTP (in Unix System 3, SVR4, Solaris and Slackware Linux) I have never experienced a problem with NTP initial synchronization because of

Code:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

in /etc/ntp.conf (and, you know, other directories on other systems but all named ntp.conf). It generally takes up to 15 minutes for initial synchronization (after boot) using the default Slackware start up and shut down routines (I never mess with those). When the satellite receiver poops its knockers (and the blasted thing does when I rains or snows heavily), NTP falls back on itself then returns to synchronization when the connection becomes available (as it should).

My work machine provides time service to two data base servers and an occasional laptop with

Code:

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
# Serve time to LAN; allow LAN machines to synchronize with us
restrict 192.168.1.0 mask 255.255.255.0 nomodify norap
restrict 192.168.2.0 mask 255.255.255.0 nomodify norap

#
# Disable the ntpdc -c monlist command, which is insecure and can be used
# to cause a denial of service attack (CVE-2013-5211). Future versions of
# NTP will remove this command.
disable monitor

#
# Trust ourselves.  :-)
restrict 127.0.0.1
restrict ::1

in the bottom section of /etc/ntp.conf (and, of course, the server address in all the other systems). No problems whatsoever -- everybody's happy campers and everybody's time is synchronized.

Works for me.

GazL · 08-03-2014, 01:08 PM

Quote:

Originally Posted by tronayne

Over the 20-odd years that I've been using NTP (in Unix System 3, SVR4, Solaris and Slackware Linux) I have never experienced a problem with NTP initial synchronization because of

Code:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

in /etc/ntp.conf

Code:

root@ws1:/tmp# diff -u ntp_with-udlc.conf ntp_without-udlc.conf 
--- ntp_with-udlc.conf  2014-08-03 19:02:57.243318669 +0100
+++ ntp_without-udlc.conf       2014-08-03 19:04:07.894649973 +0100
@@ -11,8 +11,8 @@
 # disregard all other synchronization sources, unless the kernel
 # modifications are in use and declare an unsynchronized condition.
 #
-server 127.127.1.0     # local clock
-fudge  127.127.1.0 stratum 10
+#  server      127.127.1.0     # local clock
+#  fudge       127.127.1.0 stratum 10
 
 #
 # NTP server (list one or more) to synchronize with:
root@ws1:/tmp# date
Sun  3 Aug 19:04:22 BST 2014
root@ws1:/tmp# date 08031200  # put it back to 1200.
Sun  3 Aug 12:00:00 BST 2014
root@ws1:/tmp# ntpd -qg -c ntp_with-udlc.conf 
ntpd: time slew +0.000000s
root@ws1:/tmp# date
Sun  3 Aug 12:00:37 BST 2014
root@ws1:/tmp# ntpd -qg -c ntp_without-udlc.conf 
ntpd: time set +25523.044698s
root@ws1:/tmp# date
Sun  3 Aug 19:06:17 BST 2014
root@ws1:/tmp#

I rest my case.

metaschima · 08-03-2014, 01:14 PM

Looks pretty convincing, I'll comment the lines out, and then remove them if everything works well.