In message <u9oahv$13min$1@dont-email.me> at Tue, 25 Jul 2023 07:09:50,
Paul <nospam@needed.invalid> writes
>On 7/25/2023 5:22 AM, John Hall wrote:
>
>> I'm using it under 32-bit Windows 10, where it runs fine. Looking at
>>my current logging file, I see:
>>
>> Tue, 25 Jul 2023 09:38:09 SNTP: PC clock corrected (it was 1 seconds slow)
>>
>> Being old-fashioned, I always turn off my PC overnight, and start it
>>again each morning - when
>> I think Windows resets the clock if necessary - so I imagine there's
>>never a chance for a
>> big time discrepancy to build up.
>
>Just for the record, on occasion, the "big" NTP references like
>time.windows.com
>can be off by *20 minutes* :-) So if you think life owes you a free
>lunch, it is
>a lunch of a quite variable quality :-) I was pretty shocked the time
>that happened
>to me (picked up a bad update). I switched references, did another update, and
>brought it back.
>
>https://nist.time.gov/

As another has pointed out, using an alpha rather than numeric address
adds a DNS lookup delay to the round trip (but of course has the
advantage that it doesn't need to be updated if the numeric address
changes).

(I'm not bothered by that sort of error; within two or three seconds is
more than accurate enough for me!)
>
> "Your clock is off by +0.406 seconds" <=== my clock, now
>maintained only by "w32time" builtin.
> Paying attention to
>this, is only when we have
> "hold my beer" contests.
>
>When an application checks the OS ("software clock"), more
>digits are available on the software clock, than on the
>RTC battery-backed clock. The RTC has a resolution of 1 second.
>
>That's why this output from you, really annoys me.
>
> PC clock corrected (it was 1 seconds slow)
> ^^^^^^^^^
>
>This means the clever clever kiddy programmers are reading
>the God damn RTC from Windows level, and making corrections
>to the RTC ? When the OS is maintaining the time while the OS
>is running ? The OS reads the RTC *once* at bootup, and if
>left undisturbed, the OS (via w32time) may make one write to
>the RTC at shutdown.

I don't know which clock Turnpike corrects; since, under normal
circumstances, as you say the RTC is copied from the OS clock in a
normal shutdown, I would hope that it modifies the OS one, otherwise any
correction made will be lost at next shutdown. (Or, that it modifies
both, but since it says clock singular, I presume it only modifies one
of them.)
>
>A clever clever programmer, could modify only the OS clock. Since

Actually, see the above paragraph, there might be an argument for doing
exactly that. Depends whether the normal shutdown process _does_ copy
the OS clock to the RTC or not; I have a feeling it does, but CBA to
find out (-:

>the OS clock has all those extra digits, the software (as if it
>was NTPD) could dribble out fractional-second corrections as a
>"first order correction". This is a linear fit to what is going on,

If by "clever clever kiddy programmer" you're referring to the Turnpike
programmers, I've never seen it report fractional corrections - always a
whole number of seconds. (Also, it sometimes just says the clock was
correct, which suggests it's only using whole seconds - I presume if
fractions are involved, it would never be "correct".)

>and the software concludes "this OS clock gains 0.512 seconds per hour",
>and it could make a 0.128 second correction to the time, every
>fifteen minutes. You could subtract 0.128 from the current OS time,
>because the OS has the digits for it. To correct the RTC that way,
>you would be subtracting 0.128 seconds, from a hardware device where
>the lowest unit of resolution is 1 second.

TP certainly doesn't do any sort of rate assessment - it just checks
against an external server at predefined intervals (24h by default, I
think). Much as I think the W7 built-in routine does. (If you adjust the
clock using the built-in facility - either by clicking "Update now" or
manually setting the time - does that also instigate a write to the RTC,
or only the OS one? Just curious.)
[]
>But this Turnpike practice is sounding as "hoaky as a $3 bill" (a
>currency that does not exist).
>It's a 1995 solution, in the year 2023.

Eh? Which practice? AFAICS, Turnpike is only doing the same as the
built-in mechanism - or rather thinks it is, but isn't, presumably for
an access permission reason.
>
>The "w32time" software the OS comes with, as far as I know, it
>does not make first order (dribbling) corrections. The Meinberg

If by that you mean tweaking the entirely-software clock (doing the
software equivalent of making a mechanical adjustment to a mechanical
clock), I can see no point in doing so, since badly-behaved software
(and possibly hardware) could adversely affect it anyway. The
time-retaining software would have to have higher priority than
absolutely everything else for that to be untrue, and I don't think it
does.

>software is a slightly more complete NTP-service implementation, and
>it has lots more options for clock discipline. For example, by
>telling it "which serial port" my GPS was on, it would
>absorb GPS messages, track and correct the time as it found it.
>The trick there, is the GPS has a hardware 1PPS "pulse" signal,
>and if the user ties that to RI ("Ring Indicator") on the serial
>port, the Meinberg software uses the edge of that pulse as the
>time reference. That can give quite-good alignment. A GPS-disciplined
>PC can even be used as a low-stratum reference for the rest of the
>computer room (tie GPS to computer #1, sync computer #2 to computer #1).

That sounds like it's for users who need supreme accuracy, for perhaps
scientific reasons.
>
>Oscillator performance is subject to "drift" and this is a wobbly
>phenomenon. A first-order correction is childs play (and it exists
>as acknowledgement that no attempt was made to tune the hardware
>oscillator on the motherboard). Higher order corrections are not
>really going to work, because the oscillator was not designed for
>any notion of stability (coefficients matched and negated by
>component selection). If you want to see thoughtful implementations
>of time pieces, some automobiles have had wonderful work done, with
>low drift over a one year period. And that's with no "GPS tricks
>to fake it". Just a decent low drift oscillator (which does not draw
>a lot of power). My previous car, the car clock was the best time
>piece I owned (short of the GPS of course, which is cheating).

Indeed; I worked in electronics. Cheap quartz-based oscillator modules
could be bought with an accuracy as bad as 500 ppm (I suspect that was
guaranteed, and to include all sources - variation with temperature,
ageing, and so on, and in practice they were better than that - I never
had any reason to _need_ high accuracy [I wasn't using them for
timekeeping]); normal _fairly_ cheap ones say about 50 or 100 ppm. I
_think_ you could buy - at a higher price - ones down to about 10 ppm;
for better than that, they had to be ovened, which obviously raises the
power consumption. I'm very impressed with your car one, as I can't
imagine that used an ovened crystal, as that would involve too much
power for a car system.
>
> Paul
>
As for my original question, whether prog.s need special permission to
write-access the clock (OS or RTC), it remains open, but with the strong
suggestion that yes, they do (which is fair enough, for anti-malware
reasons).
--
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)]

On 25/07/2023 11:11, J. P. Gilliver wrote:
>
> In message <u9o5n0$1368r$1@dont-email.me> at Tue, 25 Jul 2023 10:47:09,
> Java Jive <java@evij.com.invalid> writes
>>
>> Then either your existing time source is failing to get the correct
>> time and/or your RTC hardware in the BIOS is wandering, or possibly
>> you have some sort of malware which is affecting your existing
>> method.  The
>
> No, you're misunderstanding me. I have two ways of ensuring the system
> clock is showing the right time:
>
> 1. Windows 7's built-in way (currently not enabled)
> 2. Turnpike (currently thinks it's making corrections but isn't).
>
> Both are currently set to the same time server. If I manually enable the
> W7 built-in way, it _does_ successfully correct the clock, so my
> "existing time source" - the time server - _is_ yielding to correct time.

So do it the W7 built-in way and have done with the, er, time-wasting,
problem!

>> answer to the first two is as VanguardLH suggested: do it the 'right'
>> way, disable your existing method and use an approved NTP server such
>> as uk.pool.ntp.org:
>
> It's not which server I use, as both are using the same one.
>
> Turnpike _is_ retrieving the correct time from the server, as its log
> window shows the corrections it thinks it's making: it's just that it
> isn't actually making them, presumably because it doesn't have the
> appropriate permission to do so.

But, as it's failing, do it the approved way, instead.

>> To set your W7 to use internet time in the approved way:
>>       Click the clock on the taskbar;
>>       Click Change date and time settings...;
>>       Click Internet time;
>>       Click Change settings;
>
> At that point there's an "Update now" button, which allows a one-off
> manual action. This is what I've been doing - see above - to verify that
> the time server I am using (both shown in that window and in Turnpike)
> is indeed yielding a correct time (correct enough for me, anyway).
>
>>       Ensure that Synchronise with an Internet time server is checked;
>>       Enter a suitable server and click Update now;
>>       Click Ok all the way back out.
>
> Now that I come to look at that part of W7, I can't actually see any
> setting for how _often_ it does a sync.; I vaguely remember that it
> might be once in 24 hours. (In Turnpike, you set the interval - on mine
> it's set to 24h 0m, which I think was the default.)

As long as it's at least once every 24 hours and preferably not much
more than once an hour or so, I don't really see that's much of a
problem, few hardware clocks are going to get seriously out over less
than a day.

However, if you can decipher them, the service settings are at ...

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time

.... and in particular ...

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config

.... which has various settings and values, in my case, such as ...

FrequencyCorrectRate = 0x4
MaxPollInterval = 0xf
MinPollInterval = 0xa

.... which may be relevant, but I think the following is probably what
you want ...

UpdateInterval = 0x57e40

.... which is 360000 in real money. I'm guessing that's probably a
number of milliseconds = 6 minutes, or possibly seconds = 100 hours. An
internet search would probably find out its exact meaning, but I've
never felt the need to change anything other than the server, preferring
uk.pool.ntp.org rather than Microsoft's offering. ISTR that in XP I had
to change the server under the above registry key, but in W7 you can do
it just via the GUI.

>> As for malware, ISTR that there was a scare some time back that
>> malware either could potentially or was already hi-jacking the NTP
>> system in some way, and there was talk of encrypting the service, but
>> I'm not sure what the end result was.  Certainly for years I've used
>> NTP from uk.pool.ntp.org with little or no problems, but you could run
>> a scan for rootkits and other malware using a program like MalwareBytes.
>>
> I don't think I have any problem - this entire thread was triggered by
> my happening to notice that TP was not correcting the clock, though it
> thought it was; my first thought was that it was set to use a time
> server that was no longer extant (or no longer responding in the way TP
> expected), but on checking, I found it was set to use the same server as
> W7's built-in mechanism, which when invoked manually _did_ correct the
> clock, so I deduced that TP doesn't have the right access permission.
>
> There's another post in this thread with a link something like "how to
> give prog.s access to the clock"; I'm about to read that now!

FFS, why bother? Just do it the same as everyone else does it! If the
standard method didn't work for some reason, I could understand wanting
to investigate further, but in this case it's the non-standard method
that's not working, so fire it and forget it. I used to use Digiguide
to do this, but when I found that the W32Time service 'just worked', I
disable that option in the program, and have never had any desire to
re-enable it.

--

Fake news kills!

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

In message <u9odmk$141lp$1@dont-email.me> at Tue, 25 Jul 2023 13:03:29,
Java Jive <java@evij.com.invalid> writes
>On 25/07/2023 11:11, J. P. Gilliver wrote:
[]
>So do it the W7 built-in way and have done with the, er, time-wasting,
>problem!
[]
>But, as it's failing, do it the approved way, instead.

See below re "curiosity".
[]
>As long as it's at least once every 24 hours and preferably not much
>more than once an hour or so, I don't really see that's much of a
>problem, few hardware clocks are going to get seriously out over less
>than a day.

Agreed.
[]
>FFS, why bother? Just do it the same as everyone else does it! If the
>standard method didn't work for some reason, I could understand wanting
>to investigate further, but in this case it's the non-standard method
>that's not working, so fire it and forget it. I used to use Digiguide
>to do this, but when I found that the W32Time service 'just worked', I
>disable that option in the program, and have never had any desire to
>re-enable it.
>
I don't think _curiosity_ - which was my main reason for starting the
thread (my first post didn't mention Turnpike) - should be suppressed:
if it was, we'd never find out anything. My original question was, more
or less, "do prog.s need special permission to write-access the clock,
and if so, how is it achieved?"; that's _sort of_ been answered - at
least, the first part has (seems to be "yes they do need more permission
than they once did"), and the second may have been but is more
complicated than I'd hoped.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Sometimes I believe we made up god just to have someone to blame for our
mistakes - "Sarah Sidle" (Jorja Fox), CSI

On Tue, 25 Jul 2023 07:09:50 -0400, Paul <nospam@needed.invalid> wrote:

>Just for the record, on occasion, the "big" NTP references like time.windows.com
>can be off by *20 minutes* :-)

I don't really see how that's possible, or I should say how it's likely, but
from where I sit time.windows.com is stratum 3, which isn't great. I like to use
stratum 1 servers, with stratum 2 servers as fallback. This is on my linux
systems. On Windows, I just configure a single stratum 1 server.

Back to the question of an NTP server being 'off', every 2-3 years we run
through a highly coordinated exercise with many of our bigger enterprise
customers where we help them account for a leap second, so I figure if being off
a full second is a big deal then I don't even know how an NTP server could be
off by minutes. Something's up with that.

# ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
*132.163.96.1 .NIST. 1 u 12 64 1 39.681 9.593 0.691
69.89.207.99 .PPS. 1 u 4 64 1 56.171 0.981 1.183
73.239.145.47 42.20.202.230 2 u 10 64 1 85.096 15.279 4.982
216.229.4.69 162.254.66.243 2 u 10 64 1 37.995 9.128 0.356
74.6.168.73 98.137.249.214 2 u 8 64 1 81.820 12.945 0.316
72.30.35.88 98.139.133.62 2 u 7 64 1 64.130 6.741 1.186
185.125.190.58 86.23.195.30 2 u 6 64 1 124.289 11.507 0.927
209.51.161.238 66.220.9.122 2 u 6 64 1 40.378 2.783 0.440
216.229.0.49 128.138.140.44 2 u 5 64 1 38.514 9.727 0.468
198.30.92.2 130.207.244.240 2 u 3 64 1 49.261 9.973 0.698
168.61.215.74 25.66.230.2 3 u 2 64 1 37.977 9.746 0.550

That last entry is time.windows.com. Stratum 3, not used.

On Tue, 25 Jul 2023 12:57:18 +0100, "J. P. Gilliver" <G6JPG@255soft.uk> wrote:

>As another has pointed out, using an alpha rather than numeric address
>adds a DNS lookup delay to the round trip (but of course has the
>advantage that it doesn't need to be updated if the numeric address
>changes).
>
>(I'm not bothered by that sort of error; within two or three seconds is
>more than accurate enough for me!)

I don't think a DNS lookup has any bearing on the time. The DNS request is
resolved *before* the NTP request is sent to the NTP server, so it can take as
long as it likes without affecting the results.

On 7/25/2023 9:45 AM, Char Jackson wrote:
> On Tue, 25 Jul 2023 07:09:50 -0400, Paul <nospam@needed.invalid> wrote:
>
>> Just for the record, on occasion, the "big" NTP references like time.windows.com
>> can be off by *20 minutes* :-)
>
> I don't really see how that's possible, or I should say how it's likely, but
> from where I sit time.windows.com is stratum 3, which isn't great. I like to use
> stratum 1 servers, with stratum 2 servers as fallback. This is on my linux
> systems. On Windows, I just configure a single stratum 1 server.
>
> Back to the question of an NTP server being 'off', every 2-3 years we run
> through a highly coordinated exercise with many of our bigger enterprise
> customers where we help them account for a leap second, so I figure if being off
> a full second is a big deal then I don't even know how an NTP server could be
> off by minutes. Something's up with that.
>
> # ntpq -pn
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> *132.163.96.1 .NIST. 1 u 12 64 1 39.681 9.593 0.691
> 69.89.207.99 .PPS. 1 u 4 64 1 56.171 0.981 1.183
> 73.239.145.47 42.20.202.230 2 u 10 64 1 85.096 15.279 4.982
> 216.229.4.69 162.254.66.243 2 u 10 64 1 37.995 9.128 0.356
> 74.6.168.73 98.137.249.214 2 u 8 64 1 81.820 12.945 0.316
> 72.30.35.88 98.139.133.62 2 u 7 64 1 64.130 6.741 1.186
> 185.125.190.58 86.23.195.30 2 u 6 64 1 124.289 11.507 0.927
> 209.51.161.238 66.220.9.122 2 u 6 64 1 40.378 2.783 0.440
> 216.229.0.49 128.138.140.44 2 u 5 64 1 38.514 9.727 0.468
> 198.30.92.2 130.207.244.240 2 u 3 64 1 49.261 9.973 0.698
> 168.61.215.74 25.66.230.2 3 u 2 64 1 37.977 9.746 0.550
>
> That last entry is time.windows.com. Stratum 3, not used.
>

I swear to God, it was off by 20 minutes.

There might be a record of that somewhere.

That's the biggest time error of that type, I've
ever seen. And I was using one of the two big ones.

It wasn't pool.ntp.org because I'd stopped using them
years ago. I don't think anything, even the router,
runs off pool.ntp.org now.

*******

One of the reasons I have yet another standalone
timepiece in the room here today, is for a quick glance to
see that none of this rubbish has run off on me.

You know, one day, my faithful wrist watch (had been
sitting on the desk, not dropped on the floor, no
Coke spilled on it), the time setting inside that
thing was just blasted to hell. All I can think, is a
cosmic ray of energetic proportion hit it. The battery
is good and it's still keeping time today. There have been
no repeat incidents. You would think the geometry of
crusty old circuits like that, would make them less likely
to have events like that (more likely to be 3u CMOS inside than 5nm CMOS).
I could buy one of the digits being wrong, but every field
was altered.

Paul

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

> I do remember that at install time, if on (I think)
> XP or later, we had to run a couple of (I think) CLSID commands to give
> it a certain sort of control over a couple of directories if we
> installed it in certain places on C: (which it defaulted to).

Did you install TP in one of the C:\Program Files [x86] folders? Those
became protected folders. It became a no-no for programs to write data
into their own program folder. They were supposed to write their data
under the %Appdata% folder in a subfolder for the program. ACLs (Access
Control Lists) are set on those folders to prevent write access to
processes without administrative privileges. This low-level protection
helps prevent malicious programs from modifying other programs, and
prevents non-admin users from installing non-trusted programs.

https://en.wikipedia.org/wiki/Access-control_list
https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/access-control-list

For example, I use an ancient newsreader called 40tude Dialog. I didn't
need to to run with admin privs, so I dumped it in a non-protected
folder. To "install" it, I created a C:\Programs folder under which I
created a subfolder called Dialog, and where I put the files for the
program, so I have C:\Programs\Dialog as the program folder.

However, I wouldn't think TP would be doing any writes just to issue an
NTP request. That's a sync, not a write. I would first try to run the
already-installed TP with elevated privileges. You can specify that
using a shortcut where in its properties under Shortcut tab -> Advanced
you enable the "Run as administrator" option. If you're not using a
shortcut, load the command shell with elevated privileges, and navigate
to and run the .exe program for TP.

Come back to say if elevating privileges for TP resolves the problem.

Hmm, just another thought. Are you logging your computer into a domain
(Active Directory Domain Services)? The PDC (Primary Domain Controller)
gets used to time sync all of its workstations. Windows on the
workstations will sync with the time of the PDC as their primary NTP
server. If the PDC server is always off by, say, the 47 seconds you
mention after TP trys an NTP sync, could be the PDC time service is off
by that much. You sync using TP to a specified NTP server, but Windows
syncs to the PDC server. It is up to the PDC server to sync to an
authoritative time source, and the workstations sync to the PDC server.

I'd also check the Windows Firewall. NTP requires using UDP on port 123
to connect to an NTP server. Microsoft wouldn't have defined a blocking
rule in the Firewall against their own NTP service, but maybe there's a
rule in the Firewall against Turnpike.

In message <mdhvcs7u80tx$.dlg@v.nguard.lh> at Tue, 25 Jul 2023 12:12:56,
VanguardLH <V@nguard.LH> writes
>"J. P. Gilliver" <G6JPG@255soft.uk> wrote:
>
>> I do remember that at install time, if on (I think)
>> XP or later, we had to run a couple of (I think) CLSID commands to give
>> it a certain sort of control over a couple of directories if we
>> installed it in certain places on C: (which it defaulted to).
>
>Did you install TP in one of the C:\Program Files [x86] folders? Those

Not this time. (No x86 folder - this being a 32-bit system, _all_ are
32-bit, and when that's the case, the system doesn't _make_ two such
folders.) This time, since Turnpike is so small relative to other
things, I installed it entirely on D:, so that it gets backed up with my
normal data backup. (It's the only software I've done that with.)
[]
>However, I wouldn't think TP would be doing any writes just to issue an
>NTP request. That's a sync, not a write. I would first try to run the
>already-installed TP with elevated privileges. You can specify that
>using a shortcut where in its properties under Shortcut tab -> Advanced
>you enable the "Run as administrator" option. If you're not using a
>shortcut, load the command shell with elevated privileges, and navigate
>to and run the .exe program for TP.

Speaking to you now, having started the Connect part of TP with Run as
administrator ...
>
>Come back to say if elevating privileges for TP resolves the problem.

.... and it did indeed really correct the clock when it said it was doing
so. So if I'm ever worried about it in future, I know what to do.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Never make the same mistake twice...there are so many new ones to make!

In message <1ug5l03qejsfd.dlg@v.nguard.lh> at Tue, 25 Jul 2023 12:26:12,
VanguardLH <V@nguard.LH> writes
>Hmm, just another thought. Are you logging your computer into a domain
>(Active Directory Domain Services)? The PDC (Primary Domain Controller)

Not knowingly. There is one box connected to the 'phone line - what UK
ISPs call a "router", which is in practice combined MoDem, router, hub,
and wifi - and one device connected to the wifi, this laptop.

>gets used to time sync all of its workstations. Windows on the
>workstations will sync with the time of the PDC as their primary NTP
>server. If the PDC server is always off by, say, the 47 seconds you
>mention after TP trys an NTP sync, could be the PDC time service is off
>by that much. You sync using TP to a specified NTP server, but Windows
>syncs to the PDC server. It is up to the PDC server to sync to an
>authoritative time source, and the workstations sync to the PDC server.

Starting Turnpike's Connect with admin privileges let it correct the
clock.
>
>I'd also check the Windows Firewall. NTP requires using UDP on port 123
>to connect to an NTP server. Microsoft wouldn't have defined a blocking
>rule in the Firewall against their own NTP service, but maybe there's a
>rule in the Firewall against Turnpike.

It was connecting to the time server no problem - it knew how far out
the local clock was; it just was unable to correct it.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Never make the same mistake twice...there are so many new ones to make!

On Tue, 25 Jul 2023 21:29:37 +0100, "J. P. Gilliver" <G6JPG@255soft.uk> wrote:

>In message <mdhvcs7u80tx$.dlg@v.nguard.lh> at Tue, 25 Jul 2023 12:12:56,
>VanguardLH <V@nguard.LH> writes
>>"J. P. Gilliver" <G6JPG@255soft.uk> wrote:
>>
>>> I do remember that at install time, if on (I think)
>>> XP or later, we had to run a couple of (I think) CLSID commands to give
>>> it a certain sort of control over a couple of directories if we
>>> installed it in certain places on C: (which it defaulted to).
>>
>>Did you install TP in one of the C:\Program Files [x86] folders? Those
>
>Not this time. (No x86 folder - this being a 32-bit system, _all_ are
>32-bit, and when that's the case, the system doesn't _make_ two such
>folders.) This time, since Turnpike is so small relative to other
>things, I installed it entirely on D:, so that it gets backed up with my
>normal data backup. (It's the only software I've done that with.)
>[]
>>However, I wouldn't think TP would be doing any writes just to issue an
>>NTP request. That's a sync, not a write. I would first try to run the
>>already-installed TP with elevated privileges. You can specify that
>>using a shortcut where in its properties under Shortcut tab -> Advanced
>>you enable the "Run as administrator" option. If you're not using a
>>shortcut, load the command shell with elevated privileges, and navigate
>>to and run the .exe program for TP.
>
>Speaking to you now, having started the Connect part of TP with Run as
>administrator ...
>>
>>Come back to say if elevating privileges for TP resolves the problem.
>
>... and it did indeed really correct the clock when it said it was doing
>so. So if I'm ever worried about it in future, I know what to do.

Excellent, because I wasn't able to spend enough time with TP to figure out how
to use the darned thing. :)

On Tue, 25 Jul 2023 07:20:57 -0400, Paul <nospam@needed.invalid>
wrote:

>On 7/25/2023 3:55 AM, lisa wrote:
>> On Mon, 24 Jul 2023 13:30:49 +0100, "J. P. Gilliver"
>> <G6JPG@255soft.uk> wrote:
>>
>>> Is there a setting that needs to be changed from its default, to allow
>>> applications to change the system time?
>>
>> the program I used ( neutron ) needs to run as admin.
>>
>
>This is why NTP runs as NTPD (like, a SVCHOST, a daemon,
>rather than run as a Ring 3 application).
>
>You are not supposed to be elevating everything you
>run in Ring 3 to administrator. It defeats the <cough>
>security model.

neutron doesn't run as background program.
I have to start it manually and it stops after one run. After it has
finished you don't see it running or active in a program like
proceshacker. And elevating everything I run to admin? No thank you.
Keep it simple.

On 25/07/2023 11:07, JJ wrote:
> Windows 7 requires elevated rights to change the system time. So make sure
> the application is run elevated.

+1

But I wouldn't recommend running Turnpike with elevated privileges. It
does too much other stuff.

--
Brian Gregory (in England).

In message <kitg9aFn0f6U1@mid.individual.net> at Tue, 1 Aug 2023
23:46:02, Brian Gregory <void-invalid-dead-dontuse@email.invalid> writes
>On 25/07/2023 11:07, JJ wrote:
>> Windows 7 requires elevated rights to change the system time. So make sure
>> the application is run elevated.
>
>+1
>
>But I wouldn't recommend running Turnpike with elevated privileges. It
>does too much other stuff.
>
Agreed. I did try it, and it did indeed correct the time. But I normally
don't.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"We're plumbing shallows we didn't know existed here" - Jeremy Paxman (as
quizmaster of "University Challenge"), 1998 (when losing team suddenly put on a
spurt by showing knowledge of things like the Eurovision Song Contest ...)