Re: [Dovecot] ntp revisited (so what to do ?)
On 10/05/2011 22:36, Stan Hoeppner wrote: 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 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... NTP is free and the accuracy, when properly configured, is better than that required by any network application. If your goal is sub millisecond accuracy, it's not due to any actual network application requirement. I'm not sure if I understand your point? My point was that some Stratum 1 servers are less than 1ms accurate. You were making excited noises about being given access to a Stratum 1 server via an internet connection and I was simply pointing out that such a setup does not necessarily give super accurate time at your side (especially compared with adding a $50 GPS to a local machine - which of course makes that machine a stratum 1) Also, I don't understand your point about NTP being free? Chrony is GPL? Finally you say that NTP is better than required, but in fact NTP can often take quite a long time to converge to fairly accurate time? If the machine is rebooted (less common for a server, but more common for desktop machines), and the RTC is inaccurate, then it can take quite a long time each boot before the clock is decent. One citation here: http://lists.ntp.org/pipermail/questions/2011-April/029223.html Chrony converges much more rapidly in general NTP is clearly good enough, I was just trying to bring other ideas to the attention of the OP (and now you). Chrony is a very good solution and solves a number of problems with timekeeping that perhaps you were not even aware that you had? Kind regards Ed W
Re: [Dovecot] ntp revisited (so what to do ?)
-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-
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
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 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... NTP is free and the accuracy, when properly configured, is better than that required by any network application. If your goal is sub millisecond accuracy, it's not due to any actual network application requirement. -- Stan
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
Stan Hoeppner wrote: On 5/8/2011 5:07 AM, 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 ? When running ntpd don't run ntpdate at startup, or any time. Use one or the other, not both (if you incorrectly use both, ntpdate will throw off drift calculations in ntpd). This is the proper setup for bare metal hosts. 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. /Per Jessen, Zürich
Re: [Dovecot] ntp revisited (so what to do ?)
Stan Hoeppner wrote: 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. The sanity check may be disabled with -g in which case using ntpdate/sntp/ntpd -q at start up becomes pointless. /Per Jessen, Zürich
Re: [Dovecot] ntp revisited (so what to do ?)
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. Sure, I meant 'ntpd -q'. 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. For me, it's more important that all machines (local remote) are running the same time. Locally I sync to DCF77, externally I use the datacentre-provided NTP source. Anyway, we're way OT. /Per Jessen, Zürich
Re: [Dovecot] ntp revisited (so what to do ?)
Luigi Rosa wrote: -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? ntpd -g will set it immediately. /Per Jessen, Zürich
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
Harlan Stenn wrote: 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 None, it is just what is in the standard init-script in openSUSE. /Per Jessen, Zürich
[Dovecot] ntp revisited (so what to do ?)
OK, So what you people say is : 1. Run ntpdate during startup only once 2. After that, keep time with ntpd Right ? Regards, spyros I merely function as a channel that filters music through the chaos of noise - Vangelis
Re: [Dovecot] ntp revisited (so what to do ?)
On Sun, 8 May 2011 11:07:04 +0100 (BST) Spyros Tsiolis sts...@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. -- Jerry ✌ dovecot.u...@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __
Re: [Dovecot] ntp revisited (so what to do ?)
On Sun, May 08, 2011 at 06:45:01AM -0400, Jerry wrote: On Sun, 8 May 2011 11:07:04 +0100 (BST) Spyros Tsiolis sts...@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
Re: [Dovecot] ntp revisited (so what to do ?)
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). -- Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc Assumption is the Mother of Screw-Up -- Mr. John Elwood Hale
Re: [Dovecot] ntp revisited (so what to do ?)
On 5/8/2011 5:07 AM, 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 ? Yes, or run ntpd with the -g option.You don't want to use the -x option (as some might have suggested) as that can cause ntpd to take up to 2 weeks to synchronize the time. Detailed ntp setup is OT for this list, but make sure your ntp.conf lists at least three servers. Typically the ntp.org pool servers will work fine, eg. server 0.uk.pool.ntp.org server 1.uk.pool.ntp.org server 2.uk.pool.ntp.org server 3.uk.pool.ntp.org Then once in a while make sure ntp is running and syncronised. I like ntpq -p which will show the peerlist with a * next to the current master. ntpd works best on a long-running server, and typically shouldn't be used on a virtual server. Virtual environments have their own time service. -- Noel Jones
Re: [Dovecot] ntp revisited (so what to do ?)
On 5/8/2011 5:07 AM, 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 ? When running ntpd don't run ntpdate at startup, or any time. Use one or the other, not both (if you incorrectly use both, ntpdate will throw off drift calculations in ntpd). This is the proper setup for bare metal hosts. I didn't pay attention to earlier posts in this thread. 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. -- Stan
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
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
Re: [Dovecot] ntp revisited (so what to do ?)
Spyros wrote OK, So what you people say is : 1. Run ntpdate during startup only once 2. After that, keep time with ntpd Right ? https://support.ntp.org/bin/view/Support/StartingNTP4 says: - 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. I'm fairly certain the above is excellent advice, and BCP. H
