time synchronisation

[J. P. Gilliver]

When I select "Adjust date/time" from the clock menu, I get the "Date
and Time" window, with three tabs; if I select the "Internet Time" one,
I am told "This computer is set to automatically synchronize with" a
time server. There's also a "Change settings..." button.

I clicked that button, expecting to be able to change the server and the
interval. I get a window containing: a tickbox to turn syncing on and
off altogether; a drop-down list of servers (I vaguely remember a post
or something telling me how to modify that list); and an "Update now"
button. It also tells me "The clock was successfully synchronised with
<timeserver> on 2023-12-17 at 19:00."

That was when I clicked "Update now" just now; it obviously _hadn't_
been doing so (it had been more or less a minute slow), despite (a)
"This computer is set to automatically ..." and (b) the time server
selected must still work (otherwise it wouldn't have "successfully
synchronised" when I told it to. (It did - it advanced by the minute -
as well as _telling_ me it had.

So:

1. Why isn't it, despite (a) the "Synchronise ..." button being ticked,
and (b) a valid time server being in the box?
2. Where do I set the interval?

(No, I don't want to install a third-party utility: my mail/news suite
will do that if I start it with admin. privileges, but why isn't/how do
I set the interval in the mechanism that's part of the OS?)

[Paul]

When I select "Adjust date/time" from the clock menu, I get the "Date and Time" window, with three tabs; if I select the "Internet Time" one, I am told "This computer is set to automatically synchronize with" a time server. There's also a "Change settings..." button.
I clicked that button, expecting to be able to change the server and the interval. I get a window containing: a tickbox to turn syncing on and off altogether; a drop-down list of servers (I vaguely remember a post or something telling me how to modify that list); and an "Update now" button. It also tells me "The clock was successfully synchronised with <timeserver> on 2023-12-17 at 19:00."
That was when I clicked "Update now" just now; it obviously _hadn't_ been doing so (it had been more or less a minute slow), despite (a) "This computer is set to automatically ..." and (b) the time server selected must still work (otherwise it wouldn't have "successfully synchronised" when I told it to. (It did - it advanced by the minute - as well as _telling_ me it had.
1. Why isn't it, despite (a) the "Synchronise ..." button being ticked, and (b) a valid time server being in the box?
2. Where do I set the interval?
(No, I don't want to install a third-party utility: my mail/news suite will do that if I start it with admin. privileges, but why isn't/how do I set the interval in the mechanism that's part of the OS?)

Meinberg leaks out first order time corrections, which is something W32time
does not do. It studies the numbers it is seeing, to work out how
far off your clock adjustment is, and it leaks out corrections maybe
every fifteen minutes. Windows does not bother to do that, so the
clock offset grows over the week of uncalibrated operation.

This is what a Windows 7 might show. Dial down the 604800 number.

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
SpecialPollInterval DWORD32 0x93a80 604800 seconds or one week
SpecialPollTimeRemaining Multi_SZ time.windows.com,0

If you hammer time.windows.com too frequently, your IP will be blocked :-)
No, I do not know the threshold value for that.

Paul

[J. P. Gilliver]

In message <ulnv0g$357i7$***@dont-email.me> at Sun, 17 Dec 2023 18:07:58,
Paul <***@needed.invalid> writes
[]

Post by Paul
Meinberg leaks out first order time corrections, which is something W32time
does not do. It studies the numbers it is seeing, to work out how
far off your clock adjustment is, and it leaks out corrections maybe
every fifteen minutes. Windows does not bother to do that, so the
clock offset grows over the week of uncalibrated operation.
This is what a Windows 7 might show. Dial down the 604800 number.
HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
SpecialPollInterval DWORD32 0x93a80 604800
seconds or one week

That's what mine was set to.

Post by Paul
SpecialPollTimeRemaining Multi_SZ time.windows.com,0

Mine had a big number in place of zero. I'd assumed from the name that
it should go down if I refreshed, but it didn't.

Post by Paul
If you hammer time.windows.com too frequently, your IP will be blocked :-)
No, I do not know the threshold value for that.

I've tried setting it to once a day. (Though I'd have _hoped_ the
internal clock, however cheap, wouldn't have lost a minute in a week,
but we'll see.)

Post by Paul
Paul

Thanks.

[Brian Gregory]

Post by J. P. Gilliver
[]

Post by Paul
Meinberg leaks out first order time corrections, which is something W32time
does not do. It studies the numbers it is seeing, to work out how
far off your clock adjustment is, and it leaks out corrections maybe
every fifteen minutes. Windows does not bother to do that, so the
clock offset grows over the week of uncalibrated operation.
This is what a Windows 7 might show. Dial down the 604800 number.
  HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient
      SpecialPollInterval          DWORD32         0x93a80 604800
seconds or one week

That's what mine was set to.

Post by Paul
      SpecialPollTimeRemaining     Multi_SZ        time.windows.com,0

Mine had a big number in place of zero. I'd assumed from the name that
it should go down if I refreshed, but it didn't.

Post by Paul
If you hammer time.windows.com too frequently, your IP will be blocked :-)
No, I do not know the threshold value for that.

I've tried setting it to once a day. (Though I'd have _hoped_ the
internal clock, however cheap, wouldn't have lost a minute in a week,
but we'll see.)

Post by Paul
  Paul

Thanks.

If high time accuracy and reliability are important to you you should
switch off the built in time synchronisation and install Meinberg NTP
instead.

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

The built in one, especially as it was in Windows 7, is rubbish.

[J. P. Gilliver]

In message <***@mid.individual.net> at Mon, 18 Dec 2023
04:13:31, Brian Gregory <void-invalid-dead-***@email.invalid> writes
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP
instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

[Paul]

Post by J. P. Gilliver
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.

It waits all week, then makes one (huge) correction. BIG DEAL.

The Meinberg one is a real implementation.

I don't want to say anything more, because a Time Lord
might be listening :-)

And it's always possible, the Windows Server version
of w32time, is better than the desktop version. the reason
I say that, is the desktop w32time wakes up every fifteen minutes,
as if it is going to make a first order static offset correction
to the clock, but it goes right back to sleep without doing anything.
It suggests they gutted the code on purpose. Otherwise, why would
the desktop one, wake up every fifteen minutes ?

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-top

Paul

[J. P. Gilliver]

[]

Post by Paul

Post by J. P. Gilliver

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

