On Sun, May 08, 2011 at 06:45:01AM -0400, Jerry wrote:

On Sun, 8 May 2011 11:07:04 +0100 (BST) Spyros Tsiolis <stsiol@yahoo.co.uk> articulated:

...

So what you people say is :

1. Run "ntpdate" during startup only once
2. After that, keep time with ntpd

As I posted earlier using the technique I showed, on a FreeBSD system, there would be absolutely no reason to do so; however, I cannot vouch for that on other systems.

Right. As for running ntpdate, the years have passed and the debian manual now says:

   -g     Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is  1000
          s by default.  This option allows the time to be set to any value without restriction; however, this can happen
          only once.  If the threshold is exceeded after that, ntpd will exit with a message to  the  system  log.   This
          option can be used with the -q and -x options.

   -q     Exit the ntpd just after the first time the clock is set.  This behavior mimics that of  the  ntpdate  program,
          which  is to be retired.

So, ntpdate is to be retired. In boot scripts either simply run

ntpd -g

or, probably better:

ntpd -gqx
ntpd

In FreeBSD, AFAICS, setting

ntpd_enable="YES"                    # Start time server
ntpd_sync_on_start="YES"             # Synchronize on start

in /etc/rc.d corresponds to the second of the two, at least as of FreeBSD 6.4, since before 6.4 the -x was apparently missing, which would not correct big offsets, see:

http://lists.freebsd.org/pipermail/freebsd-bugs/2009-March/034439.html

On 5/8/2011 7:36 AM, Jose Celestino wrote:

On Dom, 2011-05-08 at 11:07 +0100, Spyros Tsiolis wrote:

...

OK,

So what you people say is :

1. Run "ntpdate" during startup only once
2. After that, keep time with ntpd

Right ?

Right, that ensures that time is correct (ntpdate run at startup) and that it is kept correct without the clock going back (ntp running as daemon).

This is not correct. You're assuming that ntpd doesn't perform sanity checks on the system time when the daemon starts, which is not the case.

Again, use ntpd or ntpdate, not both. Preferably, today, in 2011, and for many years now, only use ntpd, except in guests sitting atop a hypervisor. In the virtual environment case you run ntpd in the hypervisor and configure the guest kernels appropriately.

There is a plethora of platform specific documentation out there covering the VM time keeping case so I won't attempt to repeat it all here, except to say that with Linux the first/best step is running a tickless kernel, which is now the default on many distros, as it helps both laptops/netbooks when in sleep mode and VM guests when they get time sliced into what is in essence a sleep state as far as the kernel sees system clock ticks.

-- Stan

On 5/9/2011 1:31 AM, Per Jessen wrote:

Stan Hoeppner wrote:

...

This is not correct. You're assuming that ntpd doesn't perform sanity checks on the system time when the daemon starts, which is not the case.

The sanity check may be disabled with -g in which case using ntpdate/sntp/ntpd -q at start up becomes pointless.

'ntpdate -q' has always been 'pointless', unless you just want to look at the offset without modifying the clock. I do so on occasion to see how accurately my local ntp server is keeping time. For instance:

/$ ntpdate -q tick.wustl.edu ntp.okstate.edu tick.uh.edu server 128.252.19.1, stratum 1, offset -0.003486, delay 0.09729 server 139.78.135.14, stratum 1, offset 0.003479, delay 0.11545 server 129.7.1.66, stratum 1, offset -0.003950, delay 0.13434 9 May 02:39:55 ntpdate[31040]: adjust time server 128.252.19.1 offset -0.003486 sec

Mt nptd server is Debian Squeeze atop kernel 2.6.34.1, running ntp 4.2.6.p2+dfsg-1+b1. The machine is home grown w/ an 11 year old Abit main board. 0.003 seconds offset, not too shabby. ;) I've seen offset with 4 leading zeros (after the decimal) in the past. I've never seen less than two leading zeros. For most applications on my network, time this accurate is overkill, but it's nice to have.

I acquired 'special' permission many years ago to use a few stratum 1 USNO servers mostly because at that time I lived in a city where one of them is located, and because I only have one client querying infrequently. USNO is the official time keeper for the US Military and the US Government, including ships at sea via GPS. USNO has the most accurate timekeeping devices on the planet--atomic clocks. Most (if not all) of the stratum 2 servers in the US query the USNO stratum 1 servers.

-- Stan

Per wrote:

Sure, I meant 'ntpd -q'.

What benefit do you see in running something to set the time and exit before starting ntpd instead of just starting ntpd with -g?

H

On 09/05/2011 08:57, Stan Hoeppner wrote:

On 5/9/2011 1:31 AM, Per Jessen wrote:

...

Stan Hoeppner wrote:

...

...

This is not correct. You're assuming that ntpd doesn't perform sanity checks on the system time when the daemon starts, which is not the case.

The sanity check may be disabled with -g in which case using ntpdate/sntp/ntpd -q at start up becomes pointless.

