On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:

>On 20/12/2023 19:16, Char Jackson wrote:
>> 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.

Try Neutron Time, works on Windows 11

KenW

On 21/12/2023 13:14, KenW wrote:
> 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

--
Brian Gregory (in England).

On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:

>On 21/12/2023 13:14, KenW wrote:
>> 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

On 21/12/2023 15:24, KenW wrote:
> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
> <void-invalid-dead-dontuse@email.invalid> wrote:
>
>> On 21/12/2023 13:14, KenW wrote:
>>> 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.

--
Brian Gregory (in England).

Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:

> On 21/12/2023 15:24, KenW wrote:
>> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>
>>> On 21/12/2023 13:14, KenW wrote:
>>>> 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.

On 21/12/2023 22:47, VanguardLH wrote:
> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>
>> On 21/12/2023 15:24, KenW wrote:
>>> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
>>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>>
>>>> On 21/12/2023 13:14, KenW wrote:
>>>>> 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.

--
Brian Gregory (in England).

Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:

> On 21/12/2023 22:47, VanguardLH wrote:
>> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>>
>>> On 21/12/2023 15:24, KenW wrote:
>>>> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
>>>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>>>
>>>>> On 21/12/2023 13:14, KenW wrote:
>>>>>> 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.

On 12/22/2023 10:48 PM, VanguardLH wrote:
> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>
>> On 21/12/2023 22:47, VanguardLH wrote:
>>> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>>>
>>>> On 21/12/2023 15:24, KenW wrote:
>>>>> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
>>>>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>>>>
>>>>>> On 21/12/2023 13:14, KenW wrote:
>>>>>>> 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

Paul <nospam@needed.invalid> wrote:

> On 12/22/2023 10:48 PM, VanguardLH wrote:
>> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>>
>>> On 21/12/2023 22:47, VanguardLH wrote:
>>>> Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
>>>>
>>>>> On 21/12/2023 15:24, KenW wrote:
>>>>>> On Thu, 21 Dec 2023 14:48:11 +0000, Brian Gregory
>>>>>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>>>>>
>>>>>>> On 21/12/2023 13:14, KenW wrote:
>>>>>>>> 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."

In message <rl3z02okjq7d.dlg@v.nguard.lh> at Sat, 23 Dec 2023 02:24:12,
VanguardLH <V@nguard.LH> writes
[]
>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.
[]
>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.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"I'm tired of all this nonsense about beauty being only skin-deep. That's deep
enough. What do you want, an adorable pancreas?" - Jean Kerr

On 12/23/2023 3:24 AM, VanguardLH wrote:

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

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

On 12/23/2023 5:48 AM, J. P. Gilliver wrote:

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

https://i.postimg.cc/25PgfQG9/disk-benchmark-lack-of-agreement.gif

Paul

On 23/12/2023 03:48, VanguardLH wrote:
> 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.

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

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

> 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 (in England).

On 21/12/2023 08:12, Char Jackson wrote:
> On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory
> <void-invalid-dead-dontuse@email.invalid> wrote:
>
>> On 20/12/2023 19:16, Char Jackson wrote:
>>> 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.

--
Brian Gregory (in England).

On Sat, 23 Dec 2023 21:23:34 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:

>On 21/12/2023 08:12, Char Jackson wrote:
>> On Thu, 21 Dec 2023 02:56:40 +0000, Brian Gregory
>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>
>>> On 20/12/2023 19:16, Char Jackson wrote:
>>>> 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.

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.

On 21/01/2024 15:59, Spalls Hurgenson wrote:
> 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>

"Paul" <nospam@needed.invalid> wrote in message
news:ulp4ks$3emgl$1@dont-email.me...
> On 12/18/2023 2:35 AM, J. P. Gilliver wrote:
>> In message <ku9v7bFd3f3U1@mid.individual.net> at Mon, 18 Dec 2023
>> 04:13:31, Brian Gregory <void-invalid-dead-dontuse@email.invalid> writes
>>> 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.

NY <me@privacy.invalid> wrote:

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

https://www.smpspowersupply.com/connector_atx_pinout.GIF

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

In message <uoo138$17fsg$1@dont-email.me> at Tue, 23 Jan 2024 09:31:46,
NY <me@privacy.invalid> writes
>"Paul" <nospam@needed.invalid> wrote in message
>news:ulp4ks$3emgl$1@dont-email.me...
>> On 12/18/2023 2:35 AM, J. P. Gilliver wrote:
>>> In message <ku9v7bFd3f3U1@mid.individual.net> at Mon, 18 Dec 2023
>>>04:13:31, Brian Gregory <void-invalid-dead-dontuse@email.invalid>
>>>writes
>>>> 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.
[]
>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.)
[]
>I never understood why CMOS batteries are always non-rechargeable, and
[]
Agreed - more in next post.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Madness takes its toll. Please have exact change
[via Penny Mayes (mayes@pmail.net)]

In message <13fxs47ckjd9t.dlg@v.nguard.lh> at Tue, 23 Jan 2024 06:28:27,
VanguardLH <V@nguard.LH> writes
>NY <me@privacy.invalid> wrote:
>
>> 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.
>
>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.)
>
>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 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.

>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).
[]
>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.)
>
>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?
[]
>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.
[]
>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).
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Outside of a dog, a book is man's best friend. Inside of a dog, it is too
dark to read." - Groucho Marx

On 1/23/2024 8:39 AM, J. P. Gilliver wrote:
> In message <uoo138$17fsg$1@dont-email.me> at Tue, 23 Jan 2024 09:31:46,
> NY <me@privacy.invalid> writes
>> "Paul" <nospam@needed.invalid> wrote in message
>> news:ulp4ks$3emgl$1@dont-email.me...
>>> On 12/18/2023 2:35 AM, J. P. Gilliver wrote:
>>>> In message <ku9v7bFd3f3U1@mid.individual.net> at Mon, 18 Dec 2023
>>>> 04:13:31, Brian Gregory <void-invalid-dead-dontuse@email.invalid>
>>>> writes
>>>>> 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.
> []
>> 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.)
> []
>> 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.)

https://upload.wikimedia.org/wikipedia/commons/1/1f/HP_Counter_0XCO.jpg

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

A comprehensive Paul reply.

In message <uop4re$1dpvv$1@dont-email.me> at Tue, 23 Jan 2024 14:42:37,
Paul <nospam@needed.invalid> writes
[]
>Laptops do have rechargeable CMOS cells. Just not all laptops.

Interesting, thanks.
>
>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!
[]
>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
[]
>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.
[]
>PC crystals are crap, and don't get the degree of attention
[]
>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.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

There's too much attention paid to how TV can be bad for you, but I think it's
good for us more often than it's bad - Professor Barrie Gunter of Sheffield
University (quoted in RT, 15-21 March 2003).

On 1/23/2024 4:18 PM, J. P. Gilliver wrote:

> 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