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

Lewis: ... d'you think there's a god?
Morse: ... There are times when I wish to god there was one. (Inspector Morse.)

On 12/17/2023 2:23 PM, J. P. Gilliver wrote:
> 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?)

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

On 12/17/2023 11:23 AM, J. P. Gilliver wrote:
> 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?)
>

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.

--
David E. Ross
<http://www.rosde.com/>

Paris mayor quits X platform, calling it a 'gigantic global sewer'.
Others characterize X (previously known as Twitter) as the place
where truth goes to die.

"J. P. Gilliver" <G6JPG@255soft.uk> wrote:

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

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.

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

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.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

In message <ulnv0g$357i7$1@dont-email.me> at Sun, 17 Dec 2023 18:07:58,
Paul <nospam@needed.invalid> writes
[]
>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.

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

Thanks.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

I finally got my head together, and my body fell apart.

In message <13fkjxlhbyykr.dlg@v.nguard.lh> at Sun, 17 Dec 2023 17:48:16,
VanguardLH <V@nguard.LH> writes
[]
>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.
>
>To change the list of NTP servers, edit the registry at:

Thanks - post marked as keep.
[]
>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 (-:
[]
>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

I might do that if my shortening of the interval doesn't work.
[]
>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).
[]
>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.

>clock will drift. Typically I leave my desktop PC running 24x7;

Ditto (though it's a laptop).
[]
>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.

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

I finally got my head together, and my body fell apart.

On 18/12/2023 02:12, J. P. Gilliver wrote:
> In message <ulnv0g$357i7$1@dont-email.me> at Sun, 17 Dec 2023 18:07:58,
> Paul <nospam@needed.invalid> writes
> []
>> 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.
>
>>       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.
>>
>> 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.)
>>
>>   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.

--
Brian Gregory (in England).

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.

In message <ku9v7bFd3f3U1@mid.individual.net> at Mon, 18 Dec 2023
04:13:31, Brian Gregory <void-invalid-dead-dontuse@email.invalid> writes
[]
>If high time accuracy and reliability are important to you you should

Thanks - they aren't.

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

Thanks - noted.
>
>The built in one, especially as it was in Windows 7, is rubbish.
>
In what respect - what is rubbish about it?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Thay have a saying for it: /Geiz ist geil/, which roughly translates as, "It's
sexy to be stingly". - Joe Fattorini, RT insert 2016/9/10-16

In message <1uy3ji890arts.dlg@v.nguard.lh> at Sun, 17 Dec 2023 23:34:48,
VanguardLH <V@nguard.LH> writes
>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.
>
>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.
>
>There are other reasons why you need to keep your host accurate on time.

Such as?

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

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

Thay have a saying for it: /Geiz ist geil/, which roughly translates as, "It's
sexy to be stingly". - Joe Fattorini, RT insert 2016/9/10-16

J. P. Gilliver wrote on 18/12/23 6:23 am:
> 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?

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??
--
Daniel

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
> []
>> If high time accuracy and reliability are important to you you should
>
> Thanks - they aren't.
>
>> switch off the built in time synchronisation and install Meinberg NTP instead.
>>
>> https://www.meinbergglobal.com/english/sw/ntp.htm
>
> Thanks - noted.
>>
>> 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

In message <6weytvkmq0flFwSD@255soft.uk>, J. P. Gilliver
<G6JPG@255soft.uk> writes
[on time synchronisation]
>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?

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.
--
John Hall
"Acting is merely the art of keeping a large group of people
from coughing."
Sir Ralph Richardson (1902-83)

On 12/18/2023 2:39 AM, J. P. Gilliver wrote:
> In message <1uy3ji890arts.dlg@v.nguard.lh> at Sun, 17 Dec 2023 23:34:48, VanguardLH <V@nguard.LH> writes
>> 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.
>>
>> 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.
>>
>> There are other reasons why you need to keep your host accurate on time.
>
> Such as?
>
>> 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.
>
>> 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

In message <ulp4ks$3emgl$1@dont-email.me> at Mon, 18 Dec 2023 04:50:18,
Paul <nospam@needed.invalid> writes
>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.
[]
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.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

You can't abdicate and eat it - attributed to Wallis Simpson, in Radio Times
14-20 January 2012.

In message <ulp1fk$3e45t$1@dont-email.me> at Mon, 18 Dec 2023 19:56:20,
Daniel65 <daniel47@nomail.afraid.org> writes
[]
>J.P., is your computer on 24/7 or might you have set it to

Yes, most of the time.

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

Not that I can think of.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

You can't abdicate and eat it - attributed to Wallis Simpson, in Radio Times
14-20 January 2012.

In message <61w4KeBEvBglFwb$@jhall_nospamxx.co.uk> at Mon, 18 Dec 2023
10:15:32, John Hall <john_nospam@jhall.co.uk> writes
[]
>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.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

You can't abdicate and eat it - attributed to Wallis Simpson, in Radio Times
14-20 January 2012.

On 12/18/2023 8:52 AM, J. P. Gilliver wrote:
> In message <ulp4ks$3emgl$1@dont-email.me> at Mon, 18 Dec 2023 04:50:18, Paul <nospam@needed.invalid> writes
>> 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.
> []
> 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

On 18/12/2023 09:50, Paul wrote:
> 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
>> []
>>> If high time accuracy and reliability are important to you you should
>>
>> Thanks - they aren't.
>>
>>> switch off the built in time synchronisation and install Meinberg NTP instead.
>>>
>>> https://www.meinbergglobal.com/english/sw/ntp.htm
>>
>> Thanks - noted.
>>>
>>> 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.

--
Brian Gregory (in England).

In message <ulqq8b$3o96t$1@dont-email.me> at Mon, 18 Dec 2023 20:05:13,
Paul <nospam@needed.invalid> writes
>On 12/18/2023 8:52 AM, J. P. Gilliver wrote:
>> In message <ulp4ks$3emgl$1@dont-email.me> at Mon, 18 Dec 2023
>>04:50:18, Paul <nospam@needed.invalid> writes
[]
>>> 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.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

.... the closest thing the movies have ever got to a human special effect.
- Barry Norman on Arnold Schwarzenegger (RT 2014/9/27-10/3)

On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:

>On 18/12/2023 09:50, Paul wrote:
>> 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
>>> []
>>>> If high time accuracy and reliability are important to you you should
>>>
>>> Thanks - they aren't.
>>>
>>>> switch off the built in time synchronisation and install Meinberg NTP instead.
>>>>
>>>> https://www.meinbergglobal.com/english/sw/ntp.htm
>>>
>>> Thanks - noted.
>>>>
>>>> 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?

On 19/12/2023 03:11, Char Jackson wrote:
> On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory
> <void-invalid-dead-dontuse@email.invalid> wrote:
>
>> On 18/12/2023 09:50, Paul wrote:
>>> 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
>>>> []
>>>>> If high time accuracy and reliability are important to you you should
>>>>
>>>> Thanks - they aren't.
>>>>
>>>>> switch off the built in time synchronisation and install Meinberg NTP instead.
>>>>>
>>>>> https://www.meinbergglobal.com/english/sw/ntp.htm
>>>>
>>>> Thanks - noted.
>>>>>
>>>>> 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.

--
Brian Gregory (in England).

On Wed, 20 Dec 2023 03:00:26 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:

>On 19/12/2023 03:11, Char Jackson wrote:
>> On Tue, 19 Dec 2023 01:23:18 +0000, Brian Gregory
>> <void-invalid-dead-dontuse@email.invalid> wrote:
>>
>>> On 18/12/2023 09:50, Paul wrote:
>>>> 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
>>>>> []
>>>>>> If high time accuracy and reliability are important to you you should
>>>>>
>>>>> Thanks - they aren't.
>>>>>
>>>>>> switch off the built in time synchronisation and install Meinberg NTP instead.
>>>>>>
>>>>>> https://www.meinbergglobal.com/english/sw/ntp.htm
>>>>>
>>>>> Thanks - noted.
>>>>>>
>>>>>> 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.

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.

--
Brian Gregory (in England).