Dear guys, I think lot of answers flied through on the original questions and I didn't see proper answers to them, so I would like to add my contribution to this topic: I collected a lot of information some week ago because of industrial servers where the time sync was an unresolved problem. As the questions raised by Fred has overlaps with my research results, I give some answer with links. Hopefully lot of people can use it in the future.
"The time server is quite close to the computer clock. What causes the discrepancy? The offset in the time server response is about 10 min. The offset is measured from what to what and how is it measured?" Once you synced the time and experience later huge offset, it means that one side of your synchronization doesn't keep the time properly or the synchronization doesn't work itself (you can make sure by running ntpq -p and verify the output. note: ntpd has to run!). Assume, that you choosed the proper time source for sync, so it means that the mechanism which steps your clock locally is broken. It can be battery reasons on the mainboard, temperature can also influence (but not too much nowadays), if you use virtual machine, that matters a lot, as it gets the CPU cycles from the host machine, and it's inner time stepping highly depends on the CPU time given by the host, finally I have never read anything about the effect of overclocking the CPU, it might have also effect on this, but test should be run to be sure. And a quotation about the offset calculation: "Synchronizing a client to a network server consists of several packet exchanges where each exchange is a pair of request and reply. When sending out a request, the client stores its own time (originate timestamp) into the packet being sent. When a server receives such a packet, it will in turn store its own time (receive timestamp) into the packet, and the packet will be returned after putting a transmit timestamp into the packet. When receiving the reply, the receiver will once more log its own receipt time to estimate the travelling time of the packet. The travelling time (delay) is estimated to be half of "the total delay minus remote processing time", assuming symmetrical delays. Those time differences can be used to estimate the time offset between both machines, as well as the dispersion (maximum offset error). The shorter and more symmetric the round-trip time, the more accurate the estimate of the current time. Time is not believed until several packet exchanges have taken place, each passing a set of sanity checks. Only if the replies from a server satisfy the conditions defined in the protocol specification, the server is considered valid. Time cannot be synchronized from a server that is considered invalid by the protocol. Some essential values are put into multi-stage filters for statistical purposes to improve and estimate the quality of the samples from each server. All used servers are evaluated for a consistent time. In case of disagreements, the largest set of agreeing servers (truechimers) is used to produce a combined reference time, thereby declaring other servers as invalid (falsetickers). Usually it takes about five minutes (five good samples) until a NTP server is accepted as synchronization source. Interestingly, this is also true for local reference clocks that have no delay at all by definition." Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm And about ntpdate. Ntpdate, believe me, is a phantastic tool which helps you the fastest way in the most critical situations where there is no time to wait until everything gets better. We know, that some encryption algorithm depends very much on accurate time, so for example in a huge infrastructure where Apache webservers using TLS encryption, and the server also have Kerberos authentication enabled, and very important things the server is doing, there the communication can not be broken just because NTP was not able to step the clock enough fast. Ntpd has higher threshold to step the clock. "After some time, small offsets (significantly less than a second) will be slewed (adjusted slowly), while larger offsets will cause the clock to be stepped (set anew)." Source: http://www.ntp.org/ntpfaq/NTP-s-algo.htm In contrast, ntpdate: "The default is to step the time using settimeofday() if the offset is greater than +-128 ms. " Source: http://doc.ntp.org/4.1.1/ntpdate.htm So in a situtation like that I never wait to ntpd to sync the time slowly. I use ntpdate, but it can be used only if ntpd or other sync programs doesn't use UDP123 port. So I stop ntpd and make an ntpdate <IP to ntpserver> and the clock is stepped right after the syncronization. About chrony: chrony has more builtin mechanism to keep the time more accurately on the server even if it is disconnected from the network. I think the future is for chrony. Details (and sorry for the redhat link, but just because it is RedHat, it is very correct information): https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/system_administrators_guide/#ch-Configuring_NTP_Using_the_chrony_Suite So guys, I hope it was useful. Best regards, Tamas Fekete 2018-08-10 18:20 GMT+02:00 Fred <f...@blakemfg.com>: > On 08/10/2018 08:18 AM, David Wright wrote: > >> On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote: >> >>> On 08/09/2018 12:42 PM, Brian wrote: >>> >>>> On Thu 09 Aug 2018 at 20:39:16 +0200, john doe wrote: >>>> >>>> On 8/9/2018 5:00 PM, Greg Wooledge wrote: >>>>> >>>>>> On Thu, Aug 09, 2018 at 10:49:52AM -0400, Jim Popovitch wrote: >>>>>> >>>>>>> On Thu, 2018-08-09 at 10:35 -0400, Greg Wooledge wrote: >>>>>>> >>>>>>>> Whoever suggested that is using outdated information. Install ntp >>>>>>>> >>>>>>> Why not openntpd? >>>>>>> >>>>>>> https://packages.debian.org/stretch/openntpd >>>>>>> >>>>>> Sure, whatever you prefer. There are at least 4 viable alternatives: >>>>>> >>>>>> ntp >>>>>> chrony >>>>>> openntpd >>>>>> systemd-timesyncd >>>>>> >>>>>> Systemd-timesyncd is only a client and using sntp. >>>>> >>>>> https://www.freedesktop.org/software/systemd/man/systemd-tim >>>>> esyncd.service.html >>>>> >>>> Ideal for what the OP wants. Either that or chrony, if he would only >>>> make his mind up. >>>> >>>> Well, what makes you think I haven't made my mind up? >>> >> (I wasn't the one seeming impatient, but) I was going to enquire at >> some time about how you got along with chrony (which you wrote you'd >> try next). >> >> The discussion you referred to might have been the one in June last >> year when I wrote that chrony did not do a lot for me. I installed >> it naively, ie I didn't poke it with chronyc, and the system remained >> five seconds slow. OTOH ntp corrected it immediately and stays >> precisely correct all the time. (jessie at the time.) >> https://lists.debian.org/debian-user/2017/06/msg00450.html >> In a follow-up, Brian had more success with chrony. >> >> Several years ago I built a "network clock" that receives WWVB time >>> signals, has a clock display and an Ethernet interface so computers >>> on the local network can ask for the time. The hardware works and >>> the software is able to decode the WWVB time code. I am interested >>> in finishing it now. The computers on the network can use a Perl >>> program to get the time. >>> >> Interesting. I played around with a Wireless World design in the >> early 70's (TTL) where the "Rugby" time code (the slow one) was >> decoded in hardware. >> >> Currently we have a consumer radio clock which is a source of mystery >> to me twice a year: the DST change occurs in the early evening on >> Saturday instead of Sunday morning. In fact, it's about the time >> that a UK clock would be changing if they moved on the same weekend >> (which they typically don't). What does your home-built clock >> reveal about the WWVB codes (assuming our clock is receiving the >> same signal in KS)? >> >> Cheers, >> David. >> >> >> Hi David, > I haven't tried chrony as I have renewed interest in completing the > "network clock" project I started some time ago. There are far more > interesting "home projects" than you can shake a stick at. I ran ntpdate > once as root and it did correct the time. > > WWVB supposedly covers the continental US. but I am sure there are areas > that don't get useful signal strength. The software for my clock is to the > point of changing the signal time intervals into bits so the next step is > doing something with the bits. > Best regards, > Fred > > > >
