Clocks going forward

NY wrote:
"Paul" wrote in message
news
A tiny tidbit people might not be getting here, is how OS time works.

System boots

OS copies RTC_time (i.e. BIOS time) to software clock.
OS increments software clock based on hardware interrupts
(clock_tick or similar).
During the day, the software clock "drifts" with respect to the RTC.

System needs to shut down.
OS can copy the software clock, back into the RTC.
And a given OS assumes its choice of hours-keeping, is the only
choice, so if it uses LocalTime, every OS is using LocalTime.

(RTC runs on the CMOS clock battery if all power is lost.
RTC runs on +5VSB if you leave PC power ON at the back.
RTC "keeps the time", when the OS is not available to do it.)

While NTP is an additional variable, the polling rate of NTP
is on purpose, way too low, to be used as a "crutch" to fix this
LocalTime
issue. For example, my current OS only checks in with NTP
once a week, so if I had a LocalTime/UTC issue, it would
take a week without intervention, to get some sort of
correction.

Following an earlier discussion on this thread a week or so, I've now
tweaked my registry so the PC polls its NTP server every 24 hours rather
than every week to bring it back into sync. Before I did this, I found
that my desktop PC which remains on 24/7 as a server, video recorder and
weather-station data-acquisition, was getting out of sync with my laptop
which gets put to sleep and woken up fairly frequently and so is relying
on accuracy of RTC more than the desktop which relies entirely on OS
clock. The difference was sometimes as much as a couple of minutes,
which I cured either by forcing an unscheduled NTP sync with the
internet server, or else by "net time \\server-PC /set /y" from a
elevated DOS prompt, as and when I noticed it.

Now it's rare for me to see the two PCs displaying a different time.
Just now, I noticed the difference was about 10 seconds, and both PCs
are probably due to resync fairly soon. The time.is website has just
shown that the laptop is 11 seconds slow and the desktop is bang on. A
drift of 10 seconds or so per day (as long as it's not cumulative!) is
something I can live with.

You can improve on this.

As far as I know, the Windows implementation of NTP, doesn't
"dribble out" first order corrections.

Say, for example, the clock is off by 24 seconds per day.

I could, if I had the right software, automatically adjust
the software clock once an hour, removing a second. (And do this,
*without* pestering an NTP server in the process.) And perhaps
bringing me back into perfect sync. And because I was doing
the "dribbling" regularly, the apparent time difference between
machines is quite small.

Drift on real quartz crystals, is not first order, and so dribbling
out a 1 second correction every hour, doesn't guarantee 1 second
accuracy.

Windows, on the other hand, if you set it to "check in" every
24 hours, only notices the time is off by 24 seconds, and makes
one huge 24 second correction. I'm not aware of any attempt
by Windows to "dribble", even though the Windows time log shows
the Windows service "wakes up and thinks" every fifteen minutes.
It just doesn't seem to do anything when it wakes up, and it
goes back to sleep.

It's a free third-party NTP implementation, that implements
the dribbling method. And the dribbling method is probably
part of a standard, and it's a behavior Microsoft didn't
bother to include.

So it is possible, to "pull in" the error a tiny bit, and
make it look apparently better. But the dribbling method
assumes the clock drift is a static frequency offset in
the quartz crystal. For example, if the quartz crystal
is nominally 1,000,000 Hz but instead runs at 1,000,050, then
you could compensate for the speedup, by once an hour,
adjusting the seconds on the time, according to the
historic drift seen. If the quartz crystal was always
fast, you could do a better job of eliminating the static
error by dribbling. Good NTP software keeps track of the
apparent drift, over many NTP server checks, so it can
predict what the static error on the quartz crystal is.

This is an example of an NTP program.

https://www.meinbergglobal.com/english/sw/ntp.htm

I don't use any of these methods, and the above is
included only if you're an "obsessive" time person :-)

With the right third-party software, you can do a
little bit better, and without raising the polling
rate.

*******

You can run your own reference clock at home, and you
can also nominate one machine in your home to "serve"
time via NTP, to the other machines. Damn good clocks
have dropped to the $1000 level in price. This is not
a survey attempt at finding the cheapest one, and
just illustrates that you don't have to pay a
quarter million any more to have tech like this.

https://www.popsci.com/technology/ar...-ever-now-sale

We had a rack-mount version at work, that was GPS
disciplined, and it was all in aid of having a reference
grade 10MHz clock for a bench full of test equipment.
And the engineer doing the work, wanted a proper
reference, so the boss forked over for a "good" rack
mount clock. "You could set your watch by it" :-)
And the other engineers used to make a joke of this,
by standing near the equipment, and pretending to
set their watches :-) You need a nerd sense of
humor for this.