[]
If that's what you consider its main bug, won't having changed that to a
shorter interval - albeit needing to do a registry adjust (as described
in this thread, rather than that being GUIable) - make it less rubbish?
(I've set it to 1/7 what it was, i. e. daily rather than weekly. No idea
if it's made any difference yet.)

[Paul]

[]

Post by Paul

Post by J. P. Gilliver

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

[]
If that's what you consider its main bug, won't having changed that to a shorter interval - albeit needing to do a registry adjust (as described in this thread, rather than that being GUIable) - make it less rubbish? (I've set it to 1/7 what it was, i. e. daily rather than weekly. No idea if it's made any difference yet.)

It's the "pretense" which is rubbish.

If you look at the log, you might be fooled into
thinking you were getting proper service. When
it doesn't seem to be working. It is making a
single point correction.

If you wanted to study what was happening to your
computer, all that you would need to do, is record all
GPS messages from a GPS, and apply a local timestamp
to each message. Post-processing that, would show the
"drift" or "sudden change" nature of your local clock.

Paul

[J. P. Gilliver]

[]

Post by Paul

Post by J. P. Gilliver

Post by Paul
It waits all week, then makes one (huge) correction. BIG DEAL.

[]
If that's what you consider its main bug, won't having changed that
to a shorter interval - albeit needing to do a registry adjust (as
described in this thread, rather than that being GUIable) - make it
less rubbish? (I've set it to 1/7 what it was, i. e. daily rather than
weekly. No idea if it's made any difference yet.)

It's the "pretense" which is rubbish.
If you look at the log, you might be fooled into
thinking you were getting proper service. When
it doesn't seem to be working. It is making a
single point correction.
If you wanted to study what was happening to your
computer, all that you would need to do, is record all
GPS messages from a GPS, and apply a local timestamp
to each message. Post-processing that, would show the
"drift" or "sudden change" nature of your local clock.
Paul

I don't have a GPS at the moment. But I'm fairly sure that my computer
is just steadily running a little slow - either genuinely slow, or due
to activities slowing it down.

[Brian Gregory]

Post by Paul

Post by J. P. Gilliver
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

AIUI Microsoft implemented SNTP rather than NTP.

There also seems to be a weird bug, (maybe it's because it's SNTP rather
than NTP) where it doesn't reliably talk to local NTP servers, so if you
have your own NTP server on your own local network (perhaps in your
router), then Windows 7 time sync fails with an error if you tell it to
use your local NTP server.

[Char Jackson]

On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory

Post by Brian Gregory

Post by Paul

Post by J. P. Gilliver
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

AIUI Microsoft implemented SNTP rather than NTP.
There also seems to be a weird bug, (maybe it's because it's SNTP rather
than NTP) where it doesn't reliably talk to local NTP servers, so if you
have your own NTP server on your own local network (perhaps in your
router), then Windows 7 time sync fails with an error if you tell it to
use your local NTP server.

I configured a Win 10 Pro VM to enable its built-in NTP server functionality.
This functionality is disabled by default. Then I switched over to a physical
Win 7 PC and configured it to use the new Win 10 NTP server. I also opened port
123 UDP on the Win 10 VM in order to allow the inbound NTP connections. Manual
sync from Win 7 worked fine, so I dropped the automatic sync interval down to 1
hour and waited. About an hour later, the automatic sync also worked just fine.

What else do I need to do to find the bug you mentioned?

[Brian Gregory]

Post by Char Jackson
On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory

Post by Brian Gregory

Post by Paul

Post by J. P. Gilliver
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

AIUI Microsoft implemented SNTP rather than NTP.
There also seems to be a weird bug, (maybe it's because it's SNTP rather
than NTP) where it doesn't reliably talk to local NTP servers, so if you
have your own NTP server on your own local network (perhaps in your
router), then Windows 7 time sync fails with an error if you tell it to
use your local NTP server.

I configured a Win 10 Pro VM to enable its built-in NTP server functionality.
This functionality is disabled by default. Then I switched over to a physical
Win 7 PC and configured it to use the new Win 10 NTP server. I also opened port
123 UDP on the Win 10 VM in order to allow the inbound NTP connections. Manual
sync from Win 7 worked fine, so I dropped the automatic sync interval down to 1
hour and waited. About an hour later, the automatic sync also worked just fine.
What else do I need to do to find the bug you mentioned?

I saw it with the NTP server running in my router, not with any
Microsoft NTP server.

[Char Jackson]

On Wed, 20 Dec 2023 03:00:26 +0000, Brian Gregory

Post by Brian Gregory

Post by Char Jackson
On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory

Post by Brian Gregory

Post by Paul

Post by J. P. Gilliver
[]

Post by Brian Gregory
If high time accuracy and reliability are important to you you should

Thanks - they aren't.

Post by Brian Gregory
switch off the built in time synchronisation and install Meinberg NTP instead.
https://www.meinbergglobal.com/english/sw/ntp.htm

Thanks - noted.

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

AIUI Microsoft implemented SNTP rather than NTP.
There also seems to be a weird bug, (maybe it's because it's SNTP rather
than NTP) where it doesn't reliably talk to local NTP servers, so if you
have your own NTP server on your own local network (perhaps in your
router), then Windows 7 time sync fails with an error if you tell it to
use your local NTP server.

I configured a Win 10 Pro VM to enable its built-in NTP server functionality.
This functionality is disabled by default. Then I switched over to a physical
Win 7 PC and configured it to use the new Win 10 NTP server. I also opened port
123 UDP on the Win 10 VM in order to allow the inbound NTP connections. Manual
sync from Win 7 worked fine, so I dropped the automatic sync interval down to 1
hour and waited. About an hour later, the automatic sync also worked just fine.
What else do I need to do to find the bug you mentioned?

I saw it with the NTP server running in my router, not with any
Microsoft NTP server.

Got it, so it was likely a problem with that particular router, versus a problem
with Win 7's NTP client. I'll go ahead and tear down the experiment.

[Brian Gregory]

Post by Char Jackson
Got it, so it was likely a problem with that particular router, versus a problem
with Win 7's NTP client. I'll go ahead and tear down the experiment.

It's NTPD running on Linux. There couldn't be anything more standard.

Everything else works with it. Probably 95%+ of NTP servers on the
Internet use it.

[Char Jackson]

On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory

Post by Brian Gregory

Post by Char Jackson
Got it, so it was likely a problem with that particular router, versus a problem
with Win 7's NTP client. I'll go ahead and tear down the experiment.

It's NTPD running on Linux. There couldn't be anything more standard.
Everything else works with it. Probably 95%+ of NTP servers on the
Internet use it.

In that case, I'm not convinced that there's a problem. If you think of a way to
recreate the issue, we can do some packet captures to see what's going on.

[KenW]

Try Neutron Time, works on Windows 11


KenW

[Brian Gregory]

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.

Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

[KenW]

On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.


KenW

[Brian Gregory]

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

[VanguardLH]

Post by Brian Gregory

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

NTP can use multiple servers to sync versus sNTP uses 1 server. How
accurate you think you need your workstation's time. It's not an NTP
server that coordinates with several others at the same strata.
Besides, if even a tenth of a second is critical to you, just schedule
the sNTP sync at shorter intervals, like once or a couple times per day.
Even more often if you run heavy-CPU processes that would make the OS
clock drift.

[Brian Gregory]

Post by VanguardLH

Post by Brian Gregory

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

NTP can use multiple servers to sync versus sNTP uses 1 server. How
accurate you think you need your workstation's time. It's not an NTP
server that coordinates with several others at the same strata.
Besides, if even a tenth of a second is critical to you, just schedule
the sNTP sync at shorter intervals, like once or a couple times per day.
Even more often if you run heavy-CPU processes that would make the OS
clock drift.

Or just install a proper NTP client.

[VanguardLH]

Post by Brian Gregory

Post by VanguardLH

Post by Brian Gregory

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

NTP can use multiple servers to sync versus sNTP uses 1 server. How
accurate you think you need your workstation's time. It's not an NTP
server that coordinates with several others at the same strata.
Besides, if even a tenth of a second is critical to you, just schedule
the sNTP sync at shorter intervals, like once or a couple times per day.
Even more often if you run heavy-CPU processes that would make the OS
clock drift.

Or just install a proper NTP client.

If you don't mind installing additional 3rd-party software when the same
functionality is already built-in.

I've seen meinberg touted as the "best" 3rd-party NTP sync tool. Why?

"On Windows platforms, NTP does not currently support most external
reference clocks directly. Instead, the Meinberg driver can be used
together with most internal and external Meinberg radio clocks to
discipline the Windows system time. The NTP service can then be used
to make the disciplined Windows system time available on the network."

Okay, but just what is "disciplined"? A vague term trying to qualify
using the meinberg driver instead of the Windows Time service. Plus
that help is geared toward running an NTP server, not as a workstation
getting time from an NTP server. On Windows, the time sync defaults to
a week interval (except also on login of workstations connecting to a
domain). Windows servers default to 100 (seconds), so they're getting
update 864 times per day.

I used Socketwatch for many years until I found out how to configure the
Windows Time service, and how to use the w32tm.exe program to force
updates in Task Schedule on logon events, at scheduled intervals (I
didn't need more than once per day), and every time the workstation got
unlocked (got out of screensaver mode).

I've seen other atomic clock sync software that claimed they used
algorithms to estimate how much to change the OS clock instead of having
to make a change in a huge chunk. Instead of changing for off by a
minute, or a lot more, they make an incremental change. Then on the
next sync, they check if off and if plus or minus, and adjust by a
varied increment again. Okay, but that still requires multiple time
syncs to statistically estimate how much the OS clock is drifting.
Multiple time syncs using Windows Time service also reduces the size of
the chunk for change. meinberg mentions drift, but, again, just shorten
the sync intervals so the delta change for time is tiny instead of
guessing by how much it should be change on each sync over many syncs.
If the OS clock is drifting by 1 msec, or less, on each time sync, why
do you care about such a miniscule offset on your workstation?
Socketwatch would report how much drift was compensated in a time sync,
but it was always tiny. However, I was probably running Socketwatch's
sync operation once, or more, per day, not once a week, or once a month,
or once a year. The reported drift was so tiny, and always tiny, that I
saw no need for Socketwatch anymore, and simply has the Windows Time
service do shorter syncs. No additional software required.

When looking at the meinberg knowledge articles, those are geared to
running an NTP *server*, not for NTP sync clients on workstations. On
*workstations*, what is so stupendously better about meinberg?

As Paul states, meinberg calculates drift to compensate incrementally.
That's because it syncs every 15 minutes. Well, if you use w32tm to do
a time sync every 15 minutes, just how much drifte will you experience?
Yeah, diddly. Besides the default NTP update triggers, I already
mentioned how you can use multiple events in a scheduled task in Task
Scheduler to do syncs at much shorter intervals, too.

I don't need enterprise-grade NTP server software since I'm not running
an NTP server in my network nor is it synchronizing across multiple NTP
servers at the same strata. I only need an NTP sync client for my
workstation. This is the same scenario for everyone here: NTP sync on a
workstation. Of course, these same workstations that are getting
powered off aren't doing any time syncs while off, so the workstations
have to rely on their RTC logic to maintain a hardware clock.

Compensating incrementally for drift is not a unique feature only to the
meinberg NTP client. Lots of other 3rd-party NTP clients do it, too.
But if the Windows Time service were to perform much shorter intervals
for time syncs, drift is a non-issue.

[Paul]

Post by VanguardLH

Post by Brian Gregory

Post by VanguardLH

Post by Brian Gregory

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

NTP can use multiple servers to sync versus sNTP uses 1 server. How
accurate you think you need your workstation's time. It's not an NTP
server that coordinates with several others at the same strata.
Besides, if even a tenth of a second is critical to you, just schedule
the sNTP sync at shorter intervals, like once or a couple times per day.
Even more often if you run heavy-CPU processes that would make the OS
clock drift.

Or just install a proper NTP client.

If you don't mind installing additional 3rd-party software when the same
functionality is already built-in.
I've seen meinberg touted as the "best" 3rd-party NTP sync tool. Why?
"On Windows platforms, NTP does not currently support most external
reference clocks directly. Instead, the Meinberg driver can be used
together with most internal and external Meinberg radio clocks to
discipline the Windows system time. The NTP service can then be used
to make the disciplined Windows system time available on the network."
Okay, but just what is "disciplined"? A vague term trying to qualify
using the meinberg driver instead of the Windows Time service. Plus
that help is geared toward running an NTP server, not as a workstation
getting time from an NTP server. On Windows, the time sync defaults to
a week interval (except also on login of workstations connecting to a
domain). Windows servers default to 100 (seconds), so they're getting
update 864 times per day.
I used Socketwatch for many years until I found out how to configure the
Windows Time service, and how to use the w32tm.exe program to force
updates in Task Schedule on logon events, at scheduled intervals (I
didn't need more than once per day), and every time the workstation got
unlocked (got out of screensaver mode).
I've seen other atomic clock sync software that claimed they used
algorithms to estimate how much to change the OS clock instead of having
to make a change in a huge chunk. Instead of changing for off by a
minute, or a lot more, they make an incremental change. Then on the
next sync, they check if off and if plus or minus, and adjust by a
varied increment again. Okay, but that still requires multiple time
syncs to statistically estimate how much the OS clock is drifting.
Multiple time syncs using Windows Time service also reduces the size of
the chunk for change. meinberg mentions drift, but, again, just shorten
the sync intervals so the delta change for time is tiny instead of
guessing by how much it should be change on each sync over many syncs.
If the OS clock is drifting by 1 msec, or less, on each time sync, why
do you care about such a miniscule offset on your workstation?
Socketwatch would report how much drift was compensated in a time sync,
but it was always tiny. However, I was probably running Socketwatch's
sync operation once, or more, per day, not once a week, or once a month,
or once a year. The reported drift was so tiny, and always tiny, that I
saw no need for Socketwatch anymore, and simply has the Windows Time
service do shorter syncs. No additional software required.
When looking at the meinberg knowledge articles, those are geared to
running an NTP *server*, not for NTP sync clients on workstations. On
*workstations*, what is so stupendously better about meinberg?
As Paul states, meinberg calculates drift to compensate incrementally.
That's because it syncs every 15 minutes. Well, if you use w32tm to do
a time sync every 15 minutes, just how much drifte will you experience?
Yeah, diddly. Besides the default NTP update triggers, I already
mentioned how you can use multiple events in a scheduled task in Task
Scheduler to do syncs at much shorter intervals, too.
I don't need enterprise-grade NTP server software since I'm not running
an NTP server in my network nor is it synchronizing across multiple NTP
servers at the same strata. I only need an NTP sync client for my
workstation. This is the same scenario for everyone here: NTP sync on a
workstation. Of course, these same workstations that are getting
powered off aren't doing any time syncs while off, so the workstations
have to rely on their RTC logic to maintain a hardware clock.
Compensating incrementally for drift is not a unique feature only to the
meinberg NTP client. Lots of other 3rd-party NTP clients do it, too.
But if the Windows Time service were to perform much shorter intervals
for time syncs, drift is a non-issue.

Normal timekeeping, means to carry out NTP network time protocol and
get the timestamp. That is undisciplined, because it only uses
NTP protocol, with all of its issues. The time sources should have
a stratum rating. The reason for having multiple NTP sources, is
because maintenance mistakes are made.

Disciplined means, to use an alternate source, a digital clock device
such as a GPS, instead of using a network protocol. It would look
like this.

NTP_source#1 ---------------- \ Meinberg.
NTP_source#2 ---------------- \
NTP_source#3 ---------------- \___ Note the stratum. Measure the drift.
/ Eject outliers. Compute the composite time.
GPS_constellation ----------- / Measure static offset error of System Clock.
Dribble out System Clock corrections every 15 minutes.

Just a guess on my part.

We had a device in the lab, a Cesium beam, with GPS disciplining,
and it looked like this. I think there is Cesium and Rubidium
for such things. The GPS antenna was up on the office building roof.

Cesium oscillator ----\
\____ Local atomic clock --------> 10.00000000 MHz coax reference
GPS_constellation ---- / to lab instruments (frequency counter)

And as a bonus, it had a bank of digits on the front
of the device, with local time displayed. So you could
set your watch :-)

While that instrument was purchased, we also built time pieces of
our own at work. And we had a few Time Lords. And a Time Lord In Training
(green as grass). If you were to lose the GPS, in the middle of a
two day long wander measurement, you would likely have to start over
again if the output was for publication. The Cesium reference would
be perfectly good for a lot of purposes, on its own, but sometimes,
you really want it traceable to GPS. Because you're tapping into
a constellation of atomic clocks.

Paul

[VanguardLH]

Post by Paul

Post by VanguardLH

Post by Brian Gregory

Post by VanguardLH

Post by Brian Gregory

Post by KenW
On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory

Post by Brian Gregory

Post by KenW
Try Neutron Time, works on Windows 11

Over ten years since it was last updated, uses ancient obsolete long
superseded protocol rather than NTP. No thanks.
Use Meinberg NTP. https://www.meinbergglobal.com/english/sw/ntp.htm

Time is time no matter how it is done.

I'm not saying being Less accurate and less reliable means it's not time.

NTP can use multiple servers to sync versus sNTP uses 1 server. How
accurate you think you need your workstation's time. It's not an NTP
server that coordinates with several others at the same strata.
Besides, if even a tenth of a second is critical to you, just schedule
the sNTP sync at shorter intervals, like once or a couple times per day.
Even more often if you run heavy-CPU processes that would make the OS
clock drift.

Or just install a proper NTP client.

If you don't mind installing additional 3rd-party software when the same
functionality is already built-in.
I've seen meinberg touted as the "best" 3rd-party NTP sync tool. Why?
"On Windows platforms, NTP does not currently support most external
reference clocks directly. Instead, the Meinberg driver can be used
together with most internal and external Meinberg radio clocks to
discipline the Windows system time. The NTP service can then be used
to make the disciplined Windows system time available on the network."
Okay, but just what is "disciplined"? A vague term trying to qualify
using the meinberg driver instead of the Windows Time service. Plus
that help is geared toward running an NTP server, not as a workstation
getting time from an NTP server. On Windows, the time sync defaults to
a week interval (except also on login of workstations connecting to a
domain). Windows servers default to 100 (seconds), so they're getting
update 864 times per day.
I used Socketwatch for many years until I found out how to configure the
Windows Time service, and how to use the w32tm.exe program to force
updates in Task Schedule on logon events, at scheduled intervals (I
didn't need more than once per day), and every time the workstation got
unlocked (got out of screensaver mode).
I've seen other atomic clock sync software that claimed they used
algorithms to estimate how much to change the OS clock instead of having
to make a change in a huge chunk. Instead of changing for off by a
minute, or a lot more, they make an incremental change. Then on the
next sync, they check if off and if plus or minus, and adjust by a
varied increment again. Okay, but that still requires multiple time
syncs to statistically estimate how much the OS clock is drifting.
Multiple time syncs using Windows Time service also reduces the size of
the chunk for change. meinberg mentions drift, but, again, just shorten
the sync intervals so the delta change for time is tiny instead of
guessing by how much it should be change on each sync over many syncs.
If the OS clock is drifting by 1 msec, or less, on each time sync, why
do you care about such a miniscule offset on your workstation?
Socketwatch would report how much drift was compensated in a time sync,
but it was always tiny. However, I was probably running Socketwatch's
sync operation once, or more, per day, not once a week, or once a month,
or once a year. The reported drift was so tiny, and always tiny, that I
saw no need for Socketwatch anymore, and simply has the Windows Time
service do shorter syncs. No additional software required.
When looking at the meinberg knowledge articles, those are geared to
running an NTP *server*, not for NTP sync clients on workstations. On
*workstations*, what is so stupendously better about meinberg?
As Paul states, meinberg calculates drift to compensate incrementally.
That's because it syncs every 15 minutes. Well, if you use w32tm to do
a time sync every 15 minutes, just how much drifte will you experience?
Yeah, diddly. Besides the default NTP update triggers, I already
mentioned how you can use multiple events in a scheduled task in Task
Scheduler to do syncs at much shorter intervals, too.
I don't need enterprise-grade NTP server software since I'm not running
an NTP server in my network nor is it synchronizing across multiple NTP
servers at the same strata. I only need an NTP sync client for my
workstation. This is the same scenario for everyone here: NTP sync on a
workstation. Of course, these same workstations that are getting
powered off aren't doing any time syncs while off, so the workstations
have to rely on their RTC logic to maintain a hardware clock.
Compensating incrementally for drift is not a unique feature only to the
meinberg NTP client. Lots of other 3rd-party NTP clients do it, too.
But if the Windows Time service were to perform much shorter intervals
for time syncs, drift is a non-issue.

Normal timekeeping, means to carry out NTP network time protocol and
get the timestamp. That is undisciplined, because it only uses
NTP protocol, with all of its issues. The time sources should have
a stratum rating. The reason for having multiple NTP sources, is
because maintenance mistakes are made.
Disciplined means, to use an alternate source, a digital clock device
such as a GPS, instead of using a network protocol. It would look
like this.
NTP_source#1 ---------------- \ Meinberg.
NTP_source#2 ---------------- \
NTP_source#3 ---------------- \___ Note the stratum. Measure the drift.
/ Eject outliers. Compute the composite time.
GPS_constellation ----------- / Measure static offset error of System Clock.
Dribble out System Clock corrections every 15 minutes.
Just a guess on my part.
We had a device in the lab, a Cesium beam, with GPS disciplining,
and it looked like this. I think there is Cesium and Rubidium
for such things. The GPS antenna was up on the office building roof.
Cesium oscillator ----\
\____ Local atomic clock --------> 10.00000000 MHz coax reference
GPS_constellation ---- / to lab instruments (frequency counter)
And as a bonus, it had a bank of digits on the front
of the device, with local time displayed. So you could
set your watch :-)
While that instrument was purchased, we also built time pieces of
our own at work. And we had a few Time Lords. And a Time Lord In Training
(green as grass). If you were to lose the GPS, in the middle of a
two day long wander measurement, you would likely have to start over
again if the output was for publication. The Cesium reference would
be perfectly good for a lot of purposes, on its own, but sometimes,
you really want it traceable to GPS. Because you're tapping into
a constellation of atomic clocks.
Paul

For their workstation client and driver, where is a GPS source
mentioned? Best I can find is that a separate board is needed to
interface from computer to radio, like mentioned at:

http://www.satsignal.eu/ntp/setup.html

"For even better timekeeping, and for a rather low extra cost (US $35,
Ł25), you can _lock that local time server to GPS_, making it far more
precise than one locked to Internet sources. You might like to use
something like a Raspberry Pi as a low-cost, stand-alone, precision
time server."

where the "lock that local time server to GPS" points to:

http://www.satsignal.eu/ntp/Sure-GPS.htm

They have server-grade NTP software, and GPS could be incorporated, but
on a Windows *workstation*? No, now we're talking about something
outside of the Windows desktop, laptop, netbook, or other Windows
devices.

Notice even the text above says NTP /server/. When did this discussion
move to managing a Windows Server platform versus a Windows workstation
(Windows 7)? I don't see Gilliver wants to run an NTP /server/, just an
NTP client on a Windows workstation. I see no mention Gilliver is
interested in buying or building a GPS receiver and mounting an antenna.

That GPS is possible to incorporate in the time keeping, it's not a
viable feature for a workstation. When have you visited someone's home
where their desktop PC is attached to a GPS receiver? How many laptops
have you seen out and about lugging along a GPS receiver?

I could manage to tote 6 full-size spare tires: 4 in the cargo area, and
2 on the roof rack. But it's not a viable solution to ensuring you
always have a spare no matter how many concurrent or near-coincident
flats you get. At most there is 1 full-size tire in the car, or one of
those crappy emergency tires.

For a workstation (desktop PC), laptop, or other Windows non-server
platform, adding a GPS receiver and antenna is not a viable solution. I
could be wrong, and Gilliver really does want to add GPS-based time sync
along with adding a GPS receiver and antenna wherever is his computer.
Nah, I doubt it.

Just what about a desktop PC, laptop, or workstation requires use of GPS
to keep time within three nanoseconds (three-billionths of a second)?
Will the OS clock in Windows even go down that small in granularity?

https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/support-boundary-high-accuracy-time

1 millisecond is 333,333 times the granularity that GPS provides. You
can't set the OS clock down to the granularity of GPS. GPS sync is
worthless on workstations. The RTC crystal is accurate to 30.5
microseconds, for which GPS sync is still excessive, but we're talking
about synchronizing the OS clock, not the hardware clock.

If, and when, does the OS modify the time in the RTC logic (aka BIOS
clock)? From a forum post:

when using AD time sync the RTC will be updated each time a machine is
updated or updates itself from the AD time, same for direct NTP too.

I don't think Gilliver is in a domain. Other than Windows reading RTC
on startup to get its time value, does Windows write values to the RTC
hardware clock? From:

https://en.wikipedia.org/wiki/BIOS_interrupt_call#Interrupt_table

Looks like interrupt 1A was used with BIOS to write to RTC. I don't
know what UEFI might use. So Windows can update RTC, but the crystal in
a workstation still isn't going to support the resolution of using GPS.
Plus, I don't see GPS sync is available in their workstation client.
That's for their NTP server solution.

[J. P. Gilliver]

In message <***@v.nguard.lh> at Sat, 23 Dec 2023 02:24:12,
VanguardLH <***@nguard.LH> writes
[]

Post by VanguardLH
Notice even the text above says NTP /server/. When did this discussion
move to managing a Windows Server platform versus a Windows workstation
(Windows 7)? I don't see Gilliver wants to run an NTP /server/, just an
NTP client on a Windows workstation. I see no mention Gilliver is
interested in buying or building a GPS receiver and mounting an antenna.

[]

Post by VanguardLH
I don't think Gilliver is in a domain. Other than Windows reading RTC
on startup to get its time value, does Windows write values to the RTC

[]
(My name's John by the way.) I certainly didn't/don't want a precision
time reference! I was just wondering why my system had drifted off by
nearly a minute. This was just _probably_ because the built-in system
was only adjusting once a week as is the default, and I was doing the
odd thing (playing videos, extracting audio therefrom, doing the odd
backup) that was causing the software clock to lag. (On a previous
occasion, I'd discovered that my communications suite, Turnpike -
development stopped 2007, but I suspect that part of it dated from
Windows 3.1 days - was no longer adjusting the system clock, although it
thought it was, unless started with admin privileges. I suspect it
stopped having that access by default at the switch from XP to 7. But
that's a different matter.)

I have no (that I can think of) requirement that my clock is correct
even by a minute; it's just intellectually satisfying to have it more or
less to the nearest second - which I suspect having amended the interval
(as someone showed how, i. e. where it is in the registry, in this
thread) to daily has provided.

However, I've stood back from the discussion, as it took on a life of
its own, and was interesting.

Short of having a local source - e. g. a Caesium clock (!) or a GPS
receiver - I can't see that you can use time servers to an accuracy of
much more than the ping time anyway; even if you try to take account of
the request/response time and halve it, you're assuming each half took
the same time, which I suspect isn't a valid assumption, especially for
busy servers.

I also suspect that trying to maintain - or at least access to - a
reference to much less than a millisecond - if not several - is pretty
pointless in an OS such as Windows (any version) anyway.

[Paul]

I also suspect that trying to maintain - or at least access to - a reference to much less than a millisecond - if not several - is pretty pointless in an OS such as Windows (any version) anyway.

While testing it, it certainly seems that way.

Timekeeping seems rubbish from end to end.

I don't know if anyone has noticed, but if you use
the free version of HDTune, and run the benchmark,
it is reporting the wrong disk speed.

[Picture]

Loading Image...

Paul

[Paul]

Post by VanguardLH
For their workstation client and driver, where is a GPS source
mentioned? Best I can find is that a separate board is needed to
http://www.satsignal.eu/ntp/setup.html
"For even better timekeeping, and for a rather low extra cost (US $35,
Ł25), you can _lock that local time server to GPS_, making it far more
precise than one locked to Internet sources. You might like to use
something like a Raspberry Pi as a low-cost, stand-alone, precision
time server."
http://www.satsignal.eu/ntp/Sure-GPS.htm
They have server-grade NTP software, and GPS could be incorporated, but
on a Windows *workstation*? No, now we're talking about something
outside of the Windows desktop, laptop, netbook, or other Windows
devices.
Notice even the text above says NTP /server/. When did this discussion
move to managing a Windows Server platform versus a Windows workstation
(Windows 7)? I don't see Gilliver wants to run an NTP /server/, just an
NTP client on a Windows workstation. I see no mention Gilliver is
interested in buying or building a GPS receiver and mounting an antenna.
That GPS is possible to incorporate in the time keeping, it's not a
viable feature for a workstation. When have you visited someone's home
where their desktop PC is attached to a GPS receiver? How many laptops
have you seen out and about lugging along a GPS receiver?
I could manage to tote 6 full-size spare tires: 4 in the cargo area, and
2 on the roof rack. But it's not a viable solution to ensuring you
always have a spare no matter how many concurrent or near-coincident
flats you get. At most there is 1 full-size tire in the car, or one of
those crappy emergency tires.
For a workstation (desktop PC), laptop, or other Windows non-server
platform, adding a GPS receiver and antenna is not a viable solution. I
could be wrong, and Gilliver really does want to add GPS-based time sync
along with adding a GPS receiver and antenna wherever is his computer.
Nah, I doubt it.
Just what about a desktop PC, laptop, or workstation requires use of GPS
to keep time within three nanoseconds (three-billionths of a second)?
Will the OS clock in Windows even go down that small in granularity?
https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/support-boundary-high-accuracy-time
1 millisecond is 333,333 times the granularity that GPS provides. You
can't set the OS clock down to the granularity of GPS. GPS sync is
worthless on workstations. The RTC crystal is accurate to 30.5
microseconds, for which GPS sync is still excessive, but we're talking
about synchronizing the OS clock, not the hardware clock.
If, and when, does the OS modify the time in the RTC logic (aka BIOS
when using AD time sync the RTC will be updated each time a machine is
updated or updates itself from the AD time, same for direct NTP too.
I don't think Gilliver is in a domain. Other than Windows reading RTC
on startup to get its time value, does Windows write values to the RTC
https://en.wikipedia.org/wiki/BIOS_interrupt_call#Interrupt_table
Looks like interrupt 1A was used with BIOS to write to RTC. I don't
know what UEFI might use. So Windows can update RTC, but the crystal in
a workstation still isn't going to support the resolution of using GPS.
Plus, I don't see GPS sync is available in their workstation client.
That's for their NTP server solution.

We could easily make a mistake here. You have to be a Time Lord
to get this stuff right.

*******

LAPIC is abbreviation for Local Advanced Programmable Interrupt Controller APIC timer

TSC is abbreviation for Time Stamp Counter - https://en.wikipedia.org/wiki/Time_Stamp_Counter

QPC is abbreviation for QueryPerformanceCounter API.
This function can use LAPIC, TSC and also HPET (High Precision Event Timer) timers.
Developers can use this function to estimate a time span between two measures (calls).

Timer resolution means system timer resolution [ kernel ticks? could be in the millisecond range? ]

*******

That means there isn't necessarily, one monolithic 64 bit register in hardware
somewhere, that does everything. The machine has the ability to measure intervals
down in the nanoseconds, with at least one of the free running counters. Maybe
even two of them.

*******

It turns out, there is a routine called getsystemtimepreciseasfiletime(). Which is 100ns.
To do that, it would take a combination of the register for the system time,
plus fiddling around with the RDTSC-type stuff.

I was seeing whether I could set up some demo code with that, to make
some observations, and I found this.

This has a discussion about some of the time functions. It also has sample code
for using getsystemtimepreciseasfiletime(). And that's a clock function with a
100ns resolution (which is likely wasted on Windows, when you read the other comments).

https://stackoverflow.com/questions/34557407/queryperformancecounter-or-getsystemtimepreciseasfiletime-when-using-sntp

"GetSystemTimePreciseAsFileTime: high resolution measurement of "now"

good for log files
timestamping of events
synchronized to UTC for cross-machine agreement of "now"
"

One of the reasons this might have been added rather recently, is
because now there are machines with TSC_invariant (my new machine
has that property, and I expect most new machines would). And that
means there is a better chance of combining low res and high res
timekeeping, to make better routines like that one.

I've been doing experiments with timekeeping in Windows and Linux,
just recently, and everything I touched was broken (some results off
by 10%). This topic does not generally inspire confidence.

Just as (a point of reference), HDTune free version does not report
correct transfer speeds on the latest OSes. So it's affected too.

Paul

[Brian Gregory]

Post by VanguardLH
I've seen meinberg touted as the "best" 3rd-party NTP sync tool. Why?

It's a full implementation of NTP, as complete as any on UNIX or Linux.

Post by VanguardLH
Okay, but just what is "disciplined"?

AIUI it "observes" how much the internal clock drifts and effectively
tweaks it so that it runs as near as possible to the correct speed.

Post by VanguardLH
using the meinberg driver instead of the Windows Time service.

In a sense it's always a server, just only to Windows and Windows software.

Post by VanguardLH
Compensating incrementally for drift is not a unique feature only to the
meinberg NTP client. Lots of other 3rd-party NTP clients do it, too.

You're not implementing NTP properly unless you do, and do it as defined
in the reference implementation.

https://en.wikipedia.org/wiki/Network_Time_Protocol

[Brian Gregory]

Post by Char Jackson
On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory

Post by Brian Gregory

Post by Char Jackson
Got it, so it was likely a problem with that particular router, versus a problem
with Win 7's NTP client. I'll go ahead and tear down the experiment.

It's NTPD running on Linux. There couldn't be anything more standard.
Everything else works with it. Probably 95%+ of NTP servers on the
Internet use it.

In that case, I'm not convinced that there's a problem. If you think of a way to
recreate the issue, we can do some packet captures to see what's going on.

I suppose I might be remembering how it was in Windows XP.

[Char Jackson]

On Sat, 23 Dec 2023 21:23:34 +0000, Brian Gregory

Post by Brian Gregory

Post by Char Jackson
On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory

Post by Brian Gregory

Post by Char Jackson
Got it, so it was likely a problem with that particular router, versus a problem
with Win 7's NTP client. I'll go ahead and tear down the experiment.

It's NTPD running on Linux. There couldn't be anything more standard.
Everything else works with it. Probably 95%+ of NTP servers on the
Internet use it.

In that case, I'm not convinced that there's a problem. If you think of a way to
recreate the issue, we can do some packet captures to see what's going on.

I suppose I might be remembering how it was in Windows XP.

I pointed an XP VM to that same Win 10 NTP server and manual sync worked fine.
I'll keep an eye on it, checking back later to see if the auto sync worked or
failed.

I expect it to work, so trying to think ahead, I wonder if you were running into
a firewall issue, or something else not directly related to NTP.

[NY]

Post by Paul

Post by J. P. Gilliver

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

Surely that is simply a matter of how often it polls the NTP server. The
Windows default is 1 week, which IMO is far too long, given the fact that
most PC real-time clocks can drift by a couple of minutes in that time. But
you can reduce the polling interval to (for example) 1 day by changing the
registry key that people have already mentioned, which means that the clock
does not drift as far before it gets kicked back into sync. I did that on
one of my Win 7 PCs whose clock was spectacularly bad. Could it be that the
polling interval for Meinberg is shorter, rather than that the coding of
Meinberg is inherently better, irrespective of polling interval?

Interesting to see how RTC hardware varies from one PC to another. The Win 7
laptop which I powered-on every day was often a couple of minutes wrong -
usually slow but sometimes fast. But I have a PC which runs Linux (Ubuntu,
Cinnamon Mint, MX, depending on which HDD I plug into it) and I often don't
turn that on for a month or so (ie it's disconnected from the mains, so no
trickle power when not booted) and yet its RTC is spot-on when checked with
the time.is website. At first I thought that Linux checked NTP at boot time
and therefore was always correct by the time the PC was booted, so I
disconnected the LAN to spoil its little game, and the clock was still
accurate to /- 5 seconds after a month or so of no power.

I don't think the poor time-keeping of the Win 7 laptop was due to a low
CMOS battery, because in my experience that usually results in the time
being completely wrong and utterly random, rather than being nearly correct
but losing/gaining a few minutes per week.

I never understood why CMOS batteries are always non-rechargeable, and
motherboards were not designed to accept a rechargeable battery which was
topped up whenever the PC was turned on. That would avoid the occasional
flat battery which means the clock needs to be reset and (on older PCs)
maybe boot-device sequence etc may need to be corrected.

[VanguardLH]

Post by NY
I never understood why CMOS batteries are always non-rechargeable, and
motherboards were not designed to accept a rechargeable battery which was
topped up whenever the PC was turned on. That would avoid the occasional
flat battery which means the clock needs to be reset and (on older PCs)
maybe boot-device sequence etc may need to be corrected.

The CMOS battery doesn't need to be rechargeable. Your rechargeable
batteries wane in capacity (coloumbs) over time, so eventually have to
be replaced. Your smartphone, laptop, car, and other rechargeable
batteries eventually don't charge, or charge enough, to be usable.
Batteries are chemical. Being rechargeable doesn't make them eternal.
By the time a rechargeable CMOS battery would need to be replaced is
when the non-rechargeable CMOS battery would need replacement: 5 years.

When a computer is connected to line power (always for a desktop PC,
often for a laptop) there is the 5-volt standby output from the PSU to
the mobo with a fork to supply 3 VDC to the RTC. I'm not talking about
when you power up the computer. I'm talking about whenever the computer
is connected to a live A/C power source, like a wall outlet. Whether
the computer is powered on fully or when powered off, the PSU still
provides the 5 VSB standby line to the mobo as long as the PSU is
connected to an A/C power source. There is little drain on the CMOS
battery when the computer is unconnected to power, and none when the
when the computer is connected to power. This has been by design ever
since ATX PSUs showed up over 2 decades ago.

https://en.wikipedia.org/wiki/ATX

For example, with the old AT-style PSUs, the Power switch on the case
directly disconnected power from power source. The line power was cut.
With ATX-style PSUs, the PSU is still generating 5 VSB as long as the
computer was connected to a live power source, and the Power switch on
the case went to logic on the motherboard to turn on/off the PSU. The
mobo logic required power to operate hence the need for 5 VSB.

When unconnected from a power source, the CMOS battery has extremely
little drain to maintain the CMOS copy of the BIOS settings (which are
copied from EEPROM). It also supplies power to the RTC chip. Hard to
say how much is the drain, because it depends on the mobo design.
Typically it's in the microamperes range (6 to 10 uA) for the RTC, and
miniscule for maintaining state of the CMOS table. With a 1.2 Ah rating
of a CMOS coin cell battery, life expectancy is 22 years (at 20 C).
While reasonable maintainence of the CMOS battery has it replaced at 10
year intervals, 5 years is a better replacement interval as some mobos
use more power, and chemical composition of the electrolyte may not be
the most ideal, so capacity wanes earlier (and the capacity drop is
faster than linear). For serviceable applications, 5 years is
recommended. There are applications where 10 years is used, but often
the battery is not replaceable, and the product is expected to be
non-functional by then, like for home CO monitors.

While the coin cells are lithium based (e.g., lithium thionyl chloride),
it wouldn't help to be rechargeable, because their chemistry won't
outlive a non-rechargeable design. The common coin cells are lithium
manganese dioxide rated for 225 mAh. Even with a 10 uA draw, that's 4
years to sustain the CMOS table and RTC chip assuming the computer were
unconnected from a power source the entire time. If a product is
expected to be continuously unpowered but its usability is longer than
the chemistry of the battery allows, is when you see access panels
allowing replacement of the battery. Laptops are considered ancient and
long unsupported for the 5-year recommended battery replacement
interval, and why there is no access panel in the case (and the battery
may not be on the bottom accessible from that bottom side of the case,
but be on the top of the mobo which requires disassembling the case, or
at least removing the keyboard).

Batteries are chemical. They die. How long before you have to replace
that rechargeable battery in your car? Being rechargeable does not make
them eternal, or even longer lasting depending on application. If draw
is miniscule, lifespan is long, and chemistry will fail whether
rechargeable or not.

So, even when you think you have powered off the computer, and as long
as the computer is connected to a power source (e.g., live wall outlet),
the PSU generates 5 VSB to the mobo. Look at the pinout of the PSU
connector to the mobo header. Pin 9 is 5 VSB.

Loading Image...

Only when the computer is not connected to power (regardless if the
computer is powered up or down) is the CMOS battery needed.

[J. P. Gilliver]

Post by VanguardLH

Post by NY
I never understood why CMOS batteries are always non-rechargeable, and
motherboards were not designed to accept a rechargeable battery which was
topped up whenever the PC was turned on. That would avoid the occasional
flat battery which means the clock needs to be reset and (on older PCs)
maybe boot-device sequence etc may need to be corrected.

There is a - tiny, but it has been known - risk of explosion or at least
overheating of a battery (or cell) under continuous charge. The only
case I actually know of was those in the BBC Master Microcomputer, where
early models had a rechargeable battery (well before the modern
cellphone type - I think they might even have been NiCd!); only a few,
but sufficient of them _did_ overheat (melting some plastic) that the
design was changed to three ordinary (Duracell I think) AAs in a
shrink-wrap. (I can't remember what those powered - RTC _only_ I think.
[We're talking well before PCs here.])

There's also always the _suspicion_ of designed-in obsolescence, though
where the (usually CR2032) coin cell is used in a holder, that's
probably not really the case.

Post by VanguardLH
The CMOS battery doesn't need to be rechargeable. Your rechargeable
batteries wane in capacity (coloumbs) over time, so eventually have to
be replaced. Your smartphone, laptop, car, and other rechargeable
batteries eventually don't charge, or charge enough, to be usable.
Batteries are chemical. Being rechargeable doesn't make them eternal.
By the time a rechargeable CMOS battery would need to be replaced is
when the non-rechargeable CMOS battery would need replacement: 5 years.

An interesting hypothesis. Certainly, few cell manufacturers will offer
a _guarantee_ longer than 5 years, usually a lot less; though some _do_
last longer. (I think I've had my car about that long, and don't know if
the battery was fairly new when I got it; but when I had it checked
recently - at a branch of a chain who would have sold me a new one, so
had incentive to diss it - they said it was fine.)

Post by VanguardLH
When a computer is connected to line power (always for a desktop PC,
often for a laptop) there is the 5-volt standby output from the PSU to
the mobo with a fork to supply 3 VDC to the RTC. I'm not talking about

[]

Post by VanguardLH
When unconnected from a power source, the CMOS battery has extremely
little drain to maintain the CMOS copy of the BIOS settings (which are
copied from EEPROM). It also supplies power to the RTC chip. Hard to

Yes, I think retaining the settings requires near unmeasurable current;
the RTC is similar to an ordinary wristwatch - somewhat less in that it
doesn't need to power a display, though perhaps having to monitor
whether it's being interrogated may take some of that saving.

Post by VanguardLH
say how much is the drain, because it depends on the mobo design.
Typically it's in the microamperes range (6 to 10 uA) for the RTC, and
miniscule for maintaining state of the CMOS table. With a 1.2 Ah rating
of a CMOS coin cell battery, life expectancy is 22 years (at 20 C).

[]

Post by VanguardLH
recommended. There are applications where 10 years is used, but often
the battery is not replaceable, and the product is expected to be
non-functional by then, like for home CO monitors.

Though you _can_ get CO monitors that take conventional (or
rechargeable) cells. (Mine takes three AA.)

Post by VanguardLH
While the coin cells are lithium based (e.g., lithium thionyl chloride),
it wouldn't help to be rechargeable, because their chemistry won't
outlive a non-rechargeable design. The common coin cells are lithium
manganese dioxide rated for 225 mAh. Even with a 10 uA draw, that's 4

1.2 Ah (as above) or 225 mAh?
[]

Post by VanguardLH
allowing replacement of the battery. Laptops are considered ancient and
long unsupported for the 5-year recommended battery replacement

True about the "considered"; in practice, I think the ones I've owned
and used - including this one - have always been 3 or more years old,
and often gone on for much longer than that.
[]

Post by VanguardLH
Only when the computer is not connected to power (regardless if the
computer is powered up or down) is the CMOS battery needed.

Indeed. NY's question was a valid one to be asked, though. I think the
answer is some combination of the overheating concern (minuscule), your
point about them sometimes not lasting longer than non-rechargeable (at
least few want to _guarantee_ that thought they often _do_ last long in
practice), and, yes, _some_ element of "built-in obsolescence" (at the
very least, unwillingness to design in a recharge circuit when not doing
so is cheaper).

[VanguardLH]

Post by J. P. Gilliver
There is a - tiny, but it has been known - risk of explosion or at least
overheating of a battery (or cell) under continuous charge.

Lithiums can ignite on overcharging. Laptop, and other lithium
batteries have built-in protection. Coin cells do not.

Post by J. P. Gilliver
There's also always the _suspicion_ of designed-in obsolescence, though
where the (usually CR2032) coin cell is used in a holder, that's
probably not really the case.

The problem is with access. Desktop mobos are easy to replace coin cell
batteries. Remotes, hearing aids, and other devices using button
batteries have access to replace them. Alas, laptops don't add an
access panel you can remove on the bottom side of the case, plus the
battery is on the other side (top) of the mobo which requires
dismantling the case enough to remove the keyboard.

Post by J. P. Gilliver
Certainly, few cell manufacturers will offer a _guarantee_ longer than
5 years, usually a lot less; though some _do_ last longer.

The common coins cells are the cheaper lithium manganese, but there are
lithium thionyl coid cells that have longer shelf time. As for how long
they last depends on drain, and mobos vary how much they pull from the
coin cell battery. From what I've read, it's usually 6 to 10 uA. Plus
you don't want to rely on the last half of the lifespan for a battery
since that is when it has reduced capacity.

Post by J. P. Gilliver
Though you _can_ get CO monitors that take conventional (or
rechargeable) cells. (Mine takes three AA.)

But the CO sensor degrades, so often those have a 10-year battery. Even
with replaceable batteries, read the instructions which probably say to
replace the entire unit after 10 years. Most recommendations from
installers is to replace the CO detector at 5 to 7 years. Kidde, in
accordance with the National Fire Protection Association, says to
replace at 7 to 10 years depending on model. Mine say 10 years.
Temperature and humidity will reduce the lifespan of when the CO
detector can accurately "small" the deadly gas. Silicon steam will
destroy the CO sensor. Corrosive gases (acidic or alkaline) and halogen
fire systems or extinguishers damage the CO sensor. will damage the CO
sensors. Water will reduce sensitivity until the sensor dries, and why
CO monitors should not be placed in bathrooms, shower rooms, or anywhere
there is high moisture.

The ones with replaceable batteries should beep when the battery is low.
Whether replaceable or not, they should start beeping every 30 seconds,
or show ERR on an LCD screen, when the entire unit needs to get
replaced. The CO monitor should have a date on the back, so you can
tell when to replace it rather than rely on beeps or ERR messages.

Post by J. P. Gilliver
True about the "considered"; in practice, I think the ones I've owned
and used - including this one - have always been 3 or more years old,
and often gone on for much longer than that.

My aunt has a laptop with Win Vista, and a notebook with Win 7. The
maker has long dropped support for those. Seems about 2 years is about
what you can expect for them supporting a model.

[J. P. Gilliver]

In message <8nzf4a4g1x7$***@v.nguard.lh> at Tue, 23 Jan 2024 20:24:08,
VanguardLH <***@nguard.LH> writes
[]

Post by VanguardLH
Lithiums can ignite on overcharging. Laptop, and other lithium
batteries have built-in protection. Coin cells do not.

Yes. Commoner in batteries than cells.
[]

Post by VanguardLH

Post by J. P. Gilliver
Though you _can_ get CO monitors that take conventional (or
rechargeable) cells. (Mine takes three AA.)

[]

Post by VanguardLH
The ones with replaceable batteries should beep when the battery is low.

Mine does indeed do that.
[]

Post by VanguardLH

Post by J. P. Gilliver
True about the "considered"; in practice, I think the ones I've owned
and used - including this one - have always been 3 or more years old,
and often gone on for much longer than that.

My aunt has a laptop with Win Vista, and a notebook with Win 7. The
maker has long dropped support for those. Seems about 2 years is about
what you can expect for them supporting a model.

And Microsoft not that much longer. (OK, it is longer, but you're
definitely treated as a dinosaur during the latter portion.)

[J. P. Gilliver]

Post by NY

Post by Paul

Post by J. P. Gilliver

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

Surely that is simply a matter of how often it polls the NTP server.

[]

Post by NY
spectacularly bad. Could it be that the polling interval for Meinberg
is shorter, rather than that the coding of Meinberg is inherently
better, irrespective of polling interval?

Good question! (I've seen some _implication_ that it monitors drift and
amends accordingly, but no actual _statement_ of that.)
[]

Post by NY
I never understood why CMOS batteries are always non-rechargeable, and

[]
Agreed - more in next post.

[Paul]

Post by J. P. Gilliver

Post by NY

Post by Paul

Post by J. P. Gilliver

Post by Brian Gregory
The built in one, especially as it was in Windows 7, is rubbish.

In what respect - what is rubbish about it?

It does not implement enough of the standard.
It's a half-assed implementation.
It waits all week, then makes one (huge) correction. BIG DEAL.

Surely that is simply a matter of how often it polls the NTP server.

[]

Post by NY
spectacularly bad. Could it be that the polling interval for Meinberg
is shorter, rather than that the coding of Meinberg is inherently
better, irrespective of polling interval?

Good question! (I've seen some _implication_ that it monitors drift and
amends accordingly, but no actual _statement_ of that.)
[]

Post by NY
I never understood why CMOS batteries are always non-rechargeable, and

[]
Agreed - more in next post.

Laptops do have rechargeable CMOS cells. Just not all laptops.

Some laptops have LR2032, a rechargeable good for 3 days if the pack is unplugged.
With the pack to charge it, it would always be full (one rechargeable battery
feeding another rechargeable battery).

A digital watch draws 2uA to maintain time using a 32768Hz oscillator.
The RTC draws 10uA to maintain time using a 32768Hz oscillator.
( Dividing the 10uA into the maH of the CR2032, gives 2.x years,
close to 3 years. )

Other laptops have CR2032, which lasts 3 years if no other power source is
present (pack pulled, sitting in junk closet). The CR2032 lasts 10 years (shelf life)
if +5VSB is available. That is because a lot of 3VSB rails are derived
from +5VSB, rather than that being a rail created specifically for the job
by some means (3VSB does not come from the ATX supply).

And this is why, if you are ever doing maintenance on a laptop, and you
pull out a plastic wrapped disc with a 1x2 header plug on the end, you
have to unwrap the plastic and read the legend on the battery, to be sure
you are substituting the correct item. The motherboard only expects one type.
No motherboard supports both types.

The presence of a recharging circuit, means "trouble" if you plug in a CR2032.
Since a CR2032 is *not rechargeable*, the max charging current allowed is 1uA.
And the only reason the spec number is not zero, is because the leakage current
at high temperature on a BAT54 is 1uA, and you'll be using a Schottky ORing diode
in the circuit, and 1uA flows backwards at 125C or whatever. That's why the spec
is 1uA -- it's to "sign off" on the usage of a certain three pin diode for that
circuit. The CR2032 would be more happy if no current flowed into it. The PC
does not spend a lot of time at 125C, so the situation is <cough> theoretical.

*******

Regarding the w32time behavior, in WinXP, if you checked the log, the time
keeping routine was running every 15 minutes and making a log entry. But,
it wasn't doing anything. It was not "leaking out a first order correction"
every fifteen minutes. The routine may fire up every fifteen minutes, but
only once a week might it actually visit time.windows.com and synchronize.

The reason for this behavior would be:

1) Demonstrates routine may have started as a "proper algorithm".
Via a config file, maybe the behavior changes.
2) PC motherboard clocks are not biased to be slow. They might well be
center-biased. Leaking out time corrections might be plus or minus
on such machines. Perhaps apparent time is moving in the wrong direction
if you leak out corrections.
3) A server motherboard clock, might have a negative bias and always
be slow. You can do this with a trimmer, or even a fixed cap of the
"wrong" value. Leaking out time corrections in this case, does not
impact monotonic timekeeping behavior.

The Linux behavior, could be applying the first order correction,
after being asleep for a month. This might improve on the amount of
error accrued over the period, without consulting time.windows.com.
(Read RTC. Work out what static drift correction to apply
in the NTP history file. Load into PC time keeping location in RAM.)

Noting a very small error to me, seems unbelievable. As I don't think
the motherboard time pieces are good enough, to null out all the error
with just a first order correction. Only an ovenized crystal could come
close to doing that.

Crystals can also be temperature compensated. You can make the
tempco of the capacitor next to it, have the same magnitude and opposite
sign, of the tempco of the crystal (this was covered in Scientific American
Amateur Scientist, decades ago.) This may be what was done in
some automotive clocks (like my Integra clock). With an oven and tempco covered,
only aging remains. Crystals are pre-aged, before shipment, so some of the
worst behavior has happened at the factory, before the thing ships.

PC crystals are crap, and don't get the degree of attention
mentioned in the following article. But the manufacturing steps
are the same. Just the treatment at the end would be "less expensive"
for a PC crystal.

https://blog.bliley.com/ocxo-lead-times

(Oven in an HP Frequency counter. Knowing that is inside the device,
you'd want the device to stabilize before being used for lab work.)

Loading Image...

There is lots of room for improvement on PC local clocks. The RTC uses
a watch crystal, so it can't be better than a watch. Some watches have a
trimmer cap (use a plastic screwdriver!), but the PC has nothing. No trimmer.

Paul

[J. P. Gilliver]

A comprehensive Paul reply.

In message <uop4re$1dpvv$***@dont-email.me> at Tue, 23 Jan 2024 14:42:37,
Paul <***@needed.invalid> writes
[]

Post by Paul
Laptops do have rechargeable CMOS cells. Just not all laptops.

Interesting, thanks.

Post by Paul
Some laptops have LR2032, a rechargeable good for 3 days if the pack is unplugged.
With the pack to charge it, it would always be full (one rechargeable battery
feeding another rechargeable battery).
A digital watch draws 2uA to maintain time using a 32768Hz oscillator.
The RTC draws 10uA to maintain time using a 32768Hz oscillator.

Hmm. Must be ultra-cheap if it takes five times the current of a digital
watch, for a clock that has no display!
[]

Post by Paul
circuit. The CR2032 would be more happy if no current flowed into it. The PC
does not spend a lot of time at 125C, so the situation is <cough> theoretical.
*******
Regarding the w32time behavior, in WinXP, if you checked the log, the time

[]

Post by Paul
Noting a very small error to me, seems unbelievable. As I don't think
the motherboard time pieces are good enough, to null out all the error
with just a first order correction. Only an ovenized crystal could come
close to doing that.

Agreed.
[]

Post by Paul
PC crystals are crap, and don't get the degree of attention

[]

Post by Paul
There is lots of room for improvement on PC local clocks. The RTC uses
a watch crystal, so it can't be better than a watch. Some watches have a
trimmer cap (use a plastic screwdriver!), but the PC has nothing. No trimmer.
Paul

And watches have a _reasonably_ constant temperature - not an oven, but
they're usually strapped to your wrist, so not far off 37°C!

Obviously the software clock is copied from the RTC when you turn on the
PC. I presume the RTC is written if you manually set the software clock,
and perhaps when the software clock gets an update - either manually or
by the (default weekly) correction from a time server. I'm guessing the
RTC is in general _not_ set from the software clock at shutdown, as
software demands probably knock the software one out quite a bit.

Presumably 32768 Hz is used because it's a power of 2 so easy to divide
- so the RTC has a resolution of one second anyway? (I vaguely remember
reading somewhere that the software one worked on an interrupt with a
frequency of 18 or 19 hertz, but can't remember where I got that. May be
different from the early PCs that used a colour-subcarrier crystal
anyway.)

[Paul]

And watches have a _reasonably_ constant temperature - not an oven, but they're usually strapped to your wrist, so not far off 37°C!
Obviously the software clock is copied from the RTC when you turn on the PC. I presume the RTC is written if you manually set the software clock, and perhaps when the software clock gets an update - either manually or by the (default weekly) correction from a time server. I'm guessing the RTC is in general _not_ set from the software clock at shutdown, as software demands probably knock the software one out quite a bit.
Presumably 32768 Hz is used because it's a power of 2 so easy to divide - so the RTC has a resolution of one second anyway? (I vaguely remember reading somewhere that the software one worked on an interrupt with a frequency of 18 or 19 hertz, but can't remember where I got that. May be different from the early PCs that used a colour-subcarrier crystal anyway.)

The RTC is derived from a Motorola chip design from a long time ago.

It uses a ripple divider -- the Q of each flop connects to the CLK on
the next flop. It is not a synchronous counter (on a synchronous counter,
the digits count and have carry-out, so 00001, 00010, 00011 means all
the flops burn a bit of power to do that).

The last ripple divider flop ticks over at the 1 second rate, and that is used for
synchronous counting for the various digit fields of the time piece.

This allows the thing to be powered through a 1K ohm resistor, with
a filter cap. The filter cap, a small one, holds enough juice for the
logic transients. The logic transients are larger, when the OS attempts
to read the clock by whatever means, but by that time, the +5VSB path
is being used for powering, so it does not matter. The battery path
assumes the CMOS logic is mostly quiet.

The 10uA drain, is partially because the RTC and CMOS RAM sit in the
"well" of the Southbridge, and I/O uses transmission gates. (The
transmission gates in effect, "tristate" to avoid leakage from the
well, while the RTC counts sheep.) The CMOS RAM might account for
some of the leakage.

When the PC sleeps, all five rails on the Southbridge are flat, and
only 3VSB rail to the RTC and CMOS is powered. And the way CMOS logic
works, is very tricky, in that one CMOS subsystem can pass power to
another CMOS subsystem using the Q and Qbar on the logic. We had an
example of this at work, where enough power was send from a powered
subsystem, to an unpowered one, to make the LEDs work on the unpowered
component, and VCC rose to 3.6V (of a max 5V), just by phantom leakage.
This is why the Southbridge well where the RTC lives, is isolated
to prevent that sort of leakage. It's easy to imagine some part of the
microamps, is still coming though that path.

Back in Pinball machine days, the high score chip would draw around 5uA
and it was NMOS rather than CMOS. Which means the CMOS RAM is not far
off that number, or could be the source of the leakage.

It's hard to say whether every chip has exactly the same drain,
but the three year CR2032 life is remarkably reproducible.

In a few cases, the CMOS RAM was not reliable, and there was bodgery
in firmware to hide that fact. You might be able to find comments
about "cold room, my PC doesn't work right", so some things on
a PC did not pass on temperature range (should have worked to 0C ambient).
But the companies making the silicon could not afford to stop -- they
just released the goods anyway. If you miss a release window by a few months,
your chances to make money drop to just about zero.

The alternative to all this fine stuff, is to return to the Dallas
Semiconductor RTC chip, where the battery was strapped to the roof
of the chip, and people used to "edit" their Dallas chip with a
Dremel -- to deal with the dead battery on the top.

Good times... that is for sure. We got some fine examples of
the DIY spirit back then.

https://www.ardent-tool.com/misc/Dallas_Rework.html

Paul

[J. P. Gilliver]

In message <uoph5t$1fqtl$***@dont-email.me> at Tue, 23 Jan 2024 18:13:00,
Paul <***@needed.invalid> writes
[]

Post by Paul
In a few cases, the CMOS RAM was not reliable, and there was bodgery
in firmware to hide that fact. You might be able to find comments
about "cold room, my PC doesn't work right", so some things on
a PC did not pass on temperature range (should have worked to 0C ambient).
But the companies making the silicon could not afford to stop -- they
just released the goods anyway. If you miss a release window by a few months,
your chances to make money drop to just about zero.

Yes. I used to work in the support department for avionics: you've got
two incompatible industries there - most people who buy aircraft
(whether civil or military) expect them to last at least a decade or two
(many in some cases!), whereas many semiconductors have an active
manufacturing life of months, certainly advanced ones. Constant effort
finding alternatives, or old inventory.

Post by Paul
The alternative to all this fine stuff, is to return to the Dallas
Semiconductor RTC chip, where the battery was strapped to the roof
of the chip, and people used to "edit" their Dallas chip with a
Dremel -- to deal with the dead battery on the top.
Good times... that is for sure. We got some fine examples of
the DIY spirit back then.
https://www.ardent-tool.com/misc/Dallas_Rework.html
Paul

Yes, a fun page!

[NY]

Post by J. P. Gilliver
pu gnikcab yb naem uoy tahw siht sI

OK, your code at the bottom of four sig has got me intrigued. It's not a
simple ROT code (neither the default ROT13 or any other ROT1-25).

[sticks]

Post by NY

Post by J. P. Gilliver
pu gnikcab yb naem uoy tahw siht sI

OK, your code at the bottom of four sig has got me intrigued. It's not a
simple ROT code (neither the default ROT13 or any other ROT1-25).

just start at the back end

[J. P. Gilliver]

Post by NY

Post by J. P. Gilliver
pu gnikcab yb naem uoy tahw siht sI

OK, your code at the bottom of four sig has got me intrigued. It's not
a simple ROT code (neither the default ROT13 or any other ROT1-25).

It's something I picked up a very long time ago - decades, I'm pretty
sure; I think it might have been from one of the original "fortune"
files.

It's just backwards (-:

[NY]

Post by NY

Post by J. P. Gilliver
pu gnikcab yb naem uoy tahw siht sI

OK, your code at the bottom of four sig has got me intrigued. It's not a
simple ROT code (neither the default ROT13 or any other ROT1-25).

Bollocks! I've just worked it out. All the right letters but in reverse
order. Too simple for words ;-)

(and I meant "your", not "four")

[David E. Ross]

Post by J. P. Gilliver
When I select "Adjust date/time" from the clock menu, I get the "Date
and Time" window, with three tabs; if I select the "Internet Time" one,
I am told "This computer is set to automatically synchronize with" a
time server. There's also a "Change settings..." button.
I clicked that button, expecting to be able to change the server and the
interval. I get a window containing: a tickbox to turn syncing on and
off altogether; a drop-down list of servers (I vaguely remember a post
or something telling me how to modify that list); and an "Update now"
button. It also tells me "The clock was successfully synchronised with
<timeserver> on 2023-12-17 at 19:00."
That was when I clicked "Update now" just now; it obviously _hadn't_
been doing so (it had been more or less a minute slow), despite (a)
"This computer is set to automatically ..." and (b) the time server
selected must still work (otherwise it wouldn't have "successfully
synchronised" when I told it to. (It did - it advanced by the minute -
as well as _telling_ me it had.
1. Why isn't it, despite (a) the "Synchronise ..." button being ticked,
and (b) a valid time server being in the box?
2. Where do I set the interval?
(No, I don't want to install a third-party utility: my mail/news suite
will do that if I start it with admin. privileges, but why isn't/how do
I set the interval in the mechanism that's part of the OS?)

On the other hand, I do use a third-party utility: SocketWatch. This is
no longer being updated, but my version 3.5b seems to work quite well.
I have archived the installer if you would like to try it. I have been
using it for over 20 years.

Occasionally (perhaps once in two years), I review the time servers it
uses and the servers listed at
<https://support.ntp.org/Servers/WebHome>. I then update SocketWatch's
list of servers.

SocketWatch takes 5 servers from its list and queries all 5 at an
interval that is user-set (once an hour in my setup). It then scores
the servers based on how long each takes to reply. The server with the
best (lowest score) is used to update my Windows clock.

The larger list is sorted by scores, lowest first. Each time
SocketWatch queries its 5, it compares the scores with the scores in the
larger list. If any of the 5 has a higher score than the lowest-scored
unused server in the larger list, the server with the lower score
replaces it.

[VanguardLH]

Post by J. P. Gilliver
When I select "Adjust date/time" from the clock menu, I get the "Date
and Time" window, with three tabs; if I select the "Internet Time" one,
I am told "This computer is set to automatically synchronize with" a
time server. There's also a "Change settings..." button.
I clicked that button, expecting to be able to change the server and the
interval. I get a window containing: a tickbox to turn syncing on and
off altogether; a drop-down list of servers (I vaguely remember a post
or something telling me how to modify that list); and an "Update now"
button. It also tells me "The clock was successfully synchronised with
<timeserver> on 2023-12-17 at 19:00."
That was when I clicked "Update now" just now; it obviously _hadn't_
been doing so (it had been more or less a minute slow), despite (a)
"This computer is set to automatically ..." and (b) the time server
selected must still work (otherwise it wouldn't have "successfully
synchronised" when I told it to. (It did - it advanced by the minute -
as well as _telling_ me it had.
1. Why isn't it, despite (a) the "Synchronise ..." button being ticked,
and (b) a valid time server being in the box?
2. Where do I set the interval?
(No, I don't want to install a third-party utility: my mail/news suite
will do that if I start it with admin. privileges, but why isn't/how do
I set the interval in the mechanism that's part of the OS?)

If you pick a very busy NTP server, you might not synchronize for a
while. Your competing with all other Windows users on a limited
resource. Lots of users don't touch this setting, so the vast majority
of hosts are trying to use time.windows.com server. Pick one not so
busy. Even changing to the pre-configured time.nist.org server would be
less busy giving you a better chance to sync. There is only 1 chance
per NTP update request to get updated. There's no pending or retrying.

To change the list of NTP servers, edit the registry at:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

You'll see numerical key names, like 1, 2, 3, etc. Add another key
name, like 4, and specify the NTP server. Then go back into Internet
time settings to pick the one you just added.

time.nist.org is less busy than time.windows.com. However, I use
us.pool.ntp.org (I'm in the USA) which load balances across various
regions (zones) to get you to an NTP server. For more info, see
https://www.ntppool.org/en/use.html. They have continental zones
(europe, north america, oceania, and asia). For me, I would pick the
north-america zone, drill down into the united states pool. For you,
pick whatever zone is yours, and drill down to however far they give you
within that zone.

If you don't want to use the ntp.org's NTP pool, your local university
probably runs their own own stratum 2 NTP server. Public NTP servers
are mostly stratum 3, but gov't or educational servers may be at stratum
2.

https://safran-navigation-timing.com/manuals/SS/Content/_Global/Topics/NTP/NTP_Stratums.htm
https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_strata

You can find online lists of NTP servers, like this one for stratum 2
NTP servers:

https://www.advtimesync.com/docs/manual/stratum2.html

Many lists don't tell you the strata. They omit that info, or they
don't know (like they crowd-source their database). What you have to
ensure is that the NTP server is publicly accessible. Some are not,
especially those that peer to other NTP servers in the same stratum.

Check if your university has public NTP servers. I used my university's
NTP servers (they have 2 of them, so I picked the 2nd one) until I
discovered the ntp.org pools.

Windows is configured to update the system clock about once per week, or
when you log into your Windows account (but that might only be for
domain members - those that login into a PDC). To change the update
interval, edit the registry at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config

and change the UpdateInterval data item's value. Mine is set to 360000
(decimal) which is the default for stand-alone clients (workstations).
It's 100 for domain controllers, and 30000 for domain members. The
value is in seconds, so 360000 seconds is about 4.2 days. Too long for
me, so I figured out how to sync more often. I could reduce the
registry value, too, but I'm leery an update would reset it, plus I
prefer scheduling an NTP update rather than having to edit the registry
any time I want to change the default update interval.

If you want to immediately do an NTP sync, but use the command line
instead of drilling through GUI wizard, run the w32tm program.

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings

I added the following event in Task Scheduler to do a time sync every
time I login:

w32tm /resync /nowait

Actually, that is in a batch file (timesync.bat) that runs:

net start w32time
w32tm /resync /nowait

No point in trying to do a time sync unless the w32time service is
running. 'net start' is asynchronous: just because the 'net' command
exits doesn't mean the service got into Running mode. So, it's possible
the w32tm program runs before the w32time service gets started and is
running, but after a few times of running the batch file the service
will be running. I would have to add code in the batch file that polls
the service using sc.exe to see when it got into Running status, but I
figure one, or two, mishaps is not a problem since I run the scheduled
event on the following triggers: at a time each day (I chose 12:05 AM),
on system startup, on workstation unlock of any user.

I can run the batch file manually should I want to. The w32tm program
requires you run it in an elevanted command shell. If I directly ran
the .bat file as an event in Task Scheduler, I'd see the command shell
open and close which can be distracting while also stealing focus away
from the window were I was currently working. So, in Task Scheduler,
the command I use is:

Program: cmd.exe
Arguments: /c start /min c:\batch\timesync.bat

The task is configured to run with highest privileges. I load the
command shell and use start and /min to minimize the console window to
just a taskbar button. That will show a taskbar button that flashes on
and off, and often so fast that I don't notice it. There are other
means of loading a program without a window, but I don't want to get
into scripting for such a simple task.

When Windows is running, it does not get time from the RTC logic on the
mobo. It uses its own system clock. If you run CPU intensive tasks,
like video editing, Prime95, or other high-CPU processes, the system
clock will drift. Typically I leave my desktop PC running 24x7;
however, the scheduled event makes sure that an NTP sync is performed
every day both by a scheduled time, and because my computer gets locked
using the screen saver (so I have to unlock to use which is a trigger to
run the time sync event). When the computer is powered off, the 3-volt
CMOS coin cell battery supplies power to the RTC logic (to keep time
when powered off). When Windows starts, it gets its time from RTC, but
thereafter uses its own code for its system clock, and why high CPU
usage can make the system clock drift.

I don't know what is your behavior regardling leaving the computer
always powered on, what processes you run regarding sustained high CPU
usage, or if you power off the computer when not in use. Might be time
to consider how old is the CMOS coin cell batter in your computer. For
a desktop (tower), replacing the battery is easy. For laptops, and
unless a backside cover panel was provided, you have to dismantle the
laptop to replace the battery. For a notebook (since those are often
ultrasonically welded together), you'll have to cut open the case after
finding out where is the battery (which may be soldered instead of in a
slide-in holder). Batteries are chemical: they'll die no matter how
well you care for them. How old is yours? After 5 years, time to
replace the battery.

[Java Jive]

Post by VanguardLH
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers
You'll see numerical key names, like 1, 2, 3, etc. Add another key
name, like 4, and specify the NTP server. Then go back into Internet
time settings to pick the one you just added.
time.nist.org is less busy than time.windows.com. However, I use
us.pool.ntp.org (I'm in the USA) which load balances across various
regions (zones) to get you to an NTP server. For more info, see

Similarly I use uk.pool.ntp.org, but AFAICR I just entered it directly
into the W7 Internet Time settings dialog, whereas on XP I had to alter
the registry key.

[J. P. Gilliver]

In message <***@v.nguard.lh> at Sun, 17 Dec 2023 17:48:16,
VanguardLH <***@nguard.LH> writes
[]

Post by VanguardLH
If you pick a very busy NTP server, you might not synchronize for a
while. Your competing with all other Windows users on a limited
resource. Lots of users don't touch this setting, so the vast majority
of hosts are trying to use time.windows.com server. Pick one not so
busy. Even changing to the pre-configured time.nist.org server would be
less busy giving you a better chance to sync. There is only 1 chance
per NTP update request to get updated. There's no pending or retrying.

Well, it worked when I clicked it manually - first time. And it has
before.
Thanks - post marked as keep.
[]

Post by VanguardLH
me, so I figured out how to sync more often. I could reduce the
registry value, too, but I'm leery an update would reset it, plus I

I don't think I'll be getting any updates (-:
[]

Post by VanguardLH
I added the following event in Task Scheduler to do a time sync every
w32tm /resync /nowait
net start w32time
w32tm /resync /nowait

I might do that if my shortening of the interval doesn't work.
[]

Post by VanguardLH
I can run the batch file manually should I want to. The w32tm program
requires you run it in an elevanted command shell. If I directly ran

I'd probably just use the GUI if I noticed my clock was out a _lot_;
there isn't anything I can think of that I do that actually matters (I'd
been running nearly a minute slow for some days if not longer).
[]

Post by VanguardLH
When Windows is running, it does not get time from the RTC logic on the
mobo. It uses its own system clock. If you run CPU intensive tasks,
like video editing, Prime95, or other high-CPU processes, the system

That's probably what's happened in my case.

Post by VanguardLH
clock will drift. Typically I leave my desktop PC running 24x7;

Ditto (though it's a laptop).
[]

Post by VanguardLH
I don't know what is your behavior regardling leaving the computer
always powered on, what processes you run regarding sustained high CPU

Nothing unattended; very little altogether - probably the most intensive
is the odd audio extraction from a video, but that usually only a music
track. But I guess they might build up.

Post by VanguardLH
usage, or if you power off the computer when not in use. Might be time
to consider how old is the CMOS coin cell batter in your computer. For
a desktop (tower), replacing the battery is easy. For laptops, and
unless a backside cover panel was provided, you have to dismantle the
laptop to replace the battery. For a notebook (since those are often
ultrasonically welded together), you'll have to cut open the case after
finding out where is the battery (which may be soldered instead of in a
slide-in holder). Batteries are chemical: they'll die no matter how
well you care for them. How old is yours? After 5 years, time to
replace the battery.

It's a laptop I bought in January (2023), but second-hand, so might well
be in need of it; the make is "stone", which I'd never heard of, but
I've been very pleased with it. But I suspect it's more that I leave it
on all the time, so it is slowed by things I do.

[VanguardLH]

Be aware that if your system/OS clock gets too far off that SSL/TLS
handshakes will fail. You won't be able to connect to HTTPS web sites.
How long is too long depends on the server config for timeouts on the
tokens in the handshake. I've never found fixed timeouts for when 2
hosts are too different on timestamps for when HTTPS will fail. Users
will report they cannot connect via HTTPS, but works after updating
their OS clock.

File sync could also get screwed if 2 hosts getting their files
synchronized are off on their timestamp.

There are other reasons why you need to keep your host accurate on time.
That the system clock is code running under the OS is why it can drift.
A dead battery also results in the system clock way off when starting
Windows.

[J. P. Gilliver]

Post by VanguardLH
Be aware that if your system/OS clock gets too far off that SSL/TLS
handshakes will fail. You won't be able to connect to HTTPS web sites.
How long is too long depends on the server config for timeouts on the
tokens in the handshake. I've never found fixed timeouts for when 2
hosts are too different on timestamps for when HTTPS will fail. Users
will report they cannot connect via HTTPS, but works after updating
their OS clock.

Interesting. I was nearly a minute slow, and noticed no problems.

Post by VanguardLH
File sync could also get screwed if 2 hosts getting their files
synchronized are off on their timestamp.

The only syncing I do are weekly and monthly backups to a local external
hard drive.

Post by VanguardLH
There are other reasons why you need to keep your host accurate on time.

Such as?

Post by VanguardLH
That the system clock is code running under the OS is why it can drift.

I suspect that's the main cause in my case.

Post by VanguardLH
A dead battery also results in the system clock way off when starting
Windows.

My machine isn't off enough for that to be significant (it might even
gain!).

[Paul]

Post by J. P. Gilliver

Post by VanguardLH
Be aware that if your system/OS clock gets too far off that SSL/TLS
handshakes will fail.  You won't be able to connect to HTTPS web sites.
How long is too long depends on the server config for timeouts on the
tokens in the handshake.  I've never found fixed timeouts for when 2
hosts are too different on timestamps for when HTTPS will fail.  Users
will report they cannot connect via HTTPS, but works after updating
their OS clock.

Interesting. I was nearly a minute slow, and noticed no problems.

Post by VanguardLH
File sync could also get screwed if 2 hosts getting their files
synchronized are off on their timestamp.

The only syncing I do are weekly and monthly backups to a local external hard drive.

Post by VanguardLH
There are other reasons why you need to keep your host accurate on time.

Such as?

Post by VanguardLH
That the system clock is code running under the OS is why it can drift.

I suspect that's the main cause in my case.

Post by VanguardLH
A dead battery also results in the system clock way off when starting
Windows.

My machine isn't off enough for that to be significant (it might even gain!).

There are two crystals.

The RTC uses a 32768Hz Watch crystal.

BCLK has its own clockgen, which has a quartz crystal too.
The clock tick interrupts might be traceable to BCLK, so if
BCLK drifts, the OS Software Clock drifts with it.

RTC Drift BCLK Drift

System is shut down System is Running

Thus, if you're a Meinberg and attempting to measure just the
BCLK component of drift, the situation is complicated by there
being two crystal behaviors. There may be an assumption this
is a Windows Server and it never stops running on BCLK. Or, the
drift is only measured while the system is on BCLK, and the
corrections are only leaked out when BCLK is being used. This
might imply the software has to contact time.windows.com at least
twice per running session (once at the beginning, once at shutdown).

NTP software does two things:

1) Calibrates the clock (read time.windows.com , copy into Software Clock)
2) Measures oscillator drift, which takes weeks of observations
to build the confidence interval.

The Windows one does (1), Meinberg does (1) and (2).

Paul

[Daniel65]

Post by J. P. Gilliver
When I select "Adjust date/time" from the clock menu, I get the "Date
and Time" window, with three tabs; if I select the "Internet Time"
one, I am told "This computer is set to automatically synchronize
with" a time server. There's also a "Change settings..." button.
I clicked that button, expecting to be able to change the server and
the interval. I get a window containing: a tickbox to turn syncing on
and off altogether; a drop-down list of servers (I vaguely remember a
post or something telling me how to modify that list); and an "Update
now" button. It also tells me "The clock was successfully
synchronised with <timeserver> on 2023-12-17 at 19:00."
That was when I clicked "Update now" just now; it obviously _hadn't_
been doing so (it had been more or less a minute slow), despite (a)
"This computer is set to automatically ..." and (b) the time server
selected must still work (otherwise it wouldn't have "successfully
synchronised" when I told it to. (It did - it advanced by the minute
- as well as _telling_ me it had.
1. Why isn't it, despite (a) the "Synchronise ..." button being
ticked, and (b) a valid time server being in the box? 2. Where do I
set the interval?

J.P., is your computer on 24/7 or might you have set it to
check/calibrate the clock some time when you routine have your computer
off/asleep/hibernating??

[J. P. Gilliver]

In message <ulp1fk$3e45t$***@dont-email.me> at Mon, 18 Dec 2023 19:56:20,
Daniel65 <***@nomail.afraid.org> writes
[]

Post by Daniel65
J.P., is your computer on 24/7 or might you have set it to

Yes, most of the time.

Post by Daniel65
check/calibrate the clock some time when you routine have your computer
off/asleep/hibernating??

Not that I can think of.

[John Hall]

In message <***@255soft.uk>, J. P. Gilliver
<***@255soft.uk> writes
[on time synchronisation]

Post by J. P. Gilliver
That was when I clicked "Update now" just now; it obviously _hadn't_
been doing so (it had been more or less a minute slow), despite (a)
"This computer is set to automatically ..." and (b) the time server
selected must still work (otherwise it wouldn't have "successfully
synchronised" when I told it to. (It did - it advanced by the minute -
as well as _telling_ me it had.
1. Why isn't it, despite (a) the "Synchronise ..." button being ticked,
and (b) a valid time server being in the box?
2. Where do I set the interval?

Is it possible that some other piece of software that you are running is
also trying to synchronise the time and for some reason is making a bad
job of it? Then, if that had happened more recently than the last time
sync by Windows, it could explain what you saw.

[J. P. Gilliver]

In message <61w4KeBEvBglFwb$@jhall_nospamxx.co.uk> at Mon, 18 Dec 2023
10:15:32, John Hall <***@jhall.co.uk> writes
[]

Post by John Hall
Is it possible that some other piece of software that you are running
is also trying to synchronise the time and for some reason is making a
bad job of it? Then, if that had happened more recently than the last
time sync by Windows, it could explain what you saw.

The only other software I have that I'm aware of having anything to do
with the time is Turnpike, my news/mail/etc. client; when started
(actually when told to make a connection - it dates from when dialup was
common), it thinks it corrects the clock, and tells me (if I look at its
log file) what correction it made. However, I discovered (discussed,
can't remember whether here or in the Turnpike 'group) that, though it
was successfully accessing a time server and reporting it had made the
appropriate connection, it wasn't actually doing so, unless I started it
with admin. privileges: presumably without those it didn't have write
ability to the clock (though it was unaware of its failure). However,
since it remains running (and "connected") all the time, and it only
makes (or tries to) the correction when it makes a connection, that's
not the cause of the error.

[Spalls Hurgenson]

As an aside, David Mills, the gentleman who invented the NTP protocol
which all this time syncronozition depends upon, just died last
Wednesday 17 January. He created the protocol in the 70s to help the
servers in ARPANet remain synchronized, and helped maintain and
develop it for decades thereafter. And - not to diminish his work -
his effort wasn't particularly innovative (if he hadn't done it,
somebody else would have certainly come up with a similar solution)
the fact that his protocol survives to this day is a testement to the
robustness of what he created.

So my hat is off to Mr. Mills. Thank you for making all our lives a
bit more simple by allowing us to keep all our clocks in tune with one
another. It's a neat bit of magic and one of the unseen lynchpins that
keep the Internet - and thus modern society - running.

[Jack]

Post by Spalls Hurgenson
As an aside, David Mills, the gentleman who invented the NTP protocol
which all this time syncronozition depends upon, just died last
Wednesday 17 January. He created the protocol in the 70s to help the
servers in ARPANet remain synchronized, and helped maintain and
develop it for decades thereafter. And - not to diminish his work -
his effort wasn't particularly innovative (if he hadn't done it,
somebody else would have certainly come up with a similar solution)
the fact that his protocol survives to this day is a testement to the
robustness of what he created.
So my hat is off to Mr. Mills. Thank you for making all our lives a
bit more simple by allowing us to keep all our clocks in tune with one
another. It's a neat bit of magic and one of the unseen lynchpins that
keep the Internet - and thus modern society - running.

R.I.P. David.

<https://en.wikipedia.org/wiki/David_L._Mills>