Re: What time is it, really?

[Dale Forsyth]

https://www.mycause.com.au/page/183259/a-smile-will-change-a-day-love-that-changed-my-world

From: Michael Stone 
Sent: Friday, 10 August 2018 3:53 AM
To: debian-user@lists.debian.org
Subject: Re: What time is it, really?

On Thu, Aug 09, 2018 at 11:54:54AM -0400, Greg Wooledge wrote:
>On Thu, Aug 09, 2018 at 04:15:36PM +0100, Darac Marjal wrote:
>> Additionally, from http://doc.ntp.org/current-stable/ntpq.html#rv (rv allows
>> one to read the offset for a particular association directly), "Note that
>> time values are represented in milliseconds and frequency values in
>> parts-per-million (PPM)."
>
>Where do I even start

It sounds like you should start with a user/client/desktop oriented time
program. There's no reason for most users to be running ntpd in 2018. If
you're running a server syncing to a PPS source or somesuch then you
need ntpd. But at that point you're going to have to learn a lot of
domain-specific jargon to do that thing, at which point the ntpd
documentation is fine. If you want something that's fire and forget,
then install openntpd or systemd-timesyncd and call it a day.

Mike Stone

Re: What time is it, really?

[Fekete Tamás]

Dear Colleagues,

I think the extensions made by others to my comment were very valuable.
Only thing I would like to add, that Fred's (original asker) problem is
probably that time sync daemon can not do it's job in the background
properly.
Ntpd can not sync on startup or later and time async reaches 10 min, which
is huge.
So the problem here is two:

- the time stepper probably broken
- and the time sync software can not do it's job properly.

I would suggest to debug the second first, as you will need time sync even
after you solved the first problem.
Just some suggestion to this:
- check the ntpd logs. If there is no dedicated log file to it, make one by
editing the ntp.conf file
- check if the drift file can be accessed and is writeable to ntpd
- check the restriction section in ntp.conf file. Make sure the service is
available on localhost at least on IPv4
- if ntpd runs, issue ntpq -p command and check it's output (compare it's
output to any other linux machine with working time sync)

Best regards
Tamas Fekete

2018-08-10 22:53 GMT+02:00 Michael Stone :

> On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
>
>> 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.
>>
>
> It's also really bad to run more than one time synchronization at
> once--they'll tend to confuse each other and cause random time shifts.
>
> 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
>>
>
> This isn't true on ntpd startup; it'll step the clock to get it close and
> slew thereafter. The only case where this a problem is if there are major
> issues with the local clock. (Which generally means you have bigger
> problems.) You may be thinking of the behavior where ntpd will exit on
> startup if the time is too far off. Using the -g option causes it to just
> set the time and carry on. (There are pros and cons to both approaches.)
>
> Mike Stone
>
>

Re: What time is it, really?

[Michael Stone]

On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:

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.


It's also really bad to run more than one time synchronization at 
once--they'll tend to confuse each other and cause random time shifts.



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


This isn't true on ntpd startup; it'll step the clock to get it close 
and slew thereafter. The only case where this a problem is if there are 
major issues with the local clock. (Which generally means you have 
bigger problems.) You may be thinking of the behavior where ntpd will 
exit on startup if the time is too far off. Using the -g option causes 
it to just set the time and carry on. (There are pros and cons to both 
approaches.)


Mike Stone

Re: What time is it, really?

[David Wright]

On Fri 10 Aug 2018 at 09:20:42 (-0700), Fred wrote:
> On 08/10/2018 08:18 AM, David Wright wrote:
> >On Thu 09 Aug 2018 at 14:26:30 (-0700), Fred wrote:
> >>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.

Correction: it was the fast code I was using. I was confused by the
fact that we also used a BCD-encoded slow code on some of our clocks
around the same time; the latter was necessarily slow because there
were mechanical relays that had to be able to follow it.

> 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 of luck with this, and far better done in software. I turned up
a reference to the one I played with:
http://www.keith-snook.info/wireless-world-magazine/Wireless-World-1976/Self-setting%20time%20code%20clock.pdf
and its lifetime would have lasted until 1998 when they turned off
the fast code at MSF. But 1976 was about the time that microprocessors
were becoming affordable for this kind of work.

AFAIK signal strength is not an issue for us as there's not a lot
between here and CO. The only radio clock I've known to have an issue
was one that wouldn't synchronise in a UK church vestry. I swapped it
for an ancient electric wall clock, and the radio one worked perfectly
in our basement.

Cheers,
David.

Re: What time is it, really?

[David Wright]

On Fri 10 Aug 2018 at 11:32:35 (-0400), Michael Stone wrote:
> On Fri, Aug 10, 2018 at 10:18:19AM -0500, David Wright wrote:
> >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.
> 
> The clock isn't properly decoding the DST bits. See
> https://en.wikipedia.org/wiki/WWVB
[…]
> Your clock is probably only looking at the first bit, and skipping
> the logic for when to actually apply the change. A lot of the
> functionality in the time code actually allows for relatively
> graceful degradation like this to facilitate simpler or more complex
> receivers.

Ah, that makes sense. So the different time of the change (which meant
I didn't remember precisely what time it happened) is because of the
varying offset (5, 6 hours) in spring and autumn, and a delay after
that hour o'clock would likely indicate varying signal strength and
lapses in reliable code detection. Now I know what's happening, I can
watch for the latter. Being a dial clock, there's no signal strength
indicator. Our LCD clock does display it approximately, but that only
understands MSF, not WWVB, so it's now free-running (remarkably well
especially since the Low Battery warning has been flashing since
before Christmas).

Cheers,
David.

Re: What time is it, really?

[Gene Heskett]

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
>  and the clock is stepped right after the
> syncronization.
>
> About chrony:
> chrony has more builtin mechanism to keep the time more 

Re: What time is it, really?

[Greg Wooledge]

On Fri, Aug 10, 2018 at 07:46:46PM +0200, Fekete Tamás wrote:
> 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  ntpserver> and the clock is stepped right after the syncronization.

ntpdate can set the clock BACKWARD as well as forward.  Setting the clock
backward can break all kinds of shit.  Jumping the clock forward by a
large amount can also break things, but it's not as bad as going backward.

If you find that your mission-critical server has lost its clock sync
for some reason, you're better off rebooting it.  Assuming, of course,
you have already fixed whatever caused ntpd to stop working in the first
place.

Because obviously you were running ntpd on it.  Right?  Right.

Rebooting lets ntpd's -g option peform an ntpdate-like clock jump once
again, and this will ideally happen BEFORE anything else that depends
on the clock is started.  So, if all is arranged correctly, by the
time your time-sensitive services come back up, the clock will already
be approximately correct, and it will be monotonically increasing as
it finishes converging toward precision.

Re: What time is it, really?

[Brian]

On Fri 10 Aug 2018 at 09:20:42 -0700, Fred wrote:

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

Five minutes work. As opposed to 

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

The vast majority of users would be content with systemd-timesyncd or
chrony. Both simple, easy and reliable enough to forget about any
time-keeping problems. But each to his own.

-- 
Brian.

Re: What time is it, really?

[Fekete Tamás]

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

Re: What time is it, really?

[Fred]

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

Re: What time is it, really?

[Michael Stone]

On Fri, Aug 10, 2018 at 10:18:19AM -0500, David Wright wrote:

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.


The clock isn't properly decoding the DST bits. See 
https://en.wikipedia.org/wiki/WWVB


The DST status bits indicate United States daylight saving time rules. 
The bits are updated daily during the minute starting at 00:00 UTC. 
The first DST bit, transmitted at 57 seconds past the minute, changes 
at the beginning of the UTC day that DST comes into effect or ends. 
The other DST bit, at second 58, changes 24 hours later (after the DST 
change). Therefore, if the DST bits differ, DST is changing at 02:00 
local time during the current UTC day. Before the next 02:00 local 
time after that, the bits will be the same.