Paul

On 02/04/2018 22:11, VanguardLH wrote:

[a load of needlessly confusing and irrelevant information]

VanguardLH, FFS read other people's posts!

At least two other people have already answered this question perfectly
satisfactorily, without all this irrelevant verbage. The one thing
missing is that the OP has not come back to tell us that he's seen the
solutions offered, applied them, and thereby solved the problem.
However, this may well be because he hasn't even seen them, as his
original post was in uk.tech.broadcast, but it came here when a reply
was copied here ...

On 01/04/2018 13:01, J. P. Gilliver (John) wrote:
(Crossposted to a Windows 'group - may not be the right one, don't
know which one you're using - as someone there is likely to know the
correct incantations.)

.... but actually he'd've done better to crosspost to a Linux ng, because
that's where the simplest solution lies.

In message , Paul
writes:
[]
It's a free third-party NTP implementation, that implements
the dribbling method. And the dribbling method is probably
part of a standard, and it's a behavior Microsoft didn't
bother to include.
[]
What, Microsoft not bothering with part of a standard? (-:
--
J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Everyone learns from science. It all depends how you use the knowledge. - "Gil
Grissom" (CSI).

J. P. Gilliver (John) wrote:
In message , Paul
writes:
[]
It's a free third-party NTP implementation, that implements
the dribbling method. And the dribbling method is probably
part of a standard, and it's a behavior Microsoft didn't
bother to include.
[]
What, Microsoft not bothering with part of a standard? (-:

I'm not an NTP expert, but I notice other people
seem to like the third-party implementations.

As long as my computer clock shows the right day of the week, I'm
pretty happy.

I think it would be fun to have a ridiculously accurate
time piece in the computer room here (so I could
compete with Jeff Bezos), but I don't have $1000+
kicking around.

Paul

On Mon, 02 Apr 2018 23:45:59 -0400, Paul wrote:

J. P. Gilliver (John) wrote:
In message , Paul
writes:
[]
It's a free third-party NTP implementation, that implements
the dribbling method. And the dribbling method is probably
part of a standard, and it's a behavior Microsoft didn't
bother to include.
[]
What, Microsoft not bothering with part of a standard? (-:

I'm not an NTP expert, but I notice other people
seem to like the third-party implementations.

As long as my computer clock shows the right day of the week, I'm
pretty happy.

I think it would be fun to have a ridiculously accurate
time piece in the computer room here (so I could
compete with Jeff Bezos), but I don't have $1000+
kicking around.

NTP can get to within a few thousandths of a second, so that's close
enough to "ridiculously accurate" to satisfy me. The latest update here
was +0.006 seconds.

--

Char Jackson

Char Jackson wrote:
On Mon, 02 Apr 2018 23:45:59 -0400, Paul wrote:

J. P. Gilliver (John) wrote:
In message , Paul
writes:
[]
It's a free third-party NTP implementation, that implements
the dribbling method. And the dribbling method is probably
part of a standard, and it's a behavior Microsoft didn't
bother to include.
[]
What, Microsoft not bothering with part of a standard? (-:
I'm not an NTP expert, but I notice other people
seem to like the third-party implementations.

As long as my computer clock shows the right day of the week, I'm
pretty happy.

I think it would be fun to have a ridiculously accurate
time piece in the computer room here (so I could
compete with Jeff Bezos), but I don't have $1000+
kicking around.

NTP can get to within a few thousandths of a second, so that's close
enough to "ridiculously accurate" to satisfy me. The latest update here
was +0.006 seconds.


Well, the ridiculous option, would probably add another
five or six digits to that :-) And that was part of making
fun of the instrument (the absurdity of setting your
watch by it).

It was purchased for the 10MHz reference on the back, rather
than for the time piece on the front. But the clock display
on the front, was what attracted visitors to the lab.

It's basically an atomic clock. It would have these kinds of
properties, at a guess. As ours did use GPS, and we ran an antenna
up to the roof of the office building for it.

http://www.synreference.net/atomic

"To achieve even greater long-term stability, the Rubidium
reference is locked to the GPS/GNSS. This combination gives
you the best of three technologies - the stability of Rubidium,
the low noise of an OCXO and the long-term stability of GPS/GNSS."

The OCXO is an Oven controlled crystal oscillator. I doubt we'd
be so lucky, as to have the Rubidium output a signal which
is a multiple of 10MHz. And the lab standard for frequency is
10MHz, and quite a few instruments have an input for that
on the back.

The cheapest instrument that accepts 10MHz on the back, is
a frequency counter. But that's not why we bought that piece
of kit.

Paul

On 04/01/2018 01:29 PM, wrote:
On Sun, 1 Apr 2018 13:01:42 +0100, "J. P. Gilliver (John)"
wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I use a simple time sync prog called Neutron that will sort out the
time on all my Win machines.. While I haven't had any trouble with
Windows knowing what date the time changes (that was covered in a
patch back when they moved the date) Neutron also syncs the time in my
machines with a NIST server to make them all within a second or so of
each other

I'm using nettime.exe in Windows
https://sourceforge.net/projects/nettime/
Seems to have solved my issue with this for the most part. Even coming
back to Linux I note that the clock is off for just a few seconds but
resets on it's own. I like that Linux checks/resets on boot. Wish
windows would.

On 01/04/2018 13:01, J. P. Gilliver (John) wrote:
In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the
time on my computer every time I boot it into Windows after using
Linux. It's not difficult - I just go to the settings page that has
the little switch for "Set time automatically" and follow the
traditional procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

I thought many Linux distros had the option to set the hardware clock to
local time rather than to UTC.

You could also install this on your Windows:
https://www.meinbergglobal.com/english/sw/ntp.htm
It's much better than the built in Windows NTP client.

Why can't I see the OP's original message?

--

Brian Gregory (in England).

On 03/04/2018 17:24, Brian Gregory wrote:

I thought many Linux distros had the option to set the hardware clock to
local time rather than to UTC.

If you know how, you can both tell Linux to set the BIOS clock to local
time or Windows to set it to UTC. As far as programs and users are
concerned, the system clock is set to local time in both cases, updated
to match the BIOS clock at boot time, with the appropriate offset applied.


--
Tciao for Now!

John.

On 03/04/2018 17:30, John Williamson wrote:
On 03/04/2018 17:24, Brian Gregory wrote:

I thought many Linux distros had the option to set the hardware clock
to local time rather than to UTC.

If you know how, you can both tell Linux to set the BIOS clock to local
time or Windows to set it to UTC. As far as programs and users are
concerned, the system clock is set to local time in both cases, updated
to match the BIOS clock at boot time, with the appropriate offset applied.



Excellent.

Then setting Windows to expect the hardware clock to be UTC is
definitely the way to go.

That would avoid the weirdness at the time changes where both OSs change
the time, not knowing the other has already done or will do it.

I found this explaining how to do it:
https://superuser.com/questions/185773/does-windows-7-support-utc-as-bios-time/1263384

--

Brian Gregory (in England).

On Sun, 01 Apr 2018 13:01:42 +0100, J. P. Gilliver (John) wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the time
on my computer every time I boot it into Windows after using Linux. It's
not difficult - I just go to the settings page that has the little
switch for "Set time automatically" and follow the traditional procedure
of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense ends
permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be surprised
if there isn't a command line version of "go to the settings page and
... switching it off and switching it on again". (Crossposted to a
Windows 'group - may not be the right one, don't know which one you're
using - as someone there is likely to know the correct incantations.)

Rod.
John

Since you are only 1 hour off I assume that has something to do with DST.
Linux by default uses UTC and adjusts the display time after booting. The
bios clock is set to the UST time.
Windows sets the bios to local time. A google search turns up some
explanation that this somehow makes it easier for Linux machines to be
relocated and recommends leaving Linux alone and fiddling with the
windows registry. I neither like or understand that and set Linux to use
local time this works for me on Linux Mint using:
timedatectl set-local-rtc 1
Eventually whatever settings are used, the system will eventually fix
itself assuming you have it update from an Internet standard. I don't
know how long this might be in Linux, but it's fairly quick. Windows is
much longer wait. Prior to that it will display the bios time.
Personally, I think the bios should show me the current local time,
although I doubt any of us actually check the setting.

On Thu, 05 Apr 2018 15:20:12 +0000, Dave wrote:

On Sun, 01 Apr 2018 13:01:42 +0100, J. P. Gilliver (John) wrote:

In message , Roderick
Stewart writes:
[]
For the next six months or so I'll have to remember to correct the time
on my computer every time I boot it into Windows after using Linux.
It's not difficult - I just go to the settings page that has the little
switch for "Set time automatically" and follow the traditional
procedure of switching it off and switching it on again -
but I always have to remember to do it, so the sooner this nonsense
ends permanently, the better.

Since it looks unlikely that it will )-:, can't you put a batch file to
do that off-and-then-on-again into your startup folder? I'd be
surprised if there isn't a command line version of "go to the settings
page and ... switching it off and switching it on again". (Crossposted
to a Windows 'group - may not be the right one, don't know which one
you're using - as someone there is likely to know the correct
incantations.)

Rod.
John

Since you are only 1 hour off I assume that has something to do with
DST.
Linux by default uses UTC and adjusts the display time after booting.
The bios clock is set to the UST time.
Windows sets the bios to local time. A google search turns up some
explanation that this somehow makes it easier for Linux machines to be
relocated and recommends leaving Linux alone and fiddling with the
windows registry. I neither like or understand that and set Linux to use
local time this works for me on Linux Mint using:
timedatectl set-local-rtc 1 Eventually whatever settings are used, the
system will eventually fix itself assuming you have it update from an
Internet standard. I don't know how long this might be in Linux, but
it's fairly quick. Windows is much longer wait. Prior to that it will
display the bios time. Personally, I think the bios should show me the
current local time, although I doubt any of us actually check the
setting.

When I installed Linux Mint 17.1 just on 3 years ago, I chose to go with
the "set the RTC to UTC" option since I was never ever going to be using
dual/multiboot, preferring to run any windows OSen as virtual machines
under Oracle's VirtualBox. I run this desktop setup 24/7 most of the time
and, likewise the winXP VM. both the host and the guest OSes handle the
DST changes seamlessly (presumably VBox virtualises the RTC as well. :-)

--
Johnny B Good

On 04/05/2018 11:20 AM, Dave wrote:
Personally, I think the bios should show me the current local time,
although I doubt any of us actually check the setting.
I've got a 55" smart TV and for the heck of it I looked at the update
setting but it bulked that I didn't have time set. I've been using it
over 18 months and never had the time set OR EVEN looked at it!
Not that it's used in any way I use the TV.

On 05/04/2018 16:20, Dave wrote:

Since you are only 1 hour off I assume that has something to do with DST.
Linux by default uses UTC and adjusts the display time after booting. The
bios clock is set to the UST time.
Windows sets the bios to local time. A google search turns up some
explanation that this somehow makes it easier for Linux machines to be
relocated and recommends leaving Linux alone and fiddling with the
windows registry. I neither like or understand that and set Linux to use
local time this works for me on Linux Mint using:
timedatectl set-local-rtc 1
Eventually whatever settings are used, the system will eventually fix
itself assuming you have it update from an Internet standard. I don't
know how long this might be in Linux, but it's fairly quick. Windows is
much longer wait. Prior to that it will display the bios time.
Personally, I think the bios should show me the current local time,
although I doubt any of us actually check the setting.

One beauty of computers is that there is always more than one way of
doing any given job. In this case, at least three fairly simple ways
have been detailed in this thread, so choose the one that suits you.

--
Tciao for Now!

John.

On 04/05/2018 10:33 AM, Johnny B Good wrote:

[snip]

When I installed Linux Mint 17.1 just on 3 years ago, I chose to go with
the "set the RTC to UTC" option since I was never ever going to be using
dual/multiboot, preferring to run any windows OSen as virtual machines
under Oracle's VirtualBox. I run this desktop setup 24/7 most of the time
and, likewise the winXP VM. both the host and the guest OSes handle the
DST changes seamlessly (presumably VBox virtualises the RTC as well. :-)

That's what I do on my main machine (Linux host, Windows in VM). I never
have any DST-related problems. Hardware RTC is set to UTC.

BTW, I have 4 versions of Windows here (2000, XP, 7, 10) in separate VMs.

--
Mark Lloyd
http://notstupid.us/

"And lo, Jesus did say unto the soldiers 'Not the OTHER hand. Ow ****,
that hurts! You assholes!' " [2 Kinison 3:45]