'ntpdate -q' has always been 'pointless', unless you just want to look at the offset without modifying the clock. I do so on occasion to see how accurately my local ntp server is keeping time. For instance:

Can I suggest that the OP also consider Chrony for timekeeping needs?

Chrony will generally sync faster than ntp and additionally will manage the setting of the clock at startup. Even nicer it will condition the RTC clock and so for example if your RTC is drifting (it will) then chrony tries to maintain a drift estimate and set the initial time to a sensible offset from the RTC (nice!)

Chrony just made a new release a few days ago and it has a bunch of neat features for those who want to get excited about excessively accurate clocks

I acquired 'special' permission many years ago to use a few stratum 1 USNO servers mostly because at that time I lived in a city where one of them is located, and because I only have one client querying infrequently. USNO is the official time keeper for the US Military and the US Government, including ships at sea via GPS. USNO has the most accurate timekeeping devices on the planet--atomic clocks. Most (if not all) of the stratum 2 servers in the US query the USNO stratum 1 servers.

Querying an NTP stratum 1 server over the internet will likely leave you with less than millisec accuracy. ie the original is accurate, but the limitations of syncing over the internet are significant

Compared with a cheap GPS attached to your machine which should get below ms accuracy and perhaps even below the 100us mark

So, in practice it's fairly irrelevant to be hooked to a stratum 1 for most purposes and if you really want to get obsessed about accurate time (I'm going through this obsession phase right now...) then just get a local GPS attached to your machine...

I saw some analysis from the current lead Chrony developer comparing time offsets of a bunch of public timeservers and the resulting analysis seems to be that there is quite some significant skew, even on stratum 1 machines... ie you can easily do better at home with a GPS than using a public stratume 1... Curious huh

Good luck

Ed W

On 5/10/2011 8:50 AM, Ed W wrote:

...

So, in practice it's fairly irrelevant to be hooked to a stratum 1 for most purposes ...

Actually, an excellent argument can be made for hooking up to some S2 servers instead of S1 servers..

H

On Sun, 8 May 2011, Stan Hoeppner wrote:

On 5/8/2011 5:07 AM, Spyros Tsiolis wrote: So, if you're talking about a guest running inside a virtual machine then the setup is entirely different, and may vary depending on your underlying hypervisor and other factors.

Certainly I run ntpd on all my KVM-based virtual machines, since KVM provides each guest with a virtualized hardware clock. With Xen, this can also be done if using a Xen-enabled kernel in the guest, using the Xen independent wallclock. Otherwise you usually have to run ntpdate periodically through cron.

Steve

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Mon, May 09, 2011 at 08:28:38AM +0200, Per Jessen wrote:

[...]

The usual setup is to do exactly that though - ntpdate (now sntp) at startup to make sure the initial setting is reasonable, then ntpd to keep it in sync.

To be fair, that (especially the ntpdate part) seems to be a SuSE-ism.

Here's a nice reading: <http://www.ntp.org/ntpfaq/NTP-s-config.htm>

Regards

• -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFNyNwQBcgs9XrR2kYRAtPSAJ0bDpfEkzHMxgiaKEZ2izooR8VkWgCdFQ4c 2brHiLfOIy9Jlqj5Gmp4i0U= =H3mN -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Harlan Stenn said the following on 08/05/11 21:58:

• Start ntd as early as possible
• • "ntpd -g ..." is better than "ntpdate ... ; ntpd ..."
• Wait before starting time-sensitive services
• • As last as possible in the boot sequence, run 'ntp-wait -v', and start time-sensitive services after it successfully returns.

What happens if the server starts with a date very far in the past due to hardware clock reset or something like that?

I mean: if a Linux starts with the hardware clock set to 1/1/2000 how much does it take to get the real date?

I'm asking for curiosity, never tried this scenario.

Ciao, luigi

/ +--[Luigi Rosa]-- \

All in all it's just another brick in the wall... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3Hi2UACgkQ3kWu7Tfl6ZSCvwCfVP1yO2lI+QANxqwhrYry1ipW vjYAni8rivcpirUCy63k6IIts2K4Hdls =2Ob0 -----END PGP SIGNATURE-----

Per wrote:

Luigi Rosa wrote:

...

Harlan Stenn said the following on 08/05/11 21:58:

...

• Start ntd as early as possible
• • "ntpd -g ..." is better than "ntpdate ... ; ntpd ..."
• Wait before starting time-sensitive services
• • As last as possible in the boot sequence, run 'ntp-wait -v', and start time-sensitive services after it successfully returns.

What happens if the server starts with a date very far in the past due to hardware clock reset or something like that?

I mean: if a Linux starts with the hardware clock set to 1/1/2000 how much does it take to get the real date?

ntpd -g will set it immediately.

Put another way, ntpd needs the system time to be correct to within 68 years. Assuming that is true, with a good drift file and good servers/peers and the use of the 'iburst' flag, ntpd will set the clock and your (real) machine will be accurate and stable in about 11 seconds' time.

H