centerclick / feedback

Issues, Bug Reports, and Feature Requests
7 stars 0 forks source link

NTP250 and Windows 11 #87

Closed ncwolfie closed 1 year ago

ncwolfie commented 1 year ago

NTP250 works perfectly after a re-image. I am stumbling though on how to make a windows 11 desktop sync the time with the ntp250 (on my LAN) more frequently than 1024 seconds. 15 to 20 seconds would be ideal for astronomical tracking. I've googled it to death but can't seem to get by the windows minimum time of 1024. What am I missing?

Thanks in advance for any advice.

dave4445 commented 1 year ago

See MinPollInterval and MaxPollInterval registry settings at Configuring Systems for High Accuracy

tlhackque commented 1 year ago

It shouldn't be necessary to sync time very frequently; this indicates another issue. Frequent syncing may paper it over, but it won't do a good job.

The goal of NTP is to account for drift, which with good history, it does. Excursions can be caused by environment, system load (especially in a VM), bugs, or configuration.

I'm not sure how good the current windows implementation of W32Time is. It used to be, well, not good.

Things to consider:

Let your windows system run for a long time to see if it converges.

Consider using Meinberg NTP for windows, which is a port of the NTPD daemon's reference implementation for windows. There's also a monitor that will show you how well time is tracking. It has graphs and (with ntpd) will keep long-term stats across reboots; I had several years worth at one point.

You can use the graphs to correlate excursions with system, network, and/or environment activity/changes.

If you're really fussy (or unlucky), you may want to look at the environment of your windows system. Some (especially, but not exclusively) low-end systems have marginal timekeeping circuits - temperature sensitivity is not uncommon.

Also look at what you have set for power management settings.

ntp.org and nwtime.org have additional resources.

ncwolfie commented 1 year ago

Thanks Dave, That was exactly what I was looking for and seems to have done what I need. I realize it is a rather unusual request and would normally be an indicator of a system issue. For normal operations checking my time daily or less is completely satisfactory. However for near earth asteroid tracking, even the smallest errors in correct UTC can and do start to skew results. With observations coming in of recently discovered NEAs from people all over the world, those small errors in time begin to add up in determining orbital precision. So recently the Minor Planet Center and IAWN have begun encouraging observers to tighten up their time and positional errors. Many of the large observatories have the funding for in house time servers and is not really a big issue, but even some of those are going the extra mile to tighten up their reported times. Smaller observatories like myself and others look at more cost effective means like raspberry pi with time hat solutions or in my case the ntp250. I prefer the out of the box solution of the ntp250 and I am hoping that with a backup pool, this will serve my tracking sessions very well. It seems that it would be an ideal solution for small observatories like myself. Thanks again for the assistance.

tlhackque commented 1 year ago

It's a common misconception that more frequent polling increases accuracy.

More frequent polling will not increase accuracy, and may make things worse. The NTP250 server should be a solid reference. If your system is diverging from it in ways that the standard ntp algorithms / frequency can't correct, you need to address the cause.

Depending on the issue,, look for environment changes, task priorities on the system, lots of other things to check. If the environment is controlled, you should only see drift, and that's best addressed with long-term corrections. Jitter is a result of environment; polling won't help.

Unless the real issues are addressed, all that frequent polling will do is to create a sawtooth of divergence.

Properly configured, the backup pool has little to do with accuracy - should be nothing if the NTP250 is set 'prefer". All it does is to serve as a sanity check on the NTP250, and fill in should the NTP250 lose lock or go down.

Happy stargazing.