Each change in the DST bits will first be received in the mainland 
United States between 16:00 (PST) and 20:00 (EDT), depending on the 
local time zone and on whether DST is about to begin or end. A receiver 
in the Eastern time zone (UTC−5) must therefore correctly receive the 
"DST is changing" indication within a seven-hour period before DST 
begins, and six hours before DST ends, if it is to change the local time 
display at the correct time. Receivers in the Central, Mountain, and 
Pacific time zones have one, two, and three more hours of advance 
notice, respectively. 


Your clock is probably only looking at the first bit, and skipping the 
logic for when to actually apply the change. A lot of the functionality 
in the time code actually allows for relatively graceful degradation 
like this to facilitate simpler or more complex receivers.


Mike Stone

Re: What time is it, really?

[David Wright]

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

Re: What time is it, really?

[deloptes]

Greg Wooledge wrote:

> Whoever suggested that is using outdated information.  Install ntp and
> not ntpdate.

I did not suggested this but I also use ntpdate. Especially on laptop that
is not connected to the network all the time it does not make sense, as you
get those nasty mails that ntp server is not reachable.
I added simple cron job many moons ago to let ntpdate run twice a day - why
should I have a daemon running?

anyway, both is valid and one can choose what better suits. The memory
footprint of ntp is indeed really small.

regards

Re: What time is it, really?

[Shea Alterio]

The only clock in my house that stays perfectly on time without NTP is my
akai s5000 sampler. It runs on a 386 ;)

On Thu, Aug 9, 2018 at 5:39 PM 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-timesyncd.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?
>
> 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.
>
> Thanks for the help.
> Best regards,
> Fred
>
>

Re: What time is it, really?

[Fred]

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-timesyncd.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?

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.


Thanks for the help.
Best regards,
Fred

Re: What time is it, really?

[Brian]

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-timesyncd.service.html

Ideal for what the OP wants. Either that or chrony, if he would only
make his mind up.

-- 
Brian.

Re: What time is it, really?

[john doe]

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-timesyncd.service.html

--
John Doe

Re: What time is it, really?

[Michael Stone]

On Thu, Aug 09, 2018 at 09:36:33AM -0700, Fred wrote:
I think you may be right.  It seems a stupid response from ntpdate 
since I asked the time from the server.  So, ntpdate maybe isn't what 
I should be using.


ntpdate isn't a tool to tell you the time, it's a tool to establish the 
offset between your clock and a remote clock. The timestamp that appears 
is just a log entry. If you want to use ntpdate you can put it in a cron 
job that gets called once per day or whatever. You may want to add the 
-s option so the log goes to syslog instead of stdout. This will work 
fine.


There was a discussion about time services on this list some time ago 
and at that time I decided chrony should be used so I will try it 
next.  I don't want a service that keeps banging on the server.  Once 
a day seems reasonable to me.  Can chrony be configured to check in 
once a day.  I don't expect the time to be more accurate than 30 
seconds.  The computer does run 24/7 so the drift is in the software.


chrony is also probably overkill for you. I'd suggest openntpd or 
systemd-timesyncd. They'll check more than once per day, but it's really 
not much traffic or a big deal. Or you can just stick with ntpdate.


Mike Stone

Re: What time is it, really?

[Michael Stone]

On Thu, Aug 09, 2018 at 11:54:54AM -0400, Greg Wooledge wrote:

On Thu, Aug 09, 2018 at 04:15:36PM +0100, Darac Marjal wrote:

Additionally, from http://doc.ntp.org/current-stable/ntpq.html#rv (rv allows
one to read the offset for a particular association directly), "Note that
time values are represented in milliseconds and frequency values in
parts-per-million (PPM)."


Where do I even start


It sounds like you should start with a user/client/desktop oriented time 
program. There's no reason for most users to be running ntpd in 2018. If 
you're running a server syncing to a PPS source or somesuch then you 
need ntpd. But at that point you're going to have to learn a lot of 
domain-specific jargon to do that thing, at which point the ntpd 
documentation is fine. If you want something that's fire and forget, 
then install openntpd or systemd-timesyncd and call it a day.


