Re: What time is it, really?
On Friday 10 August 2018 13:46:46 Fekete Tamás wrote:
> 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_th
>e_chrony_Suite
>
As a long term user (19 years) of ntpdate in the early years, before ntp
grew that function, and ntp after boot all the time, I think a similar
disection to the above, but for chrony would be a valuable asset to be
able to reference in detail the man pages skip or gloss over. Hint,
hint. It might also disclose its Achilles heel, security leaks etc,
which will usually lead to improvements in its code.
> So guys, I hope it was useful.
>
> Best regards,
> Tamas Fekete
>
Tamas Fekete: This discussion has been most worthwhile as I have now
completed the concept of haveing only my router access the networks
level 2 servers, then this machine syncing to the router, and the rest
of my machines now listen to the rebroadcasts this machine makes on
domain.name.255. So I have good synch system wide, with only one, the
router, actually querying the nets level 2 servers. If all of us with
multi-machine home (or business for that matter) networks, we could cut
the load on the level 2 servers by 50% or more. We should all remember
the one immutable law about ALL of this stuff, TANSTAAFL.
> 2018-08-10 18:20 GMT+02:00 Fred <fred@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
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: