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
>
>
>
>

Reply via email to