Bert Gøtterup Petersen wrote:
> I have compiled NTP 4.2.2p for Windows, but it also shows the same spikes.

If you compiled ntp4.2.2 for Windows are there any chances to make it
public ? I need a new version of ntp, as the version 4.2.0b didn't work
for me.

Thanks !

Bert Gøtterup Petersen wrote:
> When running Windows I see a spike of about 16ms in the loopstats-files on
> all the Windows nodes.
> The peculiar thing is that the spike occurs every 24 hours and 15 minutes
> per machine, but not at the same time on different machines.

Hmmm. Could this be an internal windows OS counter wrapping around?

24 hours + 15 min = 86400 + 900 = 87300 s

The original keyboard timer chip which generates the Dos 55 ms timer
tick had a 64 K period which was close to but not exactly one hour...

87300 / (24 * 65536) = 0.055038

Yes! This is the original DOS timer tick period which Windows is still
emulating for anything running inside a Dos box, as well as programs
using very old Windows APIs.

I'm willing to bet that the spike is caused by a once/day fixup of any
residual errors caused by the fact that this emulation isn't totally
accurate!

Terje
--
-
"almost all programming can be viewed as an exercise in caching"

Eugen,

Eugen COCA wrote:
> Bert Gøtterup Petersen wrote:
>> I have compiled NTP 4.2.2p for Windows, but it also shows the same
>> spikes.
>
> If you compiled ntp4.2.2 for Windows are there any chances to make it
> public ? I need a new version of ntp, as the version 4.2.0b didn't work
> for me.

Neither the current -stable nor the -dev version of ntpd are stable under
Windows, that's why Meinberg has not yet made a new GUI installer version
available.

If the xmas edition is also not stable on your machine (on most systems it
is, but we've also heard about some where it isn't) you should downgrade to
the fluxcap version which Heiko has recently made available for download:
http://www.meinberg.de/english/sw/ntp.htm#ntp_nt

This version has been pretty stable, and Heiko has merged in some newer
patches (MM timer ..) to build the fluxcap version.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Hi

I didn't think NTP used old timers like that...

Any idea on how to avoid this?

Bert

"Terje Mathisen" wrote in message
news:c4p4t3-ivr.ln1@osl016lin.hda.hydro.com...
> Bert Gøtterup Petersen wrote:
>> When running Windows I see a spike of about 16ms in the loopstats-files
>> on all the Windows nodes. The peculiar thing is that the spike occurs
>> every 24 hours and 15 minutes per machine, but not at the same time on
>> different machines.
>
> Hmmm. Could this be an internal windows OS counter wrapping around?
>
> 24 hours + 15 min = 86400 + 900 = 87300 s
>
> The original keyboard timer chip which generates the Dos 55 ms timer tick
> had a 64 K period which was close to but not exactly one hour...
>
> 87300 / (24 * 65536) = 0.055038
>
> Yes! This is the original DOS timer tick period which Windows is still
> emulating for anything running inside a Dos box, as well as programs using
> very old Windows APIs.
>
> I'm willing to bet that the spike is caused by a once/day fixup of any
> residual errors caused by the fact that this emulation isn't totally
> accurate!
>
> Terje
> --
> -
> "almost all programming can be viewed as an exercise in caching"

Bert,

Bert Gøtterup Petersen wrote:

> Hi
>
> I didn't think NTP used old timers like that...
>
> Any idea on how to avoid this?

Do you have ntpd running with the -M option? Otherwise if another programs
ist run which modifies the Windows Multimedia Timer you will observe time
steps like this.

Unfortunately you don't write which exact version you have installed. There
have been quite a few version each of which started with "4.2.0a@...".
Both NTP versions which are currently available on our download page at
http://www.meinberg.de/english/sw/ntp.htm#ntp_nt
support the -M option and use it by default.

Another possible reason would be another program which is run once per day
and either tweaks the system time, or runs a task which lets the Windows
clock loose a timer tick (which is about 16 milliseconds).

We've had a customer where the Windows system time had lost 30 seconds (!)
every night when his database application ran some maintenance tasks.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin

Origionally I used your ntp-4.2.0b@1.1436mbg-xmas-o-win32-setup version.