Mike Stone

Re: What time is it, really?

[Nicolas George]

Greg Wooledge (2018-08-09):
> Not very useful.  OK, the man page also says, "SEE ALSO
> /usr/share/doc/ntp-doc/html/ntpq.html for the full documentation."
 ^^^
> 
> Of course, that file does not exist.
> 
> One might try to jump through hoops to try to find out how to obtain
> this file, etc.

You mean, like installing the ntp-doc package, maybe ?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: What time is it, really?

[Andre Majorel]

On 2018-08-09 11:54 -0400, Greg Wooledge wrote:
> On Thu, Aug 09, 2018 at 04:15:36PM +0100, Darac Marjal wrote:
> > Additionally, from
> > http://doc.ntp.org/current-stable/ntpq.html#rv (rv allows
> > one to read the offset for a particular association
> > directly), "Note that time values are represented in
> > milliseconds and frequency values in parts-per-million
> > (PPM)."
> 
> [...] So, since all of this documentation is not very
> user-friendly, I rely on word of mouth to tell people, "Hey,
> see this offset field? It's milliseconds, not seconds."

At times, it's hard to make sense of the collective behaviour of
people.

90% of the population seem to think that any software that
requires reading one line of documentation is worthless.

Then there's those who defend poorly documented software,
insisting that "it's all in there", provided you spend a few
hours or days memorising every text file in the package,
including the source. After which, anyone who's not a moron
would know the answer to their question simply by putting
together one sentence from the man page with the twelfth item in
the FAQ and the entry for version 1.6.9 in the what's-new file.

Is there no middle ground at all ? Are we condemned to choose
between two forms of insanity ?

Sorry, pet peeve. Nothing personal.

-- 
André Majorel 
I trust bugs.debian.org to not publish my email address for
spammers to harvest.

Re: What time is it, really?

[Nicolas George]

Fred (2018-08-09):
> I think you may be right.  It seems a stupid response from ntpdate since I
> asked the time from the server.

It gave you the information.

>  So, ntpdate maybe isn't what I should be
> using.

That is what many people have just told you.

> There was a discussion about time services on this list some time ago and at
> that time I decided chrony should be used so I will try it next.  I don't
> want a service that keeps banging on the server.

Since you do not have the skill yourself, trust the default
configuration.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: What time is it, really?

[Greg Wooledge]

On Thu, Aug 09, 2018 at 09:36:33AM -0700, Fred wrote:
> I don't
> want a service that keeps banging on the server.  Once a day seems
> reasonable to me.

It's not.

Re: What time is it, really?

[Fred]

On 08/09/2018 07:42 AM, Nicolas George wrote:

Fred (2018-08-09):

Someone complained off list about the timestamp in my emails being off.
Being a hardware person I think hardware should work properly and clocks
should keep accurate time.  So I installed ntpdate as suggested but it is
not active yet.

Nowadays, unless you have religions objections, you should just enable
systemd-timesyncd, it is the most lightweight and transparent way of
enabling network time synchronization with nowadays Debian.

ntpdate is not really good because it only does punctual queries; ntpd
and timesyncd will keep stats and adjust more accurately.


If I ask google what time it is in Mesa AZ. the response agrees closely with
an "atomic" clock I have.  The computer clock is about 10 min. fast.

fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
  9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4

   ^^^

offset -610.509394 sec

fred@ragnok:~$ date
Thu Aug  9 06:51:18 MST 2018

The time server is quite close to the computer clock.

If you are looking at the time I underlined above, I am pretty sure
(looking at the source) that it is the local time, not the time returned
by the server.

Regards,


Hi,
I think you may be right.  It seems a stupid response from ntpdate since 
I asked the time from the server.  So, ntpdate maybe isn't what I should 
be using.


There was a discussion about time services on this list some time ago 
and at that time I decided chrony should be used so I will try it next.  
I don't want a service that keeps banging on the server.  Once a day 
seems reasonable to me.  Can chrony be configured to check in once a 
day.  I don't expect the time to be more accurate than 30 seconds.  The 
computer does run 24/7 so the drift is in the software.


Best regards,
Fred

Re: What time is it, really?

[Greg Wooledge]

On Thu, Aug 09, 2018 at 04:15:36PM +0100, Darac Marjal wrote:
> Additionally, from http://doc.ntp.org/current-stable/ntpq.html#rv (rv allows
> one to read the offset for a particular association directly), "Note that
> time values are represented in milliseconds and frequency values in
> parts-per-million (PPM)."

Where do I even start

OK, let's start with "man ntpq".  The -p option says, "Print  a list of
the peers known to the server as well as a summary of their state.  This is
equivalent to the peers interactive command."

Not very useful.  OK, the man page also says, "SEE ALSO
/usr/share/doc/ntp-doc/html/ntpq.html for the full documentation."

Of course, that file does not exist.

One might try to jump through hoops to try to find out how to obtain
this file, etc.  I'll just assume for the moment that the end result
of those hoops would lead me to a page that's basically the same as
your URL shown above, so I'll skip those hoops.

Now, let's look at the URL you provided.

The #rv anchor points to a section for the "rv" command, which it seems
is an alias for the "readvar" command.  There's no indication that this
is relevant to me in any way.

Right above that, is the peers command.  The man page says that -p is
equivalent to peers, so we have an indication that the peers section of
this page might be relevant!  OK!  So, we read the "peers" section, and
it says, "offset of server relative to this host".

That's it.  No units are mentioned in the output or in the documentation.

If we jump to the end of the page, there's just some tables and stuff.
Nothing comprehensible.  If we jump to the start, and skip the
paragraphs of incomprehensible jargon, there's a sentence that says,
"For examples and usage, see the NTP Debugging Techniques page."

OK, so let's follow that link.

Under "Verifying Correct Operation", it says "The ntpq commands pe, as
and rv are normally sufficient to verify correct operation ...".
What's pe?  Is that short for "peers"?  Let's assume it's short for
"peers", and that whoever wrote this document wasn't writing it for
ordinary humans.

"The pe command displays a list showing the DNS name or IP address for
each association along with selected status and statistics variables."

Then it goes on to talk about the "as" and "rv" commands, which includes
some wording about times being in milliseconds, but why would I read that
paragraph at all?  It's talking about these other two commands that I'm
not using.

...

So, since all of this documentation is not very user-friendly, I
rely on word of mouth to tell people, "Hey, see this offset field?
It's milliseconds, not seconds."

Re: What time is it, really?

[Darac Marjal]

On Thu, Aug 09, 2018 at 10:35:23AM -0400, Greg Wooledge wrote:

On Thu, Aug 09, 2018 at 07:19:46AM -0700, Fred wrote:

So I installed ntpdate as suggested but it is
not active yet.


Whoever suggested that is using outdated information.  Install ntp and
not ntpdate.

The current versions of the ntp package (since, like, Debian 6.x I think)
incorporate the one-time clock slamming feature of ntpdate, so you don't
need ntpdate at all.


If I ask google what time it is in Mesa AZ. the response agrees closely with
an "atomic" clock I have.  The computer clock is about 10 min. fast.


Once you've had ntp installed for several minutes (and possibly rebooted,
if your clock was particularly bad), you can query it with "ntpq -p" to
see how it's doing.

Unfortunately, the output format of ntpq -p isn't DOCUMENTED anywhere, so
it's a bit cryptic.  The most important thing to know, which is not stated
anywhere except word of mouth like this email, is that the "offset" column
is reporting milliseconds, not seconds.



Actually, quoting http://doc.ntp.org/current-stable/debug.html: "Note 
that, except for explicit calendar dates, times are in milliseconds and 
frequencies are in parts-per-million (PPM).


Additionally, from http://doc.ntp.org/current-stable/ntpq.html#rv (rv 
allows one to read the offset for a particular association directly), 
"Note that time values are represented in milliseconds and frequency 
values in parts-per-million (PPM)."


--
For more information, please reread.


signature.asc
Description: PGP signature

Re: What time is it, really?

[Gene Heskett]

On Thursday 09 August 2018 10:35:23 Greg Wooledge wrote:

> On Thu, Aug 09, 2018 at 07:19:46AM -0700, Fred wrote:
> > So I installed ntpdate as suggested but it is
> > not active yet.
>
> Whoever suggested that is using outdated information.  Install ntp and
> not ntpdate.
>
+1

> The current versions of the ntp package (since, like, Debian 6.x I
> think) incorporate the one-time clock slamming feature of ntpdate, so
> you don't need ntpdate at all.
>
> > If I ask google what time it is in Mesa AZ. the response agrees
> > closely with an "atomic" clock I have.  The computer clock is about
> > 10 min. fast.
>
> Once you've had ntp installed for several minutes (and possibly
> rebooted, if your clock was particularly bad), you can query it with
> "ntpq -p" to see how it's doing.
>
> Unfortunately, the output format of ntpq -p isn't DOCUMENTED anywhere,
> so it's a bit cryptic.  The most important thing to know, which is not
> stated anywhere except word of mouth like this email, is that the
> "offset" column is reporting milliseconds, not seconds.

Something else I had forgotten is the loading on the level 2 servers. But 
was reminded just now. I have ntp running on my router, and this machine 
is running on the routers time broadcasts which you can enable in 
dd-wrt, and most of the rest of my machines are set and controlled by 
the this machines rebroadcast, see the man pages about how to do that. 
So I supposedly have only one actual query going out to the network time 
servers despite there being 7 to 8 machines on my local network, so that 
6 or 7 machines that are not banging on the level 2 servers.

Thats simply being a good net citizen.
-- 
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 

Re: What time is it, really?

[Jim Popovitch]

On Thu, 2018-08-09 at 11:00 -0400, 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
> 
> Pick your favorite.  ntpdate and rdate are NOT included in this list.
> 

Well, It's not for me.  I was just asking why you suggested ntp over
openntpd?  One has more advantages over the other.

-Jim P.


signature.asc
Description: This is a digitally signed message part

Re: What time is it, really?

[Greg Wooledge]

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

Pick your favorite.  ntpdate and rdate are NOT included in this list.

Re: What time is it, really?

[Jim Popovitch]

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


-Jim P.



signature.asc
Description: This is a digitally signed message part

Re: What time is it, really?

[Gene Heskett]

On Thursday 09 August 2018 10:19:46 Fred wrote:

> Hi,
>
> Someone complained off list about the timestamp in my emails being
> off. Being a hardware person I think hardware should work properly and
> clocks should keep accurate time.  So I installed ntpdate as suggested
> but it is not active yet.

And it only sets the clock once, at boot time.
>
Todays version of ntp(ntpd) handles that right well, my hardware clock is 
on grenwich and software on local, and both stay within 50 milliseconds 
of real time.

> If I ask google what time it is in Mesa AZ. the response agrees
> closely with an "atomic" clock I have.  The computer clock is about 10
> min. fast.
>
> fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
> server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay
> 0.09421 server 132.163.96.4, stratum 1, offset -610.509394, delay
> 0.08899 9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
> offset -610.509394 sec
>
> fred@ragnok:~$ date
> Thu Aug  9 06:51:18 MST 2018
>
> 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?
>
As stated. ntp handles that by making small corrections so as to not 
disturb other time sensitive stuff on your computer. Thats another way 
of saying your 10 minute error may take it 4 hours to correct. The hdwe 
clock is set as part of the shutdown, so if you don't run 24/7, you 
don't start from square one the next time you powerup. And its so little 
cpu load you may not even find it with some of the monitoring 
facilities. Here, sorted on cpu usage, its about the 20th down the htop 
list.


> 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 

Re: What time is it, really?

[Nicolas George]

Fred (2018-08-09):
> Someone complained off list about the timestamp in my emails being off.
> Being a hardware person I think hardware should work properly and clocks
> should keep accurate time.  So I installed ntpdate as suggested but it is
> not active yet.

Nowadays, unless you have religions objections, you should just enable
systemd-timesyncd, it is the most lightweight and transparent way of
enabling network time synchronization with nowadays Debian.

ntpdate is not really good because it only does punctual queries; ntpd
and timesyncd will keep stats and adjust more accurately.

> If I ask google what time it is in Mesa AZ. the response agrees closely with
> an "atomic" clock I have.  The computer clock is about 10 min. fast.
> 
> fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
> server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
> server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
>  9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
  ^^^
> offset -610.509394 sec
> 
> fred@ragnok:~$ date
> Thu Aug  9 06:51:18 MST 2018
> 
> The time server is quite close to the computer clock.

If you are looking at the time I underlined above, I am pretty sure
(looking at the source) that it is the local time, not the time returned
by the server.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature

Re: What time is it, really?

[Michael Stone]

On Thu, Aug 09, 2018 at 07:19:46AM -0700, Fred wrote:
Someone complained off list about the timestamp in my emails being 
off.  Being a hardware person I think hardware should work properly 
and clocks should keep accurate time.  So I installed ntpdate as 
suggested but it is not active yet.


If I ask google what time it is in Mesa AZ. the response agrees 
closely with an "atomic" clock I have.  The computer clock is about 10 
min. fast.


fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
offset -610.509394 sec

fred@ragnok:~$ date
Thu Aug  9 06:51:18 MST 2018

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?


I'm having trouble understanding what you wrote here. What time do you 
think it should be when you ran the commands above?


Mike Stone

Re: What time is it, really?

[Martin]

Hi Fred,

your hardware clock may be off -> man hwclock.
You can sysc it to your system time with 'hwclock -w'. hwclock requires root 
powers.

Am 09.08.2018 um 16:19 schrieb Fred:
> Hi,
> 
> Someone complained off list about the timestamp in my emails being off.  
> Being a hardware person I think hardware should work properly and clocks 
> should keep accurate time.  So I installed ntpdate as suggested but it is not 
> active yet.
> 
> If I ask google what time it is in Mesa AZ. the response agrees closely with 
> an "atomic" clock I have.  The computer clock is about 10 min. fast.
> 
> fred@ragnok:~$ /usr/sbin/ntpdate -q time.nist.gov
> server 2610:20:6f96:96::4, stratum 1, offset -610.512368, delay 0.09421
> server 132.163.96.4, stratum 1, offset -610.509394, delay 0.08899
>  9 Aug 06:51:15 ntpdate[13672]: step time server 132.163.96.4
> offset -610.509394 sec
> 
> fred@ragnok:~$ date
> Thu Aug  9 06:51:18 MST 2018
> 
> 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?
> 
> Best regards,
> Fred
> 
> 

Re: What time is it, really?

[Greg Wooledge]

On Thu, Aug 09, 2018 at 07:19:46AM -0700, Fred wrote:
> So I installed ntpdate as suggested but it is
> not active yet.

Whoever suggested that is using outdated information.  Install ntp and
not ntpdate.

The current versions of the ntp package (since, like, Debian 6.x I think)
incorporate the one-time clock slamming feature of ntpdate, so you don't
need ntpdate at all.

> If I ask google what time it is in Mesa AZ. the response agrees closely with
> an "atomic" clock I have.  The computer clock is about 10 min. fast.

Once you've had ntp installed for several minutes (and possibly rebooted,
if your clock was particularly bad), you can query it with "ntpq -p" to
see how it's doing.

Unfortunately, the output format of ntpq -p isn't DOCUMENTED anywhere, so
it's a bit cryptic.  The most important thing to know, which is not stated
anywhere except word of mouth like this email, is that the "offset" column
is reporting milliseconds, not seconds.