Meinberg's NTP Software Initialization

[W. eWatson]

As I've again begun to use the Subject software, I've found it can jump
many minutes (roughly 30) in a period of days. I really cannot pin point
the jump or even if it's a smooth transition. This has happened several
times.

I had set it set it up using either Start NTP or Restart NTP, more
likely the former, around Feb. 1, and found it was about 30 min ahead on
the 12th. Is there some difference between Start and Restart that might
cause the change?

XP Pro.

 

[Nil]

As I've again begun to use the Subject software, I've found it can
jump many minutes (roughly 30) in a period of days. I really
cannot pin point the jump or even if it's a smooth transition.
This has happened several times.

I had set it set it up using either Start NTP or Restart NTP, more
likely the former, around Feb. 1, and found it was about 30 min
ahead on the 12th. Is there some difference between Start and
Restart that might cause the change?

XP Pro.

This sounds like an issue with the Meinberg software, not an XP issue.
You should check with them.

 

[VanguardLH]

As I've again begun to use the Subject software, I've found it can jump
many minutes (roughly 30) in a period of days. I really cannot pin point
the jump or even if it's a smooth transition. This has happened several
times.

I had set it set it up using either Start NTP or Restart NTP, more
likely the former, around Feb. 1, and found it was about 30 min ahead on
the 12th. Is there some difference between Start and Restart that might
cause the change?

XP Pro.

Depends on what you are running on your host. Before Windows or an OS
loads, the RTM chip supplies the clock on your motherboard. If its
clock is getting off then it's time to replace the CMOS/clock battery.
Once the OS loads, it uses its own clock algorithm which can be affected
(thrown) off by continual high CPU usage (i.e., high priority or CPU
intensive tasks).

You never mention if you are power cycling your host. If it is powered
on 24x7 and getting off that much with the use of a time synchronization
utility then there is a problem with that utility or your configuration
of it regarding which NTP server to which it connects (maybe those NTP
servers aren't available anymore). I don't use the one you mentioned.
Mine tests which are the top 5 NTP servers out of a long list and, over
time, may change to using a faster (less latency) NTP server. However,
many NTP sites listed in the install-time provided hosts list are dead
and long gone (i.e., the list doesn't get updated). So I had to edit
the list and add in some more NTP servers. The time sync tool
(Socketwatch) checks which is the faster NTP server for *me* which is
not necessarily the one that is the physically closest or has the fewest
hops. I had to edit its NTP server list to get rid of the dead ones so
it didn't waste time trying to contact them.

 

[W. eWatson]

Depends on what you are running on your host. Before Windows or an OS
loads, the RTM chip supplies the clock on your motherboard. If its
clock is getting off then it's time to replace the CMOS/clock battery.
Once the OS loads, it uses its own clock algorithm which can be affected
(thrown) off by continual high CPU usage (i.e., high priority or CPU
intensive tasks).

You never mention if you are power cycling your host. If it is powered
on 24x7 and getting off that much with the use of a time synchronization
utility then there is a problem with that utility or your configuration
of it regarding which NTP server to which it connects (maybe those NTP
servers aren't available anymore). I don't use the one you mentioned.
Mine tests which are the top 5 NTP servers out of a long list and, over
time, may change to using a faster (less latency) NTP server. However,
many NTP sites listed in the install-time provided hosts list are dead
and long gone (i.e., the list doesn't get updated). So I had to edit
the list and add in some more NTP servers. The time sync tool
(Socketwatch) checks which is the faster NTP server for *me* which is
not necessarily the one that is the physically closest or has the fewest
hops. I had to edit its NTP server list to get rid of the dead ones so
it didn't waste time trying to contact them.

I suppose it might be the h/w. I think I'll not use it and see if it
fouls up. I just noticed that it was 20 minutes off after only 3 days.

 

[W. eWatson]

....

I suppose it might be the h/w. I think I'll not use it and see if it
fouls up. I just noticed that it was 20 minutes off after only 3 days.

Interestingly, I re-booted the computer, and it came up with exactly the
correct time. I did not start Meinberg. I do not think Meinberg is part
of my start up procedure. How would I tell anyway?

 

[VanguardLH]

...

Interestingly, I re-booted the computer, and it came up with exactly the
correct time. I did not start Meinberg. I do not think Meinberg is part
of my start up procedure. How would I tell anyway?

I doubt you'll find a large audience here that is experienced with that
particular NTP client. Look at its options to tell if it has an
auto-start setting to load it on Windows startup or on login.
Otherwise, use msconfig.exe to go look at the startup items.
SysInternals has an AutoRuns utility that shows you startup items that
msconfig doesn't list.

If the software is screwing up but the hardware is okay, why did you
leave the software installed?

 

[W. eWatson]

I doubt you'll find a large audience here that is experienced with that
particular NTP client. Look at its options to tell if it has an
auto-start setting to load it on Windows startup or on login.
Otherwise, use msconfig.exe to go look at the startup items.
SysInternals has an AutoRuns utility that shows you startup items that
msconfig doesn't list.

If the software is screwing up but the hardware is okay, why did you
leave the software installed?

Maybe there's an NTP NG?

What is SysInternals? I presume you mean options in the software package.

Installed? Of course, it's installed. How could it be otherwise, nor
exist on my machine in any form?

My question is simply does the software fire up at boot time, and if so
how do I prevent it? Which you've pretty much answered.