Today I started a client with the 'old' version
ntp-4.2.0a@mbg-fluxcap-o-win32-setup.
I expect to be able to report back tomorrow if the spike disapeared.

These are test PC, so in fact they do nothing when we are not there, yet we
see the spikes also in the weekends.
We have been monitoring the systems, but without seeing any processes being
started around the particular time.
Also monitoring the network trafic showed no special activity.

To add to my somewhat confused picture of the situation (sorry about that),
I have observed that the problem
disapeared on an IBM laptop after it was rebooted.

Bert


"Martin Burnicki" wrote in message
news:i2i5t3-j21.ln1@gateway.py.meinberg.de...
> Bert,
>
> Bert Gøtterup Petersen wrote:
>
>> Hi
>>
>> I didn't think NTP used old timers like that...
>>
>> Any idea on how to avoid this?
>
> Do you have ntpd running with the -M option? Otherwise if another programs
> ist run which modifies the Windows Multimedia Timer you will observe time
> steps like this.
>
> Unfortunately you don't write which exact version you have installed.
> There
> have been quite a few version each of which started with "4.2.0a@...".
> Both NTP versions which are currently available on our download page at
> http://www.meinberg.de/english/sw/ntp.htm#ntp_nt
> support the -M option and use it by default.
>
> Another possible reason would be another program which is run once per day
> and either tweaks the system time, or runs a task which lets the Windows
> clock loose a timer tick (which is about 16 milliseconds).
>
> We've had a customer where the Windows system time had lost 30 seconds (!)
> every night when his database application ran some maintenance tasks.
>
> Martin
> --
> Martin Burnicki
>
> Meinberg Funkuhren
> Bad Pyrmont
> Germany

Bert Gøtterup Petersen wrote:
> Hi
>
> I didn't think NTP used old timers like that...

NTP isn't!

This is an OS/Windows HAL layer bug.

> Any idea on how to avoid this?

Replace the OS?
:-)

Terje
>
> Bert
>
> "Terje Mathisen" wrote in message
> news:c4p4t3-ivr.ln1@osl016lin.hda.hydro.com...
>> Bert Gøtterup Petersen wrote:
>>> When running Windows I see a spike of about 16ms in the loopstats-files
>>> on all the Windows nodes. The peculiar thing is that the spike occurs
>>> every 24 hours and 15 minutes per machine, but not at the same time on
>>> different machines.
>> Hmmm. Could this be an internal windows OS counter wrapping around?
>>
>> 24 hours + 15 min = 86400 + 900 = 87300 s
>>
>> The original keyboard timer chip which generates the Dos 55 ms timer tick
>> had a 64 K period which was close to but not exactly one hour...
>>
>> 87300 / (24 * 65536) = 0.055038
>>
>> Yes! This is the original DOS timer tick period which Windows is still
>> emulating for anything running inside a Dos box, as well as programs using
>> very old Windows APIs.
>>
>> I'm willing to bet that the spike is caused by a once/day fixup of any
>> residual errors caused by the fact that this emulation isn't totally
>> accurate!
>>
>> Terje
>> --
>> -
>> "almost all programming can be viewed as an exercise in caching"
>
>


--
-
"almost all programming can be viewed as an exercise in caching"

Martin,

I am sad to have to report to you, that the 'old' fluxcap version also has
this problem.
Any idears for even older version I could try, or suggestions to where to
look for the cause.

I have monitored a system during a spike with the Microsoft tool TraceView
from their DDK package .
But it will take some time to work my way through the 50k entries...
Any suggestions, what I should look for?

Thanks
Bert

"Bert Gøtterup Petersen" wrote in message
news:45002682$0$3496$edfadb0f@dread11.news.tele.dk ...
> Martin
>
> Origionally I used your ntp-4.2.0b@1.1436mbg-xmas-o-win32-setup version.
>
> Today I started a client with the 'old' version
> ntp-4.2.0a@mbg-fluxcap-o-win32-setup.
> I expect to be able to report back tomorrow if the spike disapeared.
>
> These are test PC, so in fact they do nothing when we are not there, yet
> we see the spikes also in the weekends.
> We have been monitoring the systems, but without seeing any processes
> being started around the particular time.
> Also monitoring the network trafic showed no special activity.
>
> To add to my somewhat confused picture of the situation (sorry about
> that), I have observed that the problem
> disapeared on an IBM laptop after it was rebooted.
>
> Bert
>
>
> "Martin Burnicki" wrote in message
> news:i2i5t3-j21.ln1@gateway.py.meinberg.de...
>> Bert,
>>
>> Bert Gøtterup Petersen wrote:
>>
>>> Hi
>>>
>>> I didn't think NTP used old timers like that...
>>>
>>> Any idea on how to avoid this?
>>
>> Do you have ntpd running with the -M option? Otherwise if another
>> programs
>> ist run which modifies the Windows Multimedia Timer you will observe time
>> steps like this.
>>
>> Unfortunately you don't write which exact version you have installed.
>> There
>> have been quite a few version each of which started with "4.2.0a@...".
>> Both NTP versions which are currently available on our download page at
>> http://www.meinberg.de/english/sw/ntp.htm#ntp_nt
>> support the -M option and use it by default.
>>
>> Another possible reason would be another program which is run once per
>> day
>> and either tweaks the system time, or runs a task which lets the Windows
>> clock loose a timer tick (which is about 16 milliseconds).
>>
>> We've had a customer where the Windows system time had lost 30 seconds
>> (!)
>> every night when his database application ran some maintenance tasks.
>>
>> Martin
>> --
>> Martin Burnicki
>>
>> Meinberg Funkuhren
>> Bad Pyrmont
>> Germany
>
>

Bert "Gøtterup Petersen" wrote:
[]
> When running Windows I see a spike of about 16ms in the
> loopstats-files on all the Windows nodes.

Have you enabled the multi-media timer? You shoudl do this.

Cheers,
David

Bert Gøtterup Petersen wrote:
> Martin,
>
> I am sad to have to report to you, that the 'old' fluxcap version
> also has this problem.
> Any idears for even older version I could try, or suggestions to
> where to look for the cause.
>
> I have monitored a system during a spike with the Microsoft tool
> TraceView from their DDK package .
> But it will take some time to work my way through the 50k entries...
> Any suggestions, what I should look for?
>
> Thanks
> Bert

Enable the multi-media timers.

David

Bert,

Bert Gøtterup Petersen wrote:
> Martin,
>
> I am sad to have to report to you, that the 'old' fluxcap version also has
> this problem.
> Any idears for even older version I could try, or suggestions to where to
> look for the cause.

Both the fluxcap version and the xmas version can modify the multimedia
timer, if the -M option is given on the command line. Is this the case in
your environment? You can check this using the service control manager, the
-M option should be listed behind the ntpd.exe path in the properties page.

If the -M option is there and time steps still happen then the time steps
don't seem to be related to the MM timer stuff. There must be another
reason, maybe a bad driver, another piece of software which modifies the
system time, etc.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin,

I have checked the service control manager, and I do use the -M option.
As you stated earlier it there by default in the Meinberg installation.

Bert

"Martin Burnicki" wrote in message
news:t3uit3-jrc.ln1@gateway.py.meinberg.de...
> Bert,
>
> Bert Gøtterup Petersen wrote:
>> Martin,
>>
>> I am sad to have to report to you, that the 'old' fluxcap version also
>> has
>> this problem.
>> Any idears for even older version I could try, or suggestions to where to
>> look for the cause.
>
> Both the fluxcap version and the xmas version can modify the multimedia
> timer, if the -M option is given on the command line. Is this the case in
> your environment? You can check this using the service control manager,
> the
> -M option should be listed behind the ntpd.exe path in the properties
> page.
>
> If the -M option is there and time steps still happen then the time steps
> don't seem to be related to the MM timer stuff. There must be another
> reason, maybe a bad driver, another piece of software which modifies the
> system time, etc.
>
> Martin
> --
> Martin Burnicki
>
> Meinberg Funkuhren
> Bad Pyrmont
> Germany

Bert,

Bert Gøtterup Petersen wrote:

> Martin,
>
> I have checked the service control manager, and I do use the -M option.
> As you stated earlier it there by default in the Meinberg installation.

OK, so NTP shouldn't be to blame on this.

I'll see whether I can send you a little tool by mail which may help find
out what's happening.

Martin
--
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany