Folks,

I run a number of NTP systems based on Windows, and normally all but the 
Windows 2000 Workstation keep good time.  In particular, the Windows XP 
SP2 system kept good time until about 14:00 UTC on Friday 2nd December.

  http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html

I asked myself what changed on the system and, as far as I know, the 
answer is nothing!  Around that time, I was developing a program for 
processing large images, and fed it an image which was too large.  Perhaps 
coincidental - perhaps not.  The pagefile size is fixed at 2GB and seems 
to still be the same.  I wondered if disk I/O had become switched from 
UDMA to PIO, but its seems not.  I've checked for spyware and neither 
SpyBot nor AdAware find anything other than cookies.  I don't see anything 
unusual in Services.  I even did a system restore to around 12:58 (IIRC) 
on the day in question, but this didn't cure the problem.

I'm stuck!  Can you help?  Why would an otherwise good timekeeper become 
degraded in this way?  The jitter figures (from ntpq -p) are in the 10 - 
15 millisecond range, even for servers on the LAN, whereas other PCs on 
the same LAN show jitter under a millisecond.  Lan traffic looks normal, 
though.  The delay figures look normal as well.

Any ideas?  (no, replacing XP is not an option!).

Thanks,
David 

Tom Smith wrote:
> The high jitter numbers may just be because of that system's
> own instability.
>
> Have you checked the current drift rate? That might have gotten
> disrupted, especially if there was network activity involved in your
> experiment. Try the ntpq command "rv 0" or "ntpdc -c loopinfo" and
> look for the frequency. It should have an absolute value of under 100. 
> If
> it's several hundred, you may need to re-initialize NTP by stopping
> it, deleting the drift file, and then restarting it. In any case,
> sample it periodically and see if it is oscillating.
>
> Any network related changes at that time, for example, on a switch?
> If it's fast ethernet, maybe you've renegotiated or otherwise
> acquired a mismatched speed/mode and you're now suffering packet
> losses. You might want to look at "netstat -e -s" and see if you have
> a significant number of errors or see if the "reach" output from
> "ntpq -p" looks different on this system than on others.
> -Tom


Tom,

Many thanks for your thoughtful suggestions.

It looks as if the drift is OK, at -64.911, but I will keep an eye on it. 
Here is the full output just in case there's something else glaringly 
obvious:

E:\>ntpq -c "rv 0" odin
status=46b4 leap_add_sec, sync_ntp, 11 events, event_peer/strat_chg,
version="ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1)", processor="unknown",
system="WINDOWS/NT", leap=01, stratum=3, precision=-19,
rootdelay=62.583, rootdispersion=125.847, peer=62645, refid=192.168.0.1,
reftime=c73d5d1a.a4d239b4  Sun, Dec  4 2005 12:18:34.643, poll=7,
clock=c73d5f43.da3d1265  Sun, Dec  4 2005 12:27:47.852, state=4,
offset=18.583, frequency=-64.911, jitter=10.097, stability=0.028

There were no network changes I am aware of (it's just a small internal 
network, run by me....), and I don't recognise anything significant in the 
way of errors from the netstat command.  I do wonder about:

IPv4 Statistics, Received Address Errors = 2683

UDP Statistics for IPv4, No Ports = 6006

The system had been up for about 40 minutes.

Any comments?


E:\>netstat -e -s
Interface Statistics

                           Received            Sent

Bytes                     651081749        37472592
Unicast packets              484130          282526
Non-unicast packets            3741             999
Discards                          0               0
Errors                            0               0
Unknown protocols                 0

IPv4 Statistics

  Packets Received                   = 487302
  Received Header Errors             = 0
  Received Address Errors            = 2683
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 14
  Received Packets Delivered         = 487288
  Output Requests                    = 283475
  Routing Discards                   = 0
  Discarded Output Packets           = 0
  Output Packet No Route             = 0
  Reassembly Required                = 0
  Reassembly Successful              = 0
  Reassembly Failures                = 0
  Datagrams Successfully Fragmented  = 0
  Datagrams Failing Fragmentation    = 0
  Fragments Created                  = 0

ICMPv4 Statistics

                            Received    Sent
  Messages                  12          9
  Errors                    0           0
  Destination Unreachable   0           1
  Time Exceeded             0           0
  Parameter Problems        0           0
  Source Quenches           0           0
  Redirects                 0           0
  Echos                     0           8
  Echo Replies              12          0
  Timestamps                0           0
  Timestamp Replies         0           0
  Address Masks             0           0
  Address Mask Replies      0           0

TCP Statistics for IPv4

  Active Opens                        = 153
  Passive Opens                       = 72
  Failed Connection Attempts          = 2
  Reset Connections                   = 127
  Current Connections                 = 20
  Segments Received                   = 482918
  Segments Sent                       = 281457
  Segments Retransmitted              = 5

UDP Statistics for IPv4

  Datagrams Received    = 1910
  No Ports              = 6006
  Receive Errors        = 0
  Datagrams Sent        = 1867

E:\>

Thanks,
David 

The high jitter numbers may just be because of that system's
own instability.

Have you checked the current drift rate? That might have gotten
disrupted, especially if there was network activity involved in your
experiment. Try the ntpq command "rv 0" or "ntpdc -c loopinfo" and look
for the frequency. It should have an absolute value of under 100. If it's
several hundred, you may need to re-initialize NTP by stopping it,
deleting the drift file, and then restarting it. In any case,
sample it periodically and see if it is oscillating.

Any network related changes at that time, for example, on a switch? If it's
fast ethernet, maybe you've renegotiated or otherwise acquired a mismatched
speed/mode and you're now suffering packet losses. You might want to look at
"netstat -e -s" and see if you have a significant number of errors or see if
the "reach" output from "ntpq -p" looks different on this system than on others.

-Tom

David J Taylor wrote:
> Folks,
> 
> I run a number of NTP systems based on Windows, and normally all but the 
> Windows 2000 Workstation keep good time.  In particular, the Windows XP 
> SP2 system kept good time until about 14:00 UTC on Friday 2nd December.
> 
>   http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html
> 
> I asked myself what changed on the system and, as far as I know, the 
> answer is nothing!  Around that time, I was developing a program for 
> processing large images, and fed it an image which was too large.  Perhaps 
> coincidental - perhaps not.  The pagefile size is fixed at 2GB and seems 
> to still be the same.  I wondered if disk I/O had become switched from 
> UDMA to PIO, but its seems not.  I've checked for spyware and neither 
> SpyBot nor AdAware find anything other than cookies.  I don't see anything 
> unusual in Services.  I even did a system restore to around 12:58 (IIRC) 
> on the day in question, but this didn't cure the problem.
> 
> I'm stuck!  Can you help?  Why would an otherwise good timekeeper become 
> degraded in this way?  The jitter figures (from ntpq -p) are in the 10 - 
> 15 millisecond range, even for servers on the LAN, whereas other PCs on 
> the same LAN show jitter under a millisecond.  Lan traffic looks normal, 
> though.  The delay figures look normal as well.
> 
> Any ideas?  (no, replacing XP is not an option!).
> 
> Thanks,
> David 
> 
> 

Tom Smith wrote:
[]
> I guess the good news here is that the offset and frequency are
> opposite signs, so it is trying to correct itself. The offset also
> seems (at the moment) to be smaller than the worst you've seen in the
> last few days. Someone will probably tell you to upgrade to 4.2.0a or
> b.
> I notice that the leap bit is set. Just noting it for anybody
> who wants to run with that.

Tom,

Many thanks for your comments on the NTP diagnostics, and the network 
statistics.  At least I now know more about where the problem is unlikely 
to be!

David 

David J Taylor wrote:
> Tom,
> 
> Many thanks for your thoughtful suggestions.
> 
> It looks as if the drift is OK, at -64.911, but I will keep an eye on it. 
> Here is the full output just in case there's something else glaringly 
> obvious:
> 
> E:\>ntpq -c "rv 0" odin
> status=46b4 leap_add_sec, sync_ntp, 11 events, event_peer/strat_chg,
> version="ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1)", processor="unknown",
> system="WINDOWS/NT", leap=01, stratum=3, precision=-19,
> rootdelay=62.583, rootdispersion=125.847, peer=62645, refid=192.168.0.1,
> reftime=c73d5d1a.a4d239b4  Sun, Dec  4 2005 12:18:34.643, poll=7,
> clock=c73d5f43.da3d1265  Sun, Dec  4 2005 12:27:47.852, state=4,
> offset=18.583, frequency=-64.911, jitter=10.097, stability=0.028

I guess the good news here is that the offset and frequency are
opposite signs, so it is trying to correct itself. The offset also
seems (at the moment) to be smaller than the worst you've seen in the
last few days. Someone will probably tell you to upgrade to 4.2.0a or b.

I notice that the leap bit is set. Just noting it for anybody
who wants to run with that.

> 
> There were no network changes I am aware of (it's just a small internal 
> network, run by me....), and I don't recognise anything significant in the 
> way of errors from the netstat command.  I do wonder about:
> 
> IPv4 Statistics, Received Address Errors = 2683

These are packets arriving addressed to an address not valid
for this system. Packets addressed to 0.0.0.0 fall into this
slot, as do packets addressed somewhere else and routed via
this system if this system is not, in fact, a router.

> 
> UDP Statistics for IPv4, No Ports = 6006

These are packets arriving for a port at which there is no
listener. Probes for a service that is not running, for example.

> 
> The system had been up for about 40 minutes.
> 
> Any comments?
> 
> 
> E:\>netstat -e -s
> Interface Statistics
> 
>                            Received            Sent
> 
> Bytes                     651081749        37472592
> Unicast packets              484130          282526
> Non-unicast packets            3741             999
> Discards                          0               0
> Errors                            0               0
> Unknown protocols                 0
> 
> IPv4 Statistics
> 
>   Packets Received                   = 487302
>   Received Header Errors             = 0
>   Received Address Errors            = 2683
>   Datagrams Forwarded                = 0
>   Unknown Protocols Received         = 0
>   Received Packets Discarded         = 14
>   Received Packets Delivered         = 487288
>   Output Requests                    = 283475
>   Routing Discards                   = 0
>   Discarded Output Packets           = 0
>   Output Packet No Route             = 0
>   Reassembly Required                = 0
>   Reassembly Successful              = 0
>   Reassembly Failures                = 0
>   Datagrams Successfully Fragmented  = 0
>   Datagrams Failing Fragmentation    = 0
>   Fragments Created                  = 0
> 
> ICMPv4 Statistics
> 
>                             Received    Sent
>   Messages                  12          9
>   Errors                    0           0
>   Destination Unreachable   0           1
>   Time Exceeded             0           0
>   Parameter Problems        0           0
>   Source Quenches           0           0
>   Redirects                 0           0
>   Echos                     0           8
>   Echo Replies              12          0
>   Timestamps                0           0
>   Timestamp Replies         0           0
>   Address Masks             0           0
>   Address Mask Replies      0           0
> 
> TCP Statistics for IPv4
> 
>   Active Opens                        = 153
>   Passive Opens                       = 72
>   Failed Connection Attempts          = 2
>   Reset Connections                   = 127
>   Current Connections                 = 20
>   Segments Received                   = 482918
>   Segments Sent                       = 281457
>   Segments Retransmitted              = 5
> 
> UDP Statistics for IPv4
> 
>   Datagrams Received    = 1910
>   No Ports              = 6006
>   Receive Errors        = 0
>   Datagrams Sent        = 1867
> 
> E:\>
> 
> Thanks,
> David 
> 
> 

David,

my advice is to switch to version 4.2.0a / 2005. I had some problems
with offset and/or jitter with 4.2.0 /2003 version under Win/2k server.

The Windows 4.2.0b - Meinberg does not work well for me (the PC hankgs
up after starting the service).

I made numerous and various tests with NTP on Windows and FreeBSD
operating systems. On Windows, behaviours like Odin show, where only
when CPU load was over 80 percent for long periods (e.g. when making an
Windows Update or when viewing a large PDF file with Acrobat). The CPU
load may be one possible cause.

Looking at the graphs from the Odin server I wonder how is the offset
measured (relative to what server). The actual behaviour is more
realistic for a "heavy interactive" PC than the old ones (with only
several milliseconds error). A Win2k server with no user interraction
have a 5 to 20 ms offset errors (depending on the network delays, room
temperature (!!!), mains voltage (!!!), and others). With moderate user
interraction the errors are between 30 and 100ms and with heavy user
interractions the errors where sometimes more than 300-800ms. Very
strange, on a Linux Mandrake systems (dual processor, a lot of RAM) on
periods with high CPU loads the offsets where more than 500-800ms.

I'm really interested with your problem and the possible cause !

David J Taylor wrote:

>Folks,
>
>I run a number of NTP systems based on Windows, and normally all but the 
>Windows 2000 Workstation keep good time.  In particular, the Windows XP 
>SP2 system kept good time until about 14:00 UTC on Friday 2nd December.
>
>  http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html
>
>I asked myself what changed on the system and, as far as I know, the 
>answer is nothing!  Around that time, I was developing a program for 
>processing large images, and fed it an image which was too large.  Perhaps 
>coincidental - perhaps not.  The pagefile size is fixed at 2GB and seems 
>to still be the same.  I wondered if disk I/O had become switched from 
>UDMA to PIO, but its seems not.  I've checked for spyware and neither 
>SpyBot nor AdAware find anything other than cookies.  I don't see anything 
>unusual in Services.  I even did a system restore to around 12:58 (IIRC) 
>on the day in question, but this didn't cure the problem.
>
>I'm stuck!  Can you help?  Why would an otherwise good timekeeper become 
>degraded in this way?  The jitter figures (from ntpq -p) are in the 10 - 
>15 millisecond range, even for servers on the LAN, whereas other PCs on 
>the same LAN show jitter under a millisecond.  Lan traffic looks normal, 
>though.  The delay figures look normal as well.
>
>Any ideas?  (no, replacing XP is not an option!).
>
>Thanks,
>David 
>
>
>  
>
Do you have your systems configured to do "automatic updates".  If so, 
Microsoft may have installed a patch. . . .

Eugen COCA wrote:
> David,
>
> my advice is to switch to version 4.2.0a / 2005. I had some problems
> with offset and/or jitter with 4.2.0 /2003 version under Win/2k
> server.
>
> The Windows 4.2.0b - Meinberg does not work well for me (the PC hankgs
> up after starting the service).
>
> I made numerous and various tests with NTP on Windows and FreeBSD
> operating systems. On Windows, behaviours like Odin show, where only
> when CPU load was over 80 percent for long periods (e.g. when making
> an Windows Update or when viewing a large PDF file with Acrobat). The
> CPU load may be one possible cause.

Eugen,

Thanks for your suggestions.

I would try a different version of NTP, but this one has been working 100% 
correctly until 14:20 On Dec 02, and continues to work on the other 
systems.  You can see this from the weekly and monthly plots.  I used to 
have poor stability on this system until upgrading to Windows XP SP2, and 
others have seen a similar behaviour.  It is as if something undid 
whatever change SP2 made.

It's possible that I did upgrade some software - many programs offer to do 
that for you on the fly - but I would have thought the system restore 
would have fixed that.  I also tried uninstalling QuickTime, as there is a 
suggestion that if the multi-media timer is enabled in Windows, that can 
cause these problems.  As yet, I haven't found out how to determine 
whether the multi-media timer is enabled, and if so, how to disable it.

The CPU load on the system hasn't changed either - it is well under 100% 
averaging, perhaps 15-20%.

David 

Richard B. Gilbert wrote:
[]
> Do you have your systems configured to do "automatic updates".  If so,
> Microsoft may have installed a patch. . . .

No.  I do install the updates but only when I wish to and under my 
supervision.  The system is normally up 24 x 7, so reboots would not be 
welcome.

Thanks for the suggestion, though,

I may have accidentally accepted an update for other software, though.

David 

Eugen COCA wrote:
> Looking at the graphs from the Odin server I wonder how is the offset
> measured (relative to what server). The actual behaviour is more
> realistic for a "heavy interactive" PC than the old ones (with only
> several milliseconds error). A Win2k server with no user interraction
> have a 5 to 20 ms offset errors (depending on the network delays, room
> temperature (!!!), mains voltage (!!!), and others). With moderate
> user interraction the errors are between 30 and 100ms and with heavy
> user interractions the errors where sometimes more than 300-800ms.
> Very strange, on a Linux Mandrake systems (dual processor, a lot of
> RAM) on periods with high CPU loads the offsets where more than
> 500-800ms.
>
> I'm really interested with your problem and the possible cause !

From the graphs here:

  http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

you can click on a PC and see the daily, weekly, monthly and yearly 
summaries.

Bacchus is a very old PC (by today's standards) and does show variation 
with temperature, but not more than 10 - 20ms per day.  Apart from that, 
it is a solid timekeeper.

Hermes runs Windows 2000 workstation and is absolutely solid.

Odin, until just after lunch on Friday, was fine.  It can't have been the 
introduction of the leap-second bit, can it?  I don't know how long that 
bit has been there.

Stamsund, Windows 2000 workstation, has always been variable but, you can 
see that when it is not used (during the night, all Thursday), it doesn't 
show jitter, but recovers towards a zero offset.  On the other hand, Odin 
has shown signs of jitter even during the night.  (Both Odin and Stamsund 
run a similar set of background tasks).

Yes, I would love to know what the problem is as well!

David 

David, is there possible to reveal the "server" section of the Odin ?
It isn't clear for me the references for the graphs shown there (the
graph plots the difference between your server, say Odin, and what
server) ?

Eugen COCA wrote:
> David, is there possible to reveal the "server" section of the Odin ?
> It isn't clear for me the references for the graphs shown there (the
> graph plots the difference between your server, say Odin, and what
> server) ?

Sorry for any confusion.  There is no "server section" to Odin, it is 
simply a PC which is an NTP client to a couple of Internet NTP servers, 
and a couple of local (LAN-side) NTP servers (Bacchus and Hermes).

The graphs show the output of the command:

ntpq -c rv  <host>

parsed by a Perl script which picks up the 21st comma-separated value - 
the offset=<value> pair.

This is documented here:

  http://www.david-taylor.myby.co.uk/ntp/NTPandMRTG.txt

David 

David,

I said about the "server" section in the ntpq.conf file - forgot to
mention. The offset is measured between your server and the reference
server. A good idea for testing is to have only one server for syncing
(the best / the more stable) and to mark the others by the option
"noselect". By looking at the graphs after this you may conclude if
there is an operating system problem or a network one (or maybe other
?).

Eugen COCA wrote:
> David,
>
> I said about the "server" section in the ntpq.conf file - forgot to
> mention. The offset is measured between your server and the reference
> server. A good idea for testing is to have only one server for syncing
> (the best / the more stable) and to mark the others by the option
> "noselect". By looking at the graphs after this you may conclude if
> there is an operating system problem or a network one (or maybe other
> ?).

The server for both Odin and Stamsund is Hermes.  Whilst they both have 
servers in their config, hermes is "prefer" and is normally what I see. 
Today, on Odin for example, NTP has been syncing from Hermes with no 
change since a reboot at 11:45 UTC.

David 

On Sun, 04 Dec 2005 17:20:41 +0000, David J Taylor wrote:

> 
> From the graphs here:
> 
>   http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

You did notice the spike on thursday. The reason for that spike could also
be the reason for your current trouble.

When it is not the computer that is causing the trouble, I would say it is
the network. Possible reasons could be:
* a half duplex device is talking to a full duplex device; 
* a switch that is nearly dead or equally a nearly dead network interface
card;
* an overloaded network link;
* badly inserted RJ45 connectors (just replug them all). 

Hope this new direction leads you to the solution of ypour problem.

> 
> you can click on a PC and see the daily, weekly, monthly and yearly
> summaries.
> 
> Odin, until just after lunch on Friday, was fine.  It can't have been
> the introduction of the leap-second bit, can it?  I don't know how long
> that bit has been there.
> 
> Yes, I would love to know what the problem is as well!
> 
> David

Johan

On Sun, 04 Dec 2005 21:19:06 +0100, Johan Swenker wrote:

> On Sun, 04 Dec 2005 17:20:41 +0000, David J Taylor wrote:

David,

are you sure Odin is not using its wireless interface?

Johan

> 
>> 
>> From the graphs here:
>> 
>>   http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html
> 
> You did notice the spike on thursday. The reason for that spike could also
> be the reason for your current trouble.
> 
> When it is not the computer that is causing the trouble, I would say it is
> the network. Possible reasons could be:
> * a half duplex device is talking to a full duplex device; 
> * a switch that is nearly dead or equally a nearly dead network interface
> card;
> * an overloaded network link;
> * badly inserted RJ45 connectors (just replug them all). 
> 
> Hope this new direction leads you to the solution of ypour problem.
> 
> Johan

David J Taylor wrote:
> Tom,
> 
> Many thanks for your thoughtful suggestions.
> 
> It looks as if the drift is OK, at -64.911, but I will keep an eye on it. 
> Here is the full output just in case there's something else glaringly 
> obvious:
> 
> E:\>ntpq -c "rv 0" odin
> status=46b4 leap_add_sec, sync_ntp, 11 events, event_peer/strat_chg,
> version="ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1)", processor="unknown",
> system="WINDOWS/NT", leap=01, stratum=3, precision=-19,
> rootdelay=62.583, rootdispersion=125.847, peer=62645, refid=192.168.0.1,
> reftime=c73d5d1a.a4d239b4  Sun, Dec  4 2005 12:18:34.643, poll=7,
> clock=c73d5f43.da3d1265  Sun, Dec  4 2005 12:27:47.852, state=4,
> offset=18.583, frequency=-64.911, jitter=10.097, stability=0.028
> 

Well the version is rather ancient. Time to trade up?

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Johan Swenker wrote:
> On Sun, 04 Dec 2005 17:20:41 +0000, David J Taylor wrote:
>
>>
>> From the graphs here:
>>
>>   http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html
>
> You did notice the spike on thursday. The reason for that spike could
> also be the reason for your current trouble.
>
> When it is not the computer that is causing the trouble, I would say
> it is the network. Possible reasons could be:
> * a half duplex device is talking to a full duplex device;
> * a switch that is nearly dead or equally a nearly dead network
> interface card;
> * an overloaded network link;
> * badly inserted RJ45 connectors (just replug them all).
>
> Hope this new direction leads you to the solution of your problem.

Thanks for that observation, Johan.  Thursday's events could well have 
been the cause, this is what happened (approximately):

- I looked at an animation - QuickTime said there was a newer version 
available.

- I downloaded the newer version

- on starting to install the newer version, I noted it installed iTunes

- as I have no need for iTunes, I stopped the install

Now perhaps this left things in a half installed, half not installed 
state?  Later, I did remove QuickTime entirely and re-install V6.5.2 (with 
no iTunes) from a file I already had on disk.

I did notice that suring the install a new service popped up and went 
away - IDT InstallDriver Table Manager.  It was started and stopped during 
the installation, and occurs only once during the entire event log 
history.

Thanks for your suggestions on the network, but other tests don't point 
that way.

David 

Johan Swenker wrote:
> On Sun, 04 Dec 2005 21:19:06 +0100, Johan Swenker wrote:
>
>> On Sun, 04 Dec 2005 17:20:41 +0000, David J Taylor wrote:
>
> David,
>
> are you sure Odin is not using its wireless interface?
>
> Johan

Yes, reasonably sure, see:

  http://www.david-taylor.myby.co.uk/mrtg/odin-wifi.html

and take not of the vertical scaling.  It's set as a peer-to-peer (AdHoc) 
network.

David 

Danny Mayer wrote:
> David J Taylor wrote:
>> Tom,
>>
>> Many thanks for your thoughtful suggestions.
>>
>> It looks as if the drift is OK, at -64.911, but I will keep an eye
>> on it. Here is the full output just in case there's something else
>> glaringly obvious:
>>
>> E:\>ntpq -c "rv 0" odin
>> status=46b4 leap_add_sec, sync_ntp, 11 events, event_peer/strat_chg,
>> version="ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1)", processor="unknown",
>> system="WINDOWS/NT", leap=01, stratum=3, precision=-19,
>> rootdelay=62.583, rootdispersion=125.847, peer=62645,
>> refid=192.168.0.1, reftime=c73d5d1a.a4d239b4  Sun, Dec  4 2005
>> 12:18:34.643, poll=7, clock=c73d5f43.da3d1265  Sun, Dec  4 2005
>> 12:27:47.852, state=4, offset=18.583, frequency=-64.911,
>> jitter=10.097, stability=0.028
>>
>
> Well the version is rather ancient. Time to trade up?
>
> Danny

OK, I accept that in principle, but:

- is there a known error in that version which would cause it to become 
unstable?  As the software had been OK until last Friday, why should it 
suddenly become not OK?  Would the arrival of a leap second indicator 
cause instability in one copy and yet other PCs continue to function 
correctly?  It doesn't sound right to me.

- which version would you suggest using?

- where to obtain it?  Given that:

  - Terje's most recent version is: ntp-dev-4.2.0a-20040319-nt.zip.

  - Meinberg's is a ready-to-install package, whereas I just want .exe 
files I can copy - the installation is already done.

  - I wouldn't trust compiling it myself.

Cheers,
David 

Here is the 4.2.0.a 2005 version from Meinberg, installed with just the
modified files. Copy over the ntp directory and restart the NTP
service. It is not necessary to reboot the machine.

http://ecoca.eed.usv.ro/ntp_4.2.0a.zip

Just type at the command prompt "net stop ntp", copy the files and then
"net start ntp" and it's done.

I guarantee for this files. You may find two ntpdc.exe files (renamed),
an orriginal one (not working so good) and the one from norloff,
working pretty well.

Eugen COCA wrote:
> Here is the 4.2.0.a 2005 version from Meinberg, installed with just
> the modified files. Copy over the ntp directory and restart the NTP
> service. It is not necessary to reboot the machine.
>
> http://ecoca.eed.usv.ro/ntp_4.2.0a.zip
>
> Just type at the command prompt "net stop ntp", copy the files and
> then "net start ntp" and it's done.
>
> I guarantee for this files. You may find two ntpdc.exe files
> (renamed), an orriginal one (not working so good) and the one from
> norloff, working pretty well.

Oh, that is kind of you. Eugen.

I actually just installed Meinberg 1370 release onto a completely separate 
test PC, and extracted the ntpd.exe file (and the other .exe files) into a 
Zip archive, and then replaced the old ntpd.exe on my system as you 
described (except I used the graphical Services manager).  It's working 
OK, but seems to be doing a lot more clock-hopping than before.  The 
"prefer" is still set.

Interestingly, in your archive the ntpd.exe is dated 2005 Apr 07, in the 
1370 download from Meinberg the file is dated 2005 Apr 12.  Both files are 
192,512 bytes, but they are different.....

I expect Meinberg would like to know of the problems with their version of 
the ntpdc.exe program.

As a matter of interest, I'm not using the SSL stuff (as fas as I know), 
but the file I have are from Terje's archive (I think):

ssleay32.dll
  159,744 bytes, 2003 June 04, no version number

libeay32.dll
  827,392 bytes, 2003 Jun 04, no version number

[Why don't people add version numbers to executable and DLL files when the 
facility is provided within Windows?]

Thanks,
David 

In the Meinberg distribution I've installed the file is dated 07 April
2005 as in the version reported by ntpd.exe: version="ntpd
4.2.0a@1.1354-o Apr 07 12:01:06 (UTC+02:00) 2005  (3)"?"

The problem with ntpdc.exe is well known (I posted a message in this
group and an E-mail to Meinberg developers). It seems to be a timeout
problem.

For your problem: the ntp.drift file is OK ? Did you delete that file
and see the program create it ? It's a possible cause I fight with on
FreeBSD.

And, with your permission, how about doing the following test. Add this
line: "server ntp1.ptb.de minpoll 6 maxpoll 6 prefer" in your ntp.conf
file and remove the old prefer-ed server. Restart the service and allow
several hours to see the behaviour.

Eugen COCA wrote:
> In the Meinberg distribution I've installed the file is dated 07 April
> 2005 as in the version reported by ntpd.exe: version="ntpd
> 4.2.0a@1.1354-o Apr 07 12:01:06 (UTC+02:00) 2005  (3)"?"
>
> The problem with ntpdc.exe is well known (I posted a message in this
> group and an E-mail to Meinberg developers). It seems to be a timeout
> problem.
>
> For your problem: the ntp.drift file is OK ? Did you delete that file
> and see the program create it ? It's a possible cause I fight with on
> FreeBSD.

The version lists as:
 ntpd 4.2.0a@1.1370-o Apr 12 14:10:45 (UTC+02:00) 2005  (12)

so it's a few builds ahead of yours.

The drift file is fine, and contains values verying very slightly 
around -65  (say from -64.9 to -65.1).

David 

Eugen COCA wrote:
> And, with your permission, how about doing the following test. Add
> this line: "server ntp1.ptb.de minpoll 6 maxpoll 6 prefer" in your
> ntp.conf file and remove the old prefer-ed server. Restart the
> service and allow several hours to see the behaviour.

I may try that later, once I see how this new version behaves.  It is 
still reporting much higher jitter (5 - 10 ms) for servers on the LAN than 
the other PCs also on the same, small LAN running off the same ntp 
servers.

David 

You should also check the following:

1. The ntpd.exe service is running with "Realtime" priority - in
taskmanager right click and then "Change priority". It MUST be realtime
selected there.
2. Examine the "Application" log to see if there are some strage
recordings regarding the NTP service.

Eugen COCA wrote:
> You should also check the following:
>
> 1. The ntpd.exe service is running with "Realtime" priority - in
> taskmanager right click and then "Change priority". It MUST be
> realtime selected there.
> 2. Examine the "Application" log to see if there are some strage
> recordings regarding the NTP service.

Thanks, Eugen.

1 - it is, good point though

2 - no strange error messages, I had already checked.

David 

For the graphs page, with no link to your question: as the images are
cached by the browser and/or the proxy server you may add in the html
page header:

<meta http-equiv="pragma" content="no-cache" />
<meta http-equiv="cache-control" content="no-cache" />

to avoid this behaviour.

I am looking at your graphs with highest interest and it's sometimes
difficult to press reload on every image (the browser reload function
produces no visible effect).

P.S. I'm not giving lessons, it's just an opinion.

Eugen COCA wrote:
> For the graphs page, with no link to your question: as the images are
> cached by the browser and/or the proxy server you may add in the html
> page header:
>
> <meta http-equiv="pragma" content="no-cache" />
> <meta http-equiv="cache-control" content="no-cache" />
>
> to avoid this behaviour.
>
> I am looking at your graphs with highest interest and it's sometimes
> difficult to press reload on every image (the browser reload function
> produces no visible effect).
>
> P.S. I'm not giving lessons, it's just an opinion.

Eugen,

Thanks for that.  Yes, the pages generated by MRTG have just the no-cache 
meta-data, so I've added it to my NTP and Network summary pages as well.

I still don't know what happened on Friday!

On Odin I can see the effect of changing to the newer NTP version, there 
seems to be more short-term jitter and perhaps less long-term drift.  We 
will see overnight.  I upgraded Stamsund's NTP as well.

Cheers,
David 

David J Taylor wrote:
> Danny Mayer wrote:
> 
>>David J Taylor wrote:
>>
>>>Tom,
>>>
>>>Many thanks for your thoughtful suggestions.
>>>
>>>It looks as if the drift is OK, at -64.911, but I will keep an eye
>>>on it. Here is the full output just in case there's something else
>>>glaringly obvious:
>>>
>>>E:\>ntpq -c "rv 0" odin
>>>status=46b4 leap_add_sec, sync_ntp, 11 events, event_peer/strat_chg,
>>>version="ntpd 4.2.0 fr Oct 17 8:49:33 2003 (1)", processor="unknown",
>>>system="WINDOWS/NT", leap=01, stratum=3, precision=-19,
>>>rootdelay=62.583, rootdispersion=125.847, peer=62645,
>>>refid=192.168.0.1, reftime=c73d5d1a.a4d239b4  Sun, Dec  4 2005
>>>12:18:34.643, poll=7, clock=c73d5f43.da3d1265  Sun, Dec  4 2005
>>>12:27:47.852, state=4, offset=18.583, frequency=-64.911,
>>>jitter=10.097, stability=0.028
>>>
>>
>>Well the version is rather ancient. Time to trade up?
>>
>>Danny
> 
> 
> OK, I accept that in principle, but:
> 
> - is there a known error in that version which would cause it to become 
> unstable?  As the software had been OK until last Friday, why should it 
> suddenly become not OK?  Would the arrival of a leap second indicator 
> cause instability in one copy and yet other PCs continue to function 
> correctly?  It doesn't sound right to me.
> 
> - which version would you suggest using?

The one that I have running, of course! Unfortunately I haven't finished
testing it. It fixes a number of issues that the Meinberg folk have
reported.

> 
> - where to obtain it?

It's on my disk of course.

>  Given that:
> 
>   - Terje's most recent version is: ntp-dev-4.2.0a-20040319-nt.zip.
> 
That is a bit old.

>   - Meinberg's is a ready-to-install package, whereas I just want .exe 
> files I can copy - the installation is already done.
> 

Well I have an installer too even though it's not ready for release and
it creates a special account to run as a service with restricted
privileges. You can, of course just copy the files to the right places.

>   - I wouldn't trust compiling it myself.
> 
You do a good job of it!

Danny

> Cheers,
> David 
> 
> 
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions
> 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> 
> As a matter of interest, I'm not using the SSL stuff (as fas as I know), 
> but the file I have are from Terje's archive (I think):
> 
> ssleay32.dll
>   159,744 bytes, 2003 June 04, no version number
> 
> libeay32.dll
>   827,392 bytes, 2003 Jun 04, no version number
> 
> [Why don't people add version numbers to executable and DLL files when the 
> facility is provided within Windows?]
> 

It's harder to do automatically than you might think. I did have plans
to do this for BIND 9 but I ran out of time to do it.

Danny

> Thanks,
> David 
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Eugen COCA wrote:
> In the Meinberg distribution I've installed the file is dated 07 April
> 2005 as in the version reported by ntpd.exe: version="ntpd
> 4.2.0a@1.1354-o Apr 07 12:01:06 (UTC+02:00) 2005  (3)"?"
> 
> The problem with ntpdc.exe is well known (I posted a message in this
> group and an E-mail to Meinberg developers). It seems to be a timeout
> problem.
> 
If you didn't file a report on it in bugzilla it probably won't get
fixed. I don't remember you reporting a problem but it's easy for me to
miss.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:

> David J Taylor wrote:
>> Given that:
>>
>>  - Terje's most recent version is: ntp-dev-4.2.0a-20040319-nt.zip.
>>
> 
> That is a bit old.

Ouch, you're absolutely right. Sorry!
> 
> 
>>  - Meinberg's is a ready-to-install package, whereas I just want .exe 
>>files I can copy - the installation is already done.
>>
> 
> 
> Well I have an installer too even though it's not ready for release and
> it creates a special account to run as a service with restricted
> privileges. You can, of course just copy the files to the right places.

Here's the latest version that I've personally checked out, and run on
many of my own computers:

http://www.norloff.org/ntp/dev/ntp-dev-4.2.0b-20051105-nt.zip

As you wished, this is binary files only, no installer.

On the laptop where I'm writing this it has stabilized at ~1 ms offset
from a a few of my local FreeBSD boxes (with Oncore or NMEA GPS refclocks).

Terje
-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote:
[]
> Here's the latest version that I've personally checked out, and run on
> many of my own computers:
>
> http://www.norloff.org/ntp/dev/ntp-dev-4.2.0b-20051105-nt.zip
>
> As you wished, this is binary files only, no installer.
>
> On the laptop where I'm writing this it has stabilized at ~1 ms offset
> from a a few of my local FreeBSD boxes (with Oncore or NMEA GPS
> refclocks).
>
> Terje

Many thanks, Terje.  I'll download now and update all PCs.

I'm not objecting to an installer, but in the situation of fault-finding I 
didn't want to risk upsetting things by using Meinberg's installer, which 
seems not to regonise an existing manual NTP installation.  It's fine for 
a first-time install, though.

Cheers,
David 

On my win2k/sp4 computer the ntpd service restart determined a hang-up
(after upgrading to this version).

Eugen COCA wrote:
> On my win2k/sp4 computer the ntpd service restart determined a hang-up
> (after upgrading to this version).

Which version?

I have Terje's version running OK on Windows XP SP2 Pro, Windows 2000 
workstation SP4, and Windows NT4 SP6A (?).

version="ntpd 4.2.0b@1.1431-o Dec 06 10:23:21 (UTC+01:00) 2005  (1)"

David 

The version you mentioned - 4.2.0b 1431.

On another system, with win2k prof sp4 it worked ok. I have Zonealarm
and Bitdefender on my computer - if these interfere in a way with ntpd.
The 4.2.0a version from Meinberg it's working very well.

The system where ntpd version 4.2.0b - 1431 is not working is Windows
2000 Server.

Eugen COCA wrote:
> The version you mentioned - 4.2.0b 1431.
>
> On another system, with win2k prof sp4 it worked ok. I have Zonealarm
> and Bitdefender on my computer - if these interfere in a way with
> ntpd. The 4.2.0a version from Meinberg it's working very well.

On the Windows 2000 computers I menitoned Zone Alarm is running, and must 
give NTPD both Access and Server to Trusted and Internet zones.

I haven't checked on Windows 2000 server, but I may be able to do that 
after lunch.  I dimly recall there being an issue with Windows systems 
having multiple ports, but that doesn't seem to have affected this Windows 
XP Pro system (which does have multiple networks cards, and multiple IPs 
on the Ethernet NIC).

David 

Eugen COCA wrote:
> The system where ntpd version 4.2.0b - 1431 is not working is Windows
> 2000 Server.

Well, for what it's worth, I just fired up my test system (Windows 2000 
Server, Service pack 4), and over wrote the files from the Meinberg 
installation I did yesterday with the version from Terje which he provided 
this morning, and it seems to be running OK with both servers on the LAN 
and the WAN.

David 

David J Taylor wrote:

 > Many thanks, Terje.  I'll download now and update all PCs.
> 
> I'm not objecting to an installer, but in the situation of fault-finding I 
> didn't want to risk upsetting things by using Meinberg's installer, which 
> seems not to regonise an existing manual NTP installation.  It's fine for 
> a first-time install, though.

This is how I've installed most systems since last year:

First use the installer, then while still in the editor to check out the
ntp.conf file, I extract the latest binaries that I've personally
compiled and overwrite the installer-generated set.

As soon as I exit the editor, the installer will immediately startup the
service, but now using my binaries. :-)

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Eugen COCA wrote:

> The version you mentioned - 4.2.0b 1431.
> 
> On another system, with win2k prof sp4 it worked ok. I have Zonealarm
> and Bitdefender on my computer - if these interfere in a way with ntpd.
> The 4.2.0a version from Meinberg it's working very well.

Hmmm.

Can you load Ethereal and use it to track the network traffic after restart?

Having a network trace from such a situation would be very useful when
trying to determine what might have broken between those two versions.

Feel free to send me private email if you want a more thorough
walkthrough of how you can use Ethereal to diagnose various networking
problems!

Terje
-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

David J Taylor wrote:
> Eugen COCA wrote:
> 
>>The version you mentioned - 4.2.0b 1431.
>>
>>On another system, with win2k prof sp4 it worked ok. I have Zonealarm
>>and Bitdefender on my computer - if these interfere in a way with
>>ntpd. The 4.2.0a version from Meinberg it's working very well.
> 
> 
> On the Windows 2000 computers I menitoned Zone Alarm is running, and must 
> give NTPD both Access and Server to Trusted and Internet zones.
> 
> I haven't checked on Windows 2000 server, but I may be able to do that 
> after lunch.  I dimly recall there being an issue with Windows systems 
> having multiple ports, but that doesn't seem to have affected this Windows 
> XP Pro system (which does have multiple networks cards, and multiple IPs 
> on the Ethernet NIC).
> 

There should be no problems with multiple ports. NTP only uses 123/UDP.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
[]
> There should be no problems with multiple ports. NTP only uses
> 123/UDP.

I recall (vaguely) there being a problem with a recent NTPD on (the old) 
Windows NT (Server?) 4.0.  Perhaps I was confusing it with multiple IP 
addresses on one PC.  Sorry.

David

David,

Sorry for the late response, I've been offline the last few days.

David J Taylor wrote:
[...]
> Thanks for that observation, Johan.  Thursday's events could well have
> been the cause, this is what happened (approximately):
> 
> - I looked at an animation - QuickTime said there was a newer version
> available.
> 
> - I downloaded the newer version
> 
> - on starting to install the newer version, I noted it installed iTunes
> 
> - as I have no need for iTunes, I stopped the install
> 
> Now perhaps this left things in a half installed, half not installed
> state?  Later, I did remove QuickTime entirely and re-install V6.5.2 (with
> no iTunes) from a file I already had on disk.

This points to the problems with Windows time if a multimedia application is
started. I've mentioned this sometimes before here in the newsgroup, e.g.
here:
http://lists.ntp.isc.org/pipermail/questions/2005-September/006709.html

This problem is NOT from the MM apps themselves but from the way Windows is
keeping time, and AFAIK has been fixed by MS in SP2 for WinXP.

So you won't fix the problem by using another version of ntpd. Either you
must make sure no MM app runs at all (maybe even not in the background, if
QT looks if updates are available), or you must have at least one MM app
running continuously in order to have the MM timer set constantly set
either to highest resolution or default resolution, but not switching
between the 2 resolutions. 

If the MM timer is set constantly to high resolution then you should observe
a little more jitter than with default resolution, but the large steps
should go away. So as a test you just might to start Quicktime ant watch if
the offset settles down.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Terje,

Terje Mathisen wrote:
[...]
> Here's the latest version that I've personally checked out, and run on
> many of my own computers:
> 
> http://www.norloff.org/ntp/dev/ntp-dev-4.2.0b-20051105-nt.zip

There's currently a problem in all ntpd versions for Windows from 
ntp-dev-4.2.0a-20050726.tar.gz and newer which may let the service hang or
crash earlier or later on some systems. There's also been another thread
recently where a current version of ntpd crashed immediately on a server
2003.

This is the reason why I've removed the latest GUI installer from our
download page a few days ago and made an earlier version (1370) available
again.

Danny is already working to fix this and as soon as we've verified the fixed
version we'll make the updated GUI installer available.

However, as mentioned in my other post here, I'm expecting this has nothing
to do with David's problems.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[...]
> If the MM timer is set constantly to high resolution then you should
> observe a little more jitter than with default resolution, but the large
> steps should go away. So as a test you just might to start Quicktime ant
> watch if the offset settles down.

BTW, I forgot to mention that I've submitted a patch to Danny which can let
ntpd itself set the MM timer to highest resolution, possibly controlled via
a command line parameter. This has the same effect as just having e.g.
Quicktime running continuously.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Danny,

Danny Mayer wrote:
> Eugen COCA wrote:
>> In the Meinberg distribution I've installed the file is dated 07 April
>> 2005 as in the version reported by ntpd.exe: version="ntpd
>> 4.2.0a@1.1354-o Apr 07 12:01:06 (UTC+02:00) 2005  (3)"?"
>> 
>> The problem with ntpdc.exe is well known (I posted a message in this
>> group and an E-mail to Meinberg developers). It seems to be a timeout
>> problem.
>> 
> If you didn't file a report on it in bugzilla it probably won't get
> fixed. I don't remember you reporting a problem but it's easy for me to
> miss.

I think this was related to bug #286:
"tpdc -nc monlist output failure when amount of clients is over 512"
https://ntp.isc.org/bugs/show_bug.cgi?id=286

However, I haven't had time to dig into this, yet.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> This points to the problems with Windows time if a multimedia
> application is started. I've mentioned this sometimes before here in
> the newsgroup, e.g. here:
> http://lists.ntp.isc.org/pipermail/questions/2005-September/006709.html
>
> This problem is NOT from the MM apps themselves but from the way
> Windows is keeping time, and AFAIK has been fixed by MS in SP2 for
> WinXP.
>
> So you won't fix the problem by using another version of ntpd. Either
> you must make sure no MM app runs at all (maybe even not in the
> background, if QT looks if updates are available), or you must have
> at least one MM app running continuously in order to have the MM
> timer set constantly set either to highest resolution or default
> resolution, but not switching between the 2 resolutions.
>
> If the MM timer is set constantly to high resolution then you should
> observe a little more jitter than with default resolution, but the
> large steps should go away. So as a test you just might to start
> Quicktime ant watch if the offset settles down.
>
>
> Martin

Martin,

Thanks for the response.  Yes, there was something about SP2 which fixed 
the problem, and it seems to me that something I did last Friday seems to 
have undone the SP2 fix, and I can't restore whatever has been undone!  I 
suspect that QuickTime is the culprit (with me accepting the updates which 
were available), but I have no hard evidence for that.

I didn't think that changing version would help, but it seemed both polite 
to the people who suggested it, and a "good thing" to have the latest 
version in any case.

I have just started the QuickTime player, and I'll see if that makes any 
difference.

Do you know a way to check if the MM times is enabled?  I could easily 
write a small piece of code do check this and enable them as an 
experiment.  Could you perhaps send me a copy of the patch?

Your help and suggestions are very much appreciated.

David 

Martin Burnicki wrote:
[]
> This points to the problems with Windows time if a multimedia
> application is started. I've mentioned this sometimes before here in
> the newsgroup, e.g. here:
> http://lists.ntp.isc.org/pipermail/questions/2005-September/006709.html
>
> This problem is NOT from the MM apps themselves but from the way
> Windows is keeping time, and AFAIK has been fixed by MS in SP2 for
> WinXP.
>
> So you won't fix the problem by using another version of ntpd. Either
> you must make sure no MM app runs at all (maybe even not in the
> background, if QT looks if updates are available), or you must have
> at least one MM app running continuously in order to have the MM
> timer set constantly set either to highest resolution or default
> resolution, but not switching between the 2 resolutions.
>
> If the MM timer is set constantly to high resolution then you should
> observe a little more jitter than with default resolution, but the
> large steps should go away. So as a test you just might to start
> Quicktime ant watch if the offset settles down.
>
>
> Martin

I've had a QuickTime video playing but paused now for the last two hours 
or so,
It's a bit early to say yet, but it looks as if a number of things have 
happened:

- the drift value is changing from -65 downwards, currently -59.385

- the offset has shot up to 120ms, but seems to be stable at that value (I 
guess if it goes up much more a step will happen at 128ms).

- the jitter figures seem much better, around 2 - 3ms.  Of course, that's 
with a high offset value so not strictly comparable.

However, it does perhaps suggest that:

- the poor performance before was from the time switching into and out of 
MM mode.

- having a permanently "on" MM mode may help this system, and may be a 
useful feature for NTP on some Windows systems.

I still have no idea what piece of software started enabling the MM-timer 
mode last Friday, though!  I should keep better records.  I'll report 
again tomorrow.

David 

David,

David J Taylor wrote:
> Thanks for the response.  Yes, there was something about SP2 which fixed
> the problem, and it seems to me that something I did last Friday seems to
> have undone the SP2 fix, and I can't restore whatever has been undone!  I
> suspect that QuickTime is the culprit (with me accepting the updates which
> were available), but I have no hard evidence for that.

Please note, I must say it again, that Quicktime is not basically the
problem, it's just the application which triggers that behaviour by using
existing Windows API calls which have been designed for such applications.

The problem lies in Windows whose timekeeping is deranged if an application
like Quicktime uses those APIs.
 
> I didn't think that changing version would help, but it seemed both polite
> to the people who suggested it, and a "good thing" to have the latest
> version in any case.
> 
> I have just started the QuickTime player, and I'll see if that makes any
> difference.
> 
> Do you know a way to check if the MM times is enabled?  I could easily
> write a small piece of code do check this and enable them as an
> experiment.  Could you perhaps send me a copy of the patch?

I'm not currently aware of an easy way to find out if any application has
changed the MM timer resolution. 

I've observed that the timer APC callback function which is used by ntpd to
interpolate the system time between the timer ticks, and which is normally
called at regular intervals, is called with a jitter of +/- 1 millisecond
if the MM timer resolution is high. 

I can see if I can send you the patch which lets ntpd modify the MM timer
while it is active when I'm back at the office.
 
> Your help and suggestions are very much appreciated.

Thanks.

> David

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David,

David J Taylor wrote:
> I've had a QuickTime video playing but paused now for the last two hours
> or so,

As far as I can tell it's not necessary to play a video, just to have
Quicktime loaded, since it seems that Quicktime modifies the MM timer at
startup and changes back to default MM timer resulution when it exits.
Maybe other MM apps behavve differently, though.

> It's a bit early to say yet, but it looks as if a number of things have
> happened:
> 
> - the drift value is changing from -65 downwards, currently -59.385
> 
> - the offset has shot up to 120ms, but seems to be stable at that value (I
> guess if it goes up much more a step will happen at 128ms).

Maybe you've read in another current thread here that the current ntpd
version may not be very stable under Windows, so I've recently installed
and tested some other ntpd versions from earlier this year to find out
which one should be used preferably instead. Unfortunately I've found that
all of those versions adjust the Windows system clock VERY slowly. The
current version is much better in this regard, but as already said, it may
crash earlier or later.
  
> - the jitter figures seem much better, around 2 - 3ms.  Of course, that's
> with a high offset value so not strictly comparable.

That's what I've expected. However, I would expect the jitter figure being
constantly higher than without modified MM timer.
 
> However, it does perhaps suggest that:
> 
> - the poor performance before was from the time switching into and out of
> MM mode.

Right.
 
> - having a permanently "on" MM mode may help this system, and may be a
> useful feature for NTP on some Windows systems.

Right. On the other hand, it might slightly decrease the synchronization
quality on a system which does not run MM apps at all.
 
> I still have no idea what piece of software started enabling the MM-timer
> mode last Friday, though!  I should keep better records.  I'll report
> again tomorrow.
> 
> David

Thanks,

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> David,
>
> David J Taylor wrote:
[]
>> - having a permanently "on" MM mode may help this system, and may be
>> a useful feature for NTP on some Windows systems.
>
> Right. On the other hand, it might slightly decrease the
> synchronization quality on a system which does not run MM apps at all.
[]

Of course.  When I said "some" systems, I did mean that it should be 
optional and not forced.

David 

David,

David J Taylor wrote:
[...]
> I would try a different version of NTP, but this one has been working 100%
> correctly until 14:20 On Dec 02, and continues to work on the other
> systems.  You can see this from the weekly and monthly plots.  I used to
> have poor stability on this system until upgrading to Windows XP SP2, and
> others have seen a similar behaviour.  It is as if something undid
> whatever change SP2 made.

Maybe re-installing SP2 would fix the problem?
 
> It's possible that I did upgrade some software - many programs offer to do
> that for you on the fly - but I would have thought the system restore
> would have fixed that.  I also tried uninstalling QuickTime, as there is a
> suggestion that if the multi-media timer is enabled in Windows, that can
> cause these problems.  As yet, I haven't found out how to determine
> whether the multi-media timer is enabled, and if so, how to disable it.

Maybe there's a program which is run in cyclic intervals to check if new
updates are available? 

BTW, which version of ntpd have you been running before this happened?


Martin

-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> Maybe re-installing SP2 would fix the problem?
[]
> Maybe there's a program which is run in cyclic intervals to check if
> new updates are available?
>
> BTW, which version of ntpd have you been running before this happened?
>
>
> Martin

Yes, I had wondered about re-installing SP2 but (a) I've never done that 
on XP (done it many times on NT4, though!), and (b) this is my prime 
working system, so I really don't want to mess it up!

I don't think it's an update program causing the problems (the instability 
is 24 hours a day), and any updates from Microsoft I run manually (after I 
am informed they are available).  I /may/ have accepted an update from 
QuickTime without thinking, or for some other application.

Prior to the problem I was running Terje's 2003 V4.2.0 (I think, this 
level of detail is now lost).  It had been working perfectly for over two 
years.

Cheers,
David 

David J Taylor wrote:
> Danny Mayer wrote:
> []
> 
>>There should be no problems with multiple ports. NTP only uses
>>123/UDP.
> 
> 
> I recall (vaguely) there being a problem with a recent NTPD on (the old) 
> Windows NT (Server?) 4.0.  Perhaps I was confusing it with multiple IP 
> addresses on one PC.  Sorry.
> 

There should be no problem with multiple IP addresses either.

Danny
> David
> 
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> Martin Burnicki wrote:
[]
>> If the MM timer is set constantly to high resolution then you should
>> observe a little more jitter than with default resolution, but the
>> large steps should go away. So as a test you just might to start
>> Quicktime and watch if the offset settles down.
[]

Well, with the MM timer permanently running (from 17:00 Wednesday) I can 
report that things are /much/ better, see:

  http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html

- the offset first shot up to 120ms, but is now gently decaying towards 
zero.

- the jitter figures seem much better, around 1 (LAN servers) - 2ms (WAN 
servers).

- the drift value has changed from -65 down to -9.3ms.

I would certainly like the option, for this system at least, of running 
with the MM timers permanently in its high resolution mode.

I would also be interested in determining which program is switching the 
MM timer speed, and thereby upsetting the otherwise excellent timekeeping 
on this system.  I wonder if there's a relatively easy way to determine 
this?

David 

David,

David J Taylor wrote:
> David J Taylor wrote:
>> Martin Burnicki wrote:
> []
>>> If the MM timer is set constantly to high resolution then you should
>>> observe a little more jitter than with default resolution, but the
>>> large steps should go away. So as a test you just might to start
>>> Quicktime and watch if the offset settles down.
> []
> 
> Well, with the MM timer permanently running (from 17:00 Wednesday) I can
> report that things are /much/ better, see:
> 
>   http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html
> 
> - the offset first shot up to 120ms, but is now gently decaying towards
> zero.
> 
> - the jitter figures seem much better, around 1 (LAN servers) - 2ms (WAN
> servers).
> 
> - the drift value has changed from -65 down to -9.3ms.

Those results are exactly what I've expected.
 
> I would certainly like the option, for this system at least, of running
> with the MM timers permanently in its high resolution mode.

Agreed. Maybe Danny and Harlan accept my patch. 

> I would also be interested in determining which program is switching the
> MM timer speed, and thereby upsetting the otherwise excellent timekeeping
> on this system.  I wonder if there's a relatively easy way to determine
> this?

Unfortunately there's no way to find that out, AFAIK. You can only observe
the effects indirectly. 

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> David,
>
> David J Taylor wrote:
[]
>> I would also be interested in determining which program is switching
>> the MM timer speed, and thereby upsetting the otherwise excellent
>> timekeeping on this system.  I wonder if there's a relatively easy
>> way to determine this?
>
> Unfortunately there's no way to find that out, AFAIK. You can only
> observe the effects indirectly.
>
> Martin

Martin,

I certainly hope your patch is accepted - I am tired of seeing this paused 
video on my desktop!

I was wondering if (for example) sysinternals had a program for trapping 
the system call to change the MM timer resolution, and to determine who 
made that call.  I would imagine it's not impossible to do.

David 

Just doing a little more work on this.  I wrote a program to display 
(approximately) the resolution of the timer (from a timeGetTime) call, and 
got the following results:

- QuickTime Player running (not even playing a video), timer resolution 
just under 1ms (about 960 us)

- QuickTime not running, timer resolution seems to step between 15.6ms 
(approx) and 10.5ms.

Now these are early results, and my program isn't highly accurate, but it 
suggests that the program may not /only/ be the multimedia timer running 
or not (or is it more accurate to say without the system timer being 
forced into a higher precision?), but also that something is changing the 
basic system clock from a 10ms set to a 15ms step?  I do recall that there 
are a number of different basic clock periods in Windows, different for NT 
4.0, 2000 workstation and server, and XP.  Each are either (about) 10ms or 
15ms.

So when Windows XP SP2 was installed, everyone agreed on one system clock 
"frequency" (or should I say timer interrupt frequency), hence the 
stability of that system.  Now I have two system components or application 
software arguing over whether the correct value is 10ms or 15ms.  Is this 
really likely?

Anyone for or against that?  Any idea of which program might be doing 
this?  Perhaps it's just my code, and the 10/15ms switching isn't actually 
happening at all!

Thanks,
David 

"David J Taylor"
<david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk.invalid> wrote in
message news:SdYlf.4949$iz3.4800@text.news.blueyonder.co.uk...
[...]
> - QuickTime Player running (not even playing a video), timer resolution
> just under 1ms (about 960 us)

Probably 1000 or 1024 Hz. Perhaps 1048.576 Hz but that sounds really
unlikely. Odd that it would be slightly _faster_ than 1024 Hz; it
should really lose ticks, not gain time. Perhaps it's supposed to be
1193 Hz but then it would be missing a horrendous proportion of ticks.


> - QuickTime not running, timer resolution seems to step between 15.6ms
> (approx) and 10.5ms.

Probably 64 and 100 Hz. 64 Hz may be related to .Net. It matches the
resolution I observed for System.DateTime.Now evaluation. 100 Hz is
"the" clock resolution for NT as far as I know.

Groetjes,
Maarten Wiltink

David,

David J Taylor wrote:
> Just doing a little more work on this.  I wrote a program to display
> (approximately) the resolution of the timer (from a timeGetTime) call, and
> got the following results:
> 
> - QuickTime Player running (not even playing a video), timer resolution
> just under 1ms (about 960 us)

Normally 1 ms is the highest resolution you can set the MM timer to.
 
> - QuickTime not running, timer resolution seems to step between 15.6ms
> (approx) and 10.5ms.
> 
> Now these are early results, and my program isn't highly accurate, but it
> suggests that the program may not /only/ be the multimedia timer running
> or not (or is it more accurate to say without the system timer being
> forced into a higher precision?), but also that something is changing the
> basic system clock from a 10ms set to a 15ms step?  I do recall that there
> are a number of different basic clock periods in Windows, different for NT
> 4.0, 2000 workstation and server, and XP.  Each are either (about) 10ms or
> 15ms.

AFAIK the timer tick interval has been always about 10 ms under WinNT. In
Win2k, the tick interval was also 10 ms on machines with slower CPUs, but
15.625 ms on machines with faster CPU. I don't know whether newer Win
versions would also tick with 10 ms intervals under certain circumstances,
I've yet always seen 15.625 ms with those. 15.625 ms * 64 = 1.000 s, BTW.

The following is based on my assumptions, derived from what I've observed so
far. The hardware time normally generates IRQs at a rate of 10 or 15 ms,
and both the standard tick rate and the MM timer tick rate are derived from
that hardware tick rate.

If the MM timer resolution is set to 1 ms then the timer hardware is
reconfigured to really generate interrupts at the higher rate, e.g. really
in 1 ms intervals to match the MM tick intervals, the standard ticks are
synthesized from that higher tick rate. This also explains the 1 ms jitter
I've observed on the standard ticks if the MM timer is set to high res.

If the sync mode is switched from the first to the second algorithm then a
time offset of a few milliseconds is inserted, which is removed again if
the mode is switched back to the first (default) algorithm. This seems to
have been fixed in the kernel's timer handler of WinXP SP2. Either the
hardware timer always keeps ticking at the same rate, or switching between
the modes works better there.

AFAIK the code which deals with the Windows performance counter is in the
HAL, which is different for uniprocessor and multiprocessor systems. I
assume the code for the timer ticks and MM timer is also in the HAL, since
the behaviour described above is still slightly different on uniprocessor
and multiprocessor systems.

> Anyone for or against that?  Any idea of which program might be doing
> this?  Perhaps it's just my code, and the 10/15ms switching isn't actually
> happening at all!

I think the 10/15 ms switching is just used to maintain a kind of
synchronization between the standard tick rate and the MM timer tick rate.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Maarten Wiltink wrote:
> "David J Taylor"
> <david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
> wrote in message
> news:SdYlf.4949$iz3.4800@text.news.blueyonder.co.uk... [...]
>> - QuickTime Player running (not even playing a video), timer
>> resolution just under 1ms (about 960 us)
>
> Probably 1000 or 1024 Hz. Perhaps 1048.576 Hz but that sounds really
> unlikely. Odd that it would be slightly _faster_ than 1024 Hz; it
> should really lose ticks, not gain time. Perhaps it's supposed to be
> 1193 Hz but then it would be missing a horrendous proportion of ticks.
>
>
>> - QuickTime not running, timer resolution seems to step between
>> 15.6ms (approx) and 10.5ms.
>
> Probably 64 and 100 Hz. 64 Hz may be related to .Net. It matches the
> resolution I observed for System.DateTime.Now evaluation. 100 Hz is
> "the" clock resolution for NT as far as I know.
>
> Groetjes,
> Maarten Wiltink

Maarten,

Thanks for your comments.  Please don't take the fast time resolution as 
correct - I've only measured it approximately.  Let's call it "fast" and 
1ms.  I have no argument with it.

Before posting, I tried to find on the Internet what I had measured 
before, and couldn't.  I've now had another search and found that I 
previously reported: "On my own systems, Windows XP Pro has about 15.62ms 
resolution, Windows 2000 Server about 10.62ms, 2000 Professional 10.31ms." 
This was over three years ago, on Nov 28 2002, 8:27 am!

SysInternals also offer a program, and an article about the internal NT 
API (i.e. not the normal Windows API):

  http://www.sysinternals.com/Utilities/ClockRes.html

  http://www.sysinternals.com/Information/HighResolutionTimers.html

It woukd be interesting to know where this is set in the registry...

Cheers,
David 

Martin Burnicki wrote:
[]
> I think the 10/15 ms switching is just used to maintain a kind of
> synchronization between the standard tick rate and the MM timer tick
> rate.
>
> Martin

Martin,

Thanks for that detailed explanation, which I've saved for future 
reference.

What is still unexplained on this system, though, is why on Friday at 
14:30 the system change from (I suspect) a single stable clock timing (one 
unaffected by running MM applications) to a 10/15ms timing which affects 
NTP like crazy?

Looking now, the system is as stable with the MM timer running at 1KHz as 
it ever was before.  I'm going to see what your NTP Time Server Monitor 
says, as I've got the statistics from before the problem.  (Thanks for the 
excellent tool, by the way).

Pre-fault
Nov 29:  frequency -7.6 .. -7.5, offset -0.006 .. +0.006

During the fault:
Dec 04:  frequency -68..-63,  offset -0.6 .. +0.6

Today:
Dec 08: frequency -16.2 .. -7.56,  offset -0.06..+0.06 (but still 
stabilising)

So I am coming back towards the drift value I had before the fault, and 
the stability is similar (the 0.06 looks like a single transient when I 
tried stopping and restarting QuickTime to check my own measurement 
program).

OK, I'm now revising my view of what happened.  My best guess now is that 
before the fault occurred, I was running with the MM timer permanently 
enabled, and that's what made the system stable.  Something caused that to 
stop.  What?  Does XP SP2 permanently run the MM timer at 1KHz?  News to 
me if it does!

Too much thinking out loud!

Cheers,
David 

This thread has intrigued me because I think I may have a similar problem.

My Windows XP system ran Terje's NTP 4.2.0a happily from May 2004
until sometime in the last month - I can't be as precise as David Taylor.
My PC was synchronizing to my server running Linux also with NTP 4.2.0.
Using NTPMonitor occasionally, I was seeing offsets typically 20-50 ms from 
reliable low-stratum servers - more than satisfactory for me and I paid very 
little attention to it. The SP2 upgrade went smoothly some months ago.

Sometime in the last few weeks NTP on the PC has completely lost the ability to 
synchronize with the server. I'm seeing offsets increasing by several seconds an 
hour - they are consistent across my server and distant stratum 1-3 servers. The 
offsets are alway negative which means (I think) that the PC's time is running 
faster than the server.

I've tried all the obvious things - installing later and earlier versions of 
ntpd, removing applications running in the background...none of these seems to 
affect the behaviour of NTP in the slightest. I've made some fairly major 
changes to the PC in the last 2 months, some of which I'm not keen to reverse - 
like installing Visual Studio C++ Express Edition, .NET 2.0 runtime, Windows 
SDK, BIOS upgrade, so there are plenty of things which could have clobbered NTP.

Here is the output from
ntpq -c "rv 0" deeley
assID=0 status=c074 sync_alarm, sync_unspec, 7 events, event_peer/strat_chg,
version="ntpd  2004 May 07 8:37:39  (1)"?, processor="unknown",
system="WINDOWS/NT", leap=11, stratum=16, precision=-20,
rootdelay=0.000, rootdispersion=32.160, peer=0, refid=STEP,
reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000, poll=4,
clock=0xc7449871.72e5796b, state=3, offset=0.000, frequency=0.000,
noise=2299.254, jitter=870.642, stability=0.000

(only 45 minutes after restarting the NTP service)

Some of this looks a bit strange so maybe I'm out of my depth here, but I'm 
curious to know if this could be a similar issue to David Taylor's.

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
> This thread has intrigued me because I think I may have a similar
> problem.
> My Windows XP system ran Terje's NTP 4.2.0a happily from May 2004
> until sometime in the last month - I can't be as precise as David
> Taylor. My PC was synchronizing to my server running Linux also with NTP
> 4.2.0. Using NTPMonitor occasionally, I was seeing offsets typically 
> 20-50
> ms from reliable low-stratum servers - more than satisfactory for me
> and I paid very little attention to it. The SP2 upgrade went smoothly
> some months ago.
> Sometime in the last few weeks NTP on the PC has completely lost the
> ability to synchronize with the server. I'm seeing offsets increasing
> by several seconds an hour - they are consistent across my server and
> distant stratum 1-3 servers. The offsets are alway negative which
> means (I think) that the PC's time is running faster than the server.
>
> I've tried all the obvious things - installing later and earlier
> versions of ntpd, removing applications running in the
> background...none of these seems to affect the behaviour of NTP in
> the slightest. I've made some fairly major changes to the PC in the
> last 2 months, some of which I'm not keen to reverse - like
> installing Visual Studio C++ Express Edition, .NET 2.0 runtime,
> Windows SDK, BIOS upgrade, so there are plenty of things which could
> have clobbered NTP.
> Here is the output from
> ntpq -c "rv 0" deeley
> assID=0 status=c074 sync_alarm, sync_unspec, 7 events,
> event_peer/strat_chg, version="ntpd  2004 May 07 8:37:39  (1)"?,
> processor="unknown", system="WINDOWS/NT", leap=11, stratum=16,
> precision=-20, rootdelay=0.000, rootdispersion=32.160, peer=0, 
> refid=STEP,
> reftime=00000000.00000000  Thu, Feb  7 2036  7:28:16.000, poll=4,
> clock=0xc7449871.72e5796b, state=3, offset=0.000, frequency=0.000,
> noise=2299.254, jitter=870.642, stability=0.000
>
> (only 45 minutes after restarting the NTP service)
>
> Some of this looks a bit strange so maybe I'm out of my depth here,
> but I'm curious to know if this could be a similar issue to David
> Taylor's.
> John

John,

I'm not an expert in reading those "rv" outputs, but if you are on stratum 
16 it means you aren't synchronised.  Try the command:  ntpq -p deeley. 
The "reach" column should show 377 for each server  - octal for a bit 
field of 8 ones meaning 8 good connections.

My guess is that you may have a TCP/IP problem, like a firewall blocking 
access from your NTP client to its servers.

BTW: I've now written a program to force the MM timer to have a resolution 
of 1ms permanently, and this seems to have fixed the problem I had.

David 

> I'm not an expert in reading those "rv" outputs, but if you are on stratum 
> 16 it means you aren't synchronised.  Try the command:  ntpq -p deeley. 
> The "reach" column should show 377 for each server  - octal for a bit 
> field of 8 ones meaning 8 good connections.
> 
> My guess is that you may have a TCP/IP problem, like a firewall blocking 
> access from your NTP client to its servers.

David,

Thanks for the feedback.

First of all, I looked again at your website and I realise that my problem is 
probably not the same as yours - you had a deterioration in time-keeping, 
whereas my system seems to have given up altogether. Probably my problem belongs 
in a separate thread, but I'll keep going here as there is a lot of useful 
information on Windows and NTP in this thread.

Mine is not an obvious TCP/IP problem: the client (deeley) and server (barlow) 
are both on the LAN, whereas the only firewall - on barlow - is on the interface 
to the outside world (and barlow's ntpd synchronizes fine with pool.ntp.org 
servers). Also there is no sign of trouble with netstat -s.

When looking at the NTP log on deeley after a period of time I see a pattern: it 
records synchronization to barlow, and then 4-10 minutes later it records "no 
servers reachable", like this:

10 Dec 13:54:19 NTP[3548]: synchronized to 192.168.0.5, stratum 3
10 Dec 14:00:38 NTP[3548]: no servers reachable

Successive ntpq -p commands show:

C:\NTP>ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*barlow          213.222.11.219   3 u   37   64   77    0.278  -816.70 861.409

C:\NTP>ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
  barlow          213.222.11.219   3 u   37   64  377    0.267  -28115. 1823.41

I'm open to any suggestions for looking at other debugging information.

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:

>
>> I'm not an expert in reading those "rv" outputs, but if you are on 
>> stratum 16 it means you aren't synchronised.  Try the command:  ntpq 
>> -p deeley. The "reach" column should show 377 for each server  - 
>> octal for a bit field of 8 ones meaning 8 good connections.
>>
>> My guess is that you may have a TCP/IP problem, like a firewall 
>> blocking access from your NTP client to its servers.
>
>
> David,
>
> Thanks for the feedback.
>
> First of all, I looked again at your website and I realise that my 
> problem is probably not the same as yours - you had a deterioration in 
> time-keeping, whereas my system seems to have given up altogether. 
> Probably my problem belongs in a separate thread, but I'll keep going 
> here as there is a lot of useful information on Windows and NTP in 
> this thread.
>
> Mine is not an obvious TCP/IP problem: the client (deeley) and server 
> (barlow) are both on the LAN, whereas the only firewall - on barlow - 
> is on the interface to the outside world (and barlow's ntpd 
> synchronizes fine with pool.ntp.org servers). Also there is no sign of 
> trouble with netstat -s.
>
> When looking at the NTP log on deeley after a period of time I see a 
> pattern: it records synchronization to barlow, and then 4-10 minutes 
> later it records "no servers reachable", like this:
>
> 10 Dec 13:54:19 NTP[3548]: synchronized to 192.168.0.5, stratum 3
> 10 Dec 14:00:38 NTP[3548]: no servers reachable
>
> Successive ntpq -p commands show:
>
> C:\NTP>ntpq -p
>      remote           refid      st t when poll reach   delay   
> offset  jitter
> ============================================================================== 
>
> *barlow          213.222.11.219   3 u   37   64   77    0.278  -816.70 
> 861.409
>
> C:\NTP>ntpq -p
>      remote           refid      st t when poll reach   delay   
> offset  jitter
> ============================================================================== 
>
>  barlow          213.222.11.219   3 u   37   64  377    0.267  -28115. 
> 1823.41
>
> I'm open to any suggestions for looking at other debugging information.
>
> John
>
> -- 
>
> John Allen
> Bofferdange, Luxembourg
> allen{at}vo{dot}lu
> http://www.homepages.lu/allen

Do you have a drift file?   What value is stored in the drift file?   
What was the interval between the two ntpq -p commands?

My guess would be that your local clock has a frequency error well in 
excess of 500 parts per million!   If that is the case, you will 
probably have to replace the mother board to fix it.

David J Taylor wrote:
> BTW: I've now written a program to force the MM timer to have a resolution 
> of 1ms permanently, and this seems to have fixed the problem I had.
> 
> David 

This one interests me. What is it about the MM timer which makes the
difference? Also what's the impact of doing this versus not doing this
on other applications?

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
>> BTW: I've now written a program to force the MM timer to have a
>> resolution of 1ms permanently, and this seems to have fixed the
>> problem I had.
>>
>> David
>
> This one interests me. What is it about the MM timer which makes the
> difference? Also what's the impact of doing this versus not doing this
> on other applications?
>
> Danny

Danny,

I'm getting e-mails directly from you, but shouldn't these be on the 
usenet newsgroup?

Cheers,
David
-- 
SatSignal Software - quality software written to your requirements
Web:  http://www.satsignal.net
Email:  davidtaylor@writeme.com



_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
>> BTW: I've now written a program to force the MM timer to have a
>> resolution of 1ms permanently, and this seems to have fixed the
>> problem I had.
>>
>> David
>
> This one interests me. What is it about the MM timer which makes the
> difference? Also what's the impact of doing this versus not doing this
> on other applications?
>
> Danny

Danny,

Aside:  I've been getting direct e-mails from you which I thought should 
have appeared on the Usenet newsgroup.  Perhaps the list reflector is not 
working 100%?

The problems seems to be as (IIRC) Martin Burnicki explained, when 
switching between "1ms MM timer" and "normal 10/15ms timer", Windows 
inserts some sort of "adjustment", which causes the steps we've seen.  Why 
I only started seeing this ten days ago on the XP Pro system I don't know.

I now have been running with the MM timer enabled at 1ms on both Odin 
(1.9GHz Windows XP Pro SP2) and Stamsund (Windows 2000 WS) since Friday 
9th at 09:00 (56 hours) with no ill effects.

  http://www.david-taylor.myby.co.uk/mrtg/daily_ntp.html

The stability on Odin appears to be restored, and there have been no 
timing steps on Stamsund like there were before.  Look at the Stamsund 
week graph!  A drastic improvement since last Wednesday.

  http://www.david-taylor.myby.co.uk/mrtg/stamsund_ntp.html

My current view is that not only should NTP on Windows run with the 1ms MM 
timer enabled, but that it should be the default.  Obviously, though, 
you'll want to do testing on more than two machines before building that 
in!

David 

Danny Mayer wrote:
[]
> You can put in some hooking functions to catch this, but these aren't
> simple things to do. I'm not sure that sysinternals has something like
> you're suggesting. LiveKD may be the closest thing.
>
> Danny

Thanks for that, Danny.  As the system seems to work OK with the 1ms MM 
timer "always on", finding out which program was enabling the MM timer has 
become less important.

David 

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David,

I've just sent Danny a patch which lets ntpd set the MM timer to high
resolution if a parameter -M is given on the command line.

Additionally it contains code to slew the system clock quickly when a leap
second is inserted.

Hope we'll get this out soon.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David J Taylor wrote:
> Danny Mayer wrote:
> 
>>David J Taylor wrote:
>>
>>>BTW: I've now written a program to force the MM timer to have a
>>>resolution of 1ms permanently, and this seems to have fixed the
>>>problem I had.
>>>
>>>David
>>
>>This one interests me. What is it about the MM timer which makes the
>>difference? Also what's the impact of doing this versus not doing this
>>on other applications?
>>
>>Danny
> 
> 
> Danny,
> 
> Aside:  I've been getting direct e-mails from you which I thought should 
> have appeared on the Usenet newsgroup.  Perhaps the list reflector is not 
> working 100%?
> 

No, it's working as designed. I have to fix your address, delete it or
get bounced mail.

> The problems seems to be as (IIRC) Martin Burnicki explained, when 
> switching between "1ms MM timer" and "normal 10/15ms timer", Windows 
> inserts some sort of "adjustment", which causes the steps we've seen.  Why 
> I only started seeing this ten days ago on the XP Pro system I don't know.
> 

If I understand this right the change in the timer is what causes the
problem which means that the disciplining is suddenly way off. It is not
good to have the frequency change when you are trying to keep accurate
time. That would indicate that laptops which change speed when they are
unplugged or plugged in.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
>> The problems seems to be as (IIRC) Martin Burnicki explained, when
>> switching between "1ms MM timer" and "normal 10/15ms timer", Windows
>> inserts some sort of "adjustment", which causes the steps we've seen. 
>> Why I only started seeing this ten days ago on the XP Pro system I don't
>> know.
> 
> If I understand this right the change in the timer is what causes the
> problem which means that the disciplining is suddenly way off. It is not
> good to have the frequency change when you are trying to keep accurate
> time. That would indicate that laptops which change speed when they are
> unplugged or plugged in.

AFAIK if laptops change speed it's basically the speed of the CPU clock what
is decreased, so this should affect the CPU's time stamp counter (TSC). 

On machines which use the SMP HAL the Windows performance counter API uses
the TSC, so if the CPU frequency is decreased the performance counter
values must be evaluated differently unless the changenment is taken into
account by the performance counter API or ACPI.

On machines with uniprocessor HAL the performance counter API uses one of
the hardware timer chips which has a much lower clock rate than the CPU
clock frequency. I'm not sure whether that clock rate is also changed on
laptops.

However, what has been discussed here before has nothing to do with laptop
power saving, it also happens on old machines which don't even support
power saving. As I see it it is a clear design flaw or faulty
implementation of the Windows system clock, and you have two possibilities
to avoid this effect: 

1.) Be absolutely sure that no app is run which changes the MM timer. This
yields the best clock synchronization results. The problem is that you
normally don't know before whether an app changes the MM timer or not.

2.) Have the MM timer running always on high resolution. This yields a clock
synchronization wich is a little bit degraded compared to 1.), but the
sytem time won't have steps back and forth if an MM app starts and stops.

If either the MM timer is constantly high or constantly low this is
transparent to applications which read the system time. The problem arises
if the MM timer resolution is switched, and the time synchronization
suddenly observes an offset of a few milliseconds which it then tries to
compensate. If the MM timer res changes again after the initial offset has
been partly or completely compensated then the result is what David has
seen.

I thought that this has been solved with XP SP2, but something David has
done seems to have removed that fix. 

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
> David,
>
> I've just sent Danny a patch which lets ntpd set the MM timer to high
> resolution if a parameter -M is given on the command line.
>
> Additionally it contains code to slew the system clock quickly when a
> leap second is inserted.
>
> Hope we'll get this out soon.
>
> Martin

Many thanks for that, Martin.

IIRC, there was a problem with NTP reading parameters from the 
command-line when running as a service, but perhaps that was a long time 
ago.  I see that in the services control tool a parameter can be 
specified.  I also hope you remembered to reset the time resolution when 
NTP closes down (although I can't actually see it being a problem if a 
program forgot to do this).

I will test this on my backup PC if you wish.

Great that leap-second code is there.  Only 19 days to go.....

Cheers,
David 

Danny Mayer wrote:
[]
>> Aside:  I've been getting direct e-mails from you which I thought
>> should have appeared on the Usenet newsgroup.  Perhaps the list
>> reflector is not working 100%?
>>
>
> No, it's working as designed. I have to fix your address, delete it or
> get bounced mail.

But I was not seeing on the newsgroup messages which you e-mailed to me 
and the ISC list.  In any case, I prefer to keep newsgroup messages on the 
newsgroup, and not get copies direct by e-mail.

> If I understand this right the change in the timer is what causes the
> problem which means that the disciplining is suddenly way off. It is
> not good to have the frequency change when you are trying to keep
> accurate time. That would indicate that laptops which change speed
> when they are unplugged or plugged in.
>
> Danny

Yes, I think that laptops which change CPU speed will continue to be a 
problem.  I'm not suggesting that running the MM timer permanently will 
help them at all with changing CPU speed (although my guess is that it 
/will/ help them when running at normal speed).

David 

Martin Burnicki wrote:
[]
> On machines which use the SMP HAL the Windows performance counter API
> uses the TSC, so if the CPU frequency is decreased the performance
> counter values must be evaluated differently unless the changenment
> is taken into account by the performance counter API or ACPI.
>
> On machines with uniprocessor HAL the performance counter API uses
> one of the hardware timer chips which has a much lower clock rate
> than the CPU clock frequency. I'm not sure whether that clock rate is
> also changed on laptops.
[]
> I thought that this has been solved with XP SP2, but something David
> has done seems to have removed that fix.
>
> Martin

Martin,

I didn't know about the difference between the SMP and uniprocessor HAL - 
most interesting!  On this system the performance counter is 3.579... MHz 
(US colour TV!), as it is on the backup PC.  Both are uniprocessor 
systems.

I agree with your other comments.

I wish I knew what I had changed, but I don't!  However, from my own tests 
the change will benefit all those systems no on XP SP2, so any SP1 systems 
still out there, plus all the Windows 2000 and (perhaps) the Windows NT 
systems.

David 

David J Taylor wrote:
> IIRC, there was a problem with NTP reading parameters from the
> command-line when running as a service, but perhaps that was a long time
> ago.  

Right. A few months ago I've sent a patch which fixed this.

> I see that in the services control tool a parameter can be 
> specified.  

Yes, the problem was that you could specify the parameters in the service
control manager, but you could not specify parameters which were evaluated
when the service was started automatically.

> I also hope you remembered to reset the time resolution when 
> NTP closes down (although I can't actually see it being a problem if a
> program forgot to do this).

The latest patch I've sent also contains code which shuts down all threads
properly and writes a message to the event log when the service shuts down.
Without that patch the service could exit too early so that some tasks
(e.g. the log message, and the time reset) were unable to complete
properly.
 
> I will test this on my backup PC if you wish.

I'll send you a precompiled version of the patched ntpd per direct mail.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

David J Taylor wrote:
> I didn't know about the difference between the SMP and uniprocessor HAL -
> most interesting!  On this system the performance counter is 3.579... MHz
> (US colour TV!), as it is on the backup PC.  Both are uniprocessor
> systems.

Yes, that's the clock rate of the timer chip which is used in the
uniprocessor HAL.

If the SMP HAL is used then the performance counter frequency matches the
CPU clock.

> I wish I knew what I had changed, but I don't!  However, from my own tests
> the change will benefit all those systems no on XP SP2, so any SP1 systems
> still out there, plus all the Windows 2000 and (perhaps) the Windows NT
> systems.

Yep.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany

Martin Burnicki wrote:
[]
> I'll send you a precompiled version of the patched ntpd per direct
> mail.

Thanks, Martin.  I'll look out for that.  To get my correct address, just 
remove these bits:

  not-this-bit  nor-this-part  invalid

David

Martin Burnicki wrote:
> David J Taylor wrote:
> 
>>IIRC, there was a problem with NTP reading parameters from the
>>command-line when running as a service, but perhaps that was a long time
>>ago.  
> 
> 
> Right. A few months ago I've sent a patch which fixed this.
> 
> 
>>I see that in the services control tool a parameter can be 
>>specified.  
> 
> 
> Yes, the problem was that you could specify the parameters in the service
> control manager, but you could not specify parameters which were evaluated
> when the service was started automatically.
> 

Just to be clear here. The command line options which Martin implemented
requires that the parameters MUST be in the registry as part of the
string that points to the ntpd executable. It is not a separate registry
entry.

The manual start allows you to enter parameters but it does NOT add them
permanently, just for that start. Martin's patch fixes that in the way
stated above.

> 
>>I also hope you remembered to reset the time resolution when 
>>NTP closes down (although I can't actually see it being a problem if a
>>program forgot to do this).
> 
> 
> The latest patch I've sent also contains code which shuts down all threads
> properly and writes a message to the event log when the service shuts down.
> Without that patch the service could exit too early so that some tasks
> (e.g. the log message, and the time reset) were unable to complete
> properly.
>  

I haven't even started to look at that one yet.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> Martin Burnicki wrote:
>> David J Taylor wrote:
[]
>>> I see that in the services control tool a parameter can be
>>> specified.
>>
>>
>> Yes, the problem was that you could specify the parameters in the
>> service control manager, but you could not specify parameters which
>> were evaluated when the service was started automatically.
>>
>
> Just to be clear here. The command line options which Martin
> implemented requires that the parameters MUST be in the registry as
> part of the string that points to the ntpd executable. It is not a
> separate registry entry.
>
> The manual start allows you to enter parameters but it does NOT add
> them permanently, just for that start. Martin's patch fixes that in
> the way stated above.
[]

OK, to be clear.  Comparing on my own system, Zone Alarm has the following 
registry entry:

HKLM\SYSTEM\CurrentControlSet\Services\vsmon\ImagePath:
  C:\WINDOWS\system32\ZoneLabs\vsmon.exe -service

where the executable is shown with a parameter "-service".

However, looking with the Services applet there is /no/parameter shown for 
vsmon.exe, but the "Path to executable" is shown as: 
"....\vsmon.exe -service".

At the moment, the path for NTP is shown as:

  C:\WINDOWS\System32\ntpd.exe

whereas if I wish to include the new -M parameter, I would need to alter 
the path to:

  C:\WINDOWS\System32\ntpd.exe  -M

A simple "yes" is I hope all the answer I need!

By the way, it's still looking good - we've burnt CDs, printed documents, 
scanned, etc. etc. all with the MM timer set to 1ms resolution.

Thanks,
David 

Martin Burnicki wrote:
[]
> I'll send you a precompiled version of the patched ntpd per direct
> mail.
>
>
> Martin

Many thanks, Martin.  I now have that version on test, and it's looking 
good.  The results are update from time to time here:

  http://www.david-taylor.myby.co.uk/mrtg/stamsund_ntp.html

David 

Richard B. Gilbert wrote:
 >Do you have a drift file?   What value is stored in the drift file?
 >What was the interval between the two ntpq -p commands?

 >My guess would be that your local clock has a frequency error well in
 >excess of 500 parts per million!   If that is the case, you will
 >probably have to replace the mother board to fix it.

Richard,

Sorry to respond so slowly on this. Your message didn't appear on the newsgroup 
server I was using, and I only found it today when I was browsing back through 
the thread on Google Groups.

I had missed the significance of the fact that the drift file has regularly been 
up to -500.00 at which point NTP really does give up - so the irregular 
time-keeping was not from NTP but from the PC's system clock unsynchronised by 
NTP. This was happening very quickly - the interval between the successive ntpq 
-p commands was only ten or fifteen minutes.

As you say, the hopeless inaccuracy of the system clock might be cured only by a 
new motherboard, although it seems strange that for more than a year it seemed 
to work fairly well.

Along the way I discovered this useful Windows command:

w32tm /stripchart /computer:barlow /dataonly
(barlow is my server, running NTP)

which just prints the successive offsets - a kind of text-only version of David 
Taylor's  NTPMonitor. As it doesn't require NTP to be running, it is a 
convenient way to see what the system clock is doing - on my system, the results 
are not encouraging.

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

David J Taylor wrote:
> 
> At the moment, the path for NTP is shown as:
> 
>   C:\WINDOWS\System32\ntpd.exe
> 
> whereas if I wish to include the new -M parameter, I would need to alter 
> the path to:
> 
>   C:\WINDOWS\System32\ntpd.exe  -M
> 
> A simple "yes" is I hope all the answer I need!

Yes.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
>>
>> At the moment, the path for NTP is shown as:
>>
>>   C:\WINDOWS\System32\ntpd.exe
>>
>> whereas if I wish to include the new -M parameter, I would need to
>> alter the path to:
>>
>>   C:\WINDOWS\System32\ntpd.exe  -M
>>
>> A simple "yes" is I hope all the answer I need!
>
> Yes.
>
> Danny

Thanks, Danny.  I'm now testing Martin's version.

One thing I did note is that the existing ntpd software doesn't work if 
that parameter is present, but when it closes it doesn't leave a message 
in the event log saying why it has failed to initialise.  It would be help 
to have a message like "Unrecognised parameter found on command-line" or 
something like that.

David 

David J Taylor wrote:
> Danny Mayer wrote:
> 
>>David J Taylor wrote:
>>
>>>At the moment, the path for NTP is shown as:
>>>
>>>  C:\WINDOWS\System32\ntpd.exe
>>>
>>>whereas if I wish to include the new -M parameter, I would need to
>>>alter the path to:
>>>
>>>  C:\WINDOWS\System32\ntpd.exe  -M
>>>
>>>A simple "yes" is I hope all the answer I need!
>>
>>Yes.
>>
>>Danny
> 
> 
> Thanks, Danny.  I'm now testing Martin's version.
> 
> One thing I did note is that the existing ntpd software doesn't work if 
> that parameter is present, but when it closes it doesn't leave a message 
> in the event log saying why it has failed to initialise.  It would be help 
> to have a message like "Unrecognised parameter found on command-line" or 
> something like that.
> 
> David 
> 
Yes. Please file a bug report since it should log an error somewhere.
The current behavior is to print the usage to stderr which is not useful
for either a service or a daemon which has nowhere to put it out.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
[]
>> One thing I did note is that the existing ntpd software doesn't work
>> if that parameter is present, but when it closes it doesn't leave a
>> message in the event log saying why it has failed to initialise.  It
>> would be help to have a message like "Unrecognised parameter found
>> on command-line" or something like that.
>>
>> David
>>
> Yes. Please file a bug report since it should log an error somewhere.
> The current behavior is to print the usage to stderr which is not
> useful for either a service or a daemon which has nowhere to put it
> out.
>
> Danny

Bug 534 Submitted - I hope I entered it correctly.

Cheers,
David 

John Allen wrote:
> Richard B. Gilbert wrote:
>  >My guess would be that your local clock has a frequency error well in
>  >excess of 500 parts per million!   If that is the case, you will
>  >probably have to replace the mother board to fix it.

> As you say, the hopeless inaccuracy of the system clock might be cured 
> only by a new motherboard, although it seems strange that for more than 
> a year it seemed to work fairly well.

I really was going to give up on this when I made what could be a useful 
discovery. While reading of recurrent problems with system clocks on nForce2 
motherboards, eg these threads:
http://www.nforcershq.com/forum/1-vt19631.html
http://kerneltrap.org/node/4872

I found references to possibly using a different HAL (Hardware Abstraction 
Layer). I then did what was probably not wise, which was to change from
"ACPI Uniprocessor PC" to "Advanced Configuration and Power Interface (ACPI) 
PC". I also set the BIOS option "FSB Spread Spectrum" to "disabled".

By good fortune this did not stop the PC working but it has had the result that 
the system clock has been very stable for 24 hours and NTP is now working 
properly, with offsets of no more than 7 ms (from the NTP server on my LAN) over 
long periods:

 >ntpq -c "rv 0"
assID=0 status=4644 leap_add_sec, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd  2004 May 07 8:37:39  (1)"?, processor="unknown",
system="WINDOWS/NT", leap=01, stratum=4, precision=-20,
rootdelay=58.614, rootdispersion=153.312, peer=7996, refid=192.168.0.5,
reftime=c74ae7bc.223db21c  Wed, Dec 14 2005 19:49:32.133, poll=9,
clock=0xc74ae8e7.5bfd448c, state=4, offset=-7.045, frequency=-7.005,
noise=3.010, jitter=0.955, stability=1.529

It may be that this HAL change only works because it disables the APIC (Advanced 
Programmable Interrupt Controller); at any rate, it has made me realise how far 
one can go from what initially appeared to be an NTP issue.

I've noticed that some other threads in this newsgroup have concerned PCs with 
nForce2 motherboards, so this could be a useful hint. However, changing HALs 
should not be done without careful reflection and a willingness to reinstall 
Windows if something goes wrong.

This site (in German) gives some more information:
http://www.planet3dnow.de/artikel/diverses/nf2config/3.shtml#config_apic

as does this:
http://support.microsoft.com/?kbid=821893

Moral of the story: if NTP seems to stop working properly and you have an 
nForce2 motherboard (a) the problem is quite possibly not NTP and (b) you may 
not need a new motherboard...

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
[]
> I found references to possibly using a different HAL (Hardware
> Abstraction Layer). I then did what was probably not wise, which was
> to change from "ACPI Uniprocessor PC" to "Advanced Configuration and
> Power Interface (ACPI) PC". I also set the BIOS option "FSB Spread
> Spectrum" to "disabled".

John,

Good to hear that your timekeeping has been restored!

I would have though that "spread spectrum" (implying a continually 
changing random frequency) was definitely something to avoid for accurate 
timekeeping!  As you say, changing the HAL is not something to be 
undertaken lightly.

I wonder if you could check just the effects of the spread-spectrum being 
enabled or not?

Cheers,
David 

>I would have though that "spread spectrum" (implying a continually 
>changing random frequency) was definitely something to avoid for accurate 
>timekeeping!  As you say, changing the HAL is not something to be 
>undertaken lightly.

Is "spread spectrym" as used for CPU clocks really going to
do anything evil to timekeeping?  Is it really random?  I've been
assuming it was some simple modulation pattern - sine or sawtooth.
It's all on one chip in a cutthroat business so they aren't going
to pay much for it.


What does Windows use for timekeeping?

Linux (on most boxes) uses the interrupts from the TOY/battery-backed
clock, usually running off a 32 KHz watch crystal.  I got surprised
by this a few years ago.  The main complication with using the main
CPU clock is SMP systems.

It's fairly easy to compare the two crystals.  Both track temperature
very well.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
>> I would have though that "spread spectrum" (implying a continually
>> changing random frequency) was definitely something to avoid for
>> accurate timekeeping!  As you say, changing the HAL is not something
>> to be undertaken lightly.
>
> Is "spread spectrym" as used for CPU clocks really going to
> do anything evil to timekeeping?  Is it really random?  I've been
> assuming it was some simple modulation pattern - sine or sawtooth.
> It's all on one chip in a cutthroat business so they aren't going
> to pay much for it.
>
>
> What does Windows use for timekeeping?
>
> Linux (on most boxes) uses the interrupts from the TOY/battery-backed
> clock, usually running off a 32 KHz watch crystal.  I got surprised
> by this a few years ago.  The main complication with using the main
> CPU clock is SMP systems.
>
> It's fairly easy to compare the two crystals.  Both track temperature
> very well.

For NTP, Windows uses one of the CPU clocks (I forget now if it's RDTSC or 
the Performance Counter) to interpolate between the Windows ticks (which 
are at 10 - 15ms intervals).  That's why I asked the OP to try the simple 
test of disabling the "spread-spectrum" in the BIOS - to see if it did 
make a difference.

I do agree with you that's it's like to be a very simple spread-spectrum 
implementation.

David 

David J Taylor wrote:
> John Allen wrote:
> []
>> I found references to possibly using a different HAL (Hardware
>> Abstraction Layer). I then did what was probably not wise, which was
>> to change from "ACPI Uniprocessor PC" to "Advanced Configuration and
>> Power Interface (ACPI) PC". I also set the BIOS option "FSB Spread
>> Spectrum" to "disabled".
> 

> I would have though that "spread spectrum" (implying a continually 
> changing random frequency) was definitely something to avoid for accurate 
> timekeeping!  As you say, changing the HAL is not something to be 
> undertaken lightly.
> 
> I wonder if you could check just the effects of the spread-spectrum being 
> enabled or not?

David,

Yes, I have checked with and without FSB Spread Spectrum with both HALs.

My observations for the 4 combinations are:

Motherboard: A7N8X-X (nForce2)  Windows XP SP 2

HAL: "ACPI Uniprocessor PC" (with APIC, halaacpi.dll):
1) FSB Spread Spectrum = 0.50% :  system clock unstable, NTP did not synchronise
2) FSB Spread Spectrum = disabled :  system clock unstable, NTP did not synchronise

HAL: "Advanced Configuration and Power Interface (ACPI) PC" (no APIC, Halacpi.dll)
3) FSB Spread Spectrum = 0.50% :  system clock stable, NTP synchronised
4) FSB Spread Spectrum = disabled :  system clock stable, NTP synchronised

It's a bit anecdotal, but it seems that FSB Spread Spectrum may not make a big 
difference. However, I'm still running (3), I'll have to check its behaviour 
over a longer period.

It should be mentioned that according to the Microsoft KB article
http://support.microsoft.com/?kbid=821893
there is a quite fundamental difference between the two DLLs:
- Halaapic.dll: uses the Real Time Clock (RTC) to generate clock interrupts
- Halacpi.dll: uses the 8254 Programmable Interval Timer (PIT) to generate clock 
interrupts

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
> John Allen wrote:
> 
>> Richard B. Gilbert wrote:
>>  >My guess would be that your local clock has a frequency error well in
>>  >excess of 500 parts per million!   If that is the case, you will
>>  >probably have to replace the mother board to fix it.
> 
> 
>> As you say, the hopeless inaccuracy of the system clock might be cured
>> only by a new motherboard, although it seems strange that for more
>> than a year it seemed to work fairly well.
> 
> 
> I really was going to give up on this when I made what could be a useful
> discovery. While reading of recurrent problems with system clocks on
> nForce2 motherboards, eg these threads:
> http://www.nforcershq.com/forum/1-vt19631.html
> http://kerneltrap.org/node/4872
> 
> I found references to possibly using a different HAL (Hardware
> Abstraction Layer). I then did what was probably not wise, which was to
> change from
> "ACPI Uniprocessor PC" to "Advanced Configuration and Power Interface
> (ACPI) PC". I also set the BIOS option "FSB Spread Spectrum" to "disabled".
> 
> By good fortune this did not stop the PC working but it has had the
> result that the system clock has been very stable for 24 hours and NTP
> is now working properly, with offsets of no more than 7 ms (from the NTP
> server on my LAN) over long periods:
> 
>>ntpq -c "rv 0"
> assID=0 status=4644 leap_add_sec, sync_ntp, 4 events, event_peer/strat_chg,
> version="ntpd  2004 May 07 8:37:39  (1)"?, processor="unknown",
> system="WINDOWS/NT", leap=01, stratum=4, precision=-20,
> rootdelay=58.614, rootdispersion=153.312, peer=7996, refid=192.168.0.5,
> reftime=c74ae7bc.223db21c  Wed, Dec 14 2005 19:49:32.133, poll=9,
> clock=0xc74ae8e7.5bfd448c, state=4, offset=-7.045, frequency=-7.005,
> noise=3.010, jitter=0.955, stability=1.529
> 
> It may be that this HAL change only works because it disables the APIC
> (Advanced Programmable Interrupt Controller); at any rate, it has made
> me realise how far one can go from what initially appeared to be an NTP
> issue.
> 
> I've noticed that some other threads in this newsgroup have concerned
> PCs with nForce2 motherboards, so this could be a useful hint. However,
> changing HALs should not be done without careful reflection and a
> willingness to reinstall Windows if something goes wrong.
> 
> This site (in German) gives some more information:
> http://www.planet3dnow.de/artikel/diverses/nf2config/3.shtml#config_apic
> 
> as does this:
> http://support.microsoft.com/?kbid=821893
> 
> Moral of the story: if NTP seems to stop working properly and you have
> an nForce2 motherboard (a) the problem is quite possibly not NTP and (b)
> you may not need a new motherboard...
> 

Can you add this to the our Support Twiki? It's always useful to have
this kind of thing easily available and not to have to stumble across it.

Danny

> John
> 
> -- 
> 
> John Allen
> Bofferdange, Luxembourg
> allen{at}vo{dot}lu
> http://www.homepages.lu/allen
> 
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> Hal Murray wrote:
> 
>>>I would have though that "spread spectrum" (implying a continually
>>>changing random frequency) was definitely something to avoid for
>>>accurate timekeeping!  As you say, changing the HAL is not something
>>>to be undertaken lightly.
>>
>>Is "spread spectrym" as used for CPU clocks really going to
>>do anything evil to timekeeping?  Is it really random?  I've been
>>assuming it was some simple modulation pattern - sine or sawtooth.
>>It's all on one chip in a cutthroat business so they aren't going
>>to pay much for it.
>>
>>
>>What does Windows use for timekeeping?
>>
>>Linux (on most boxes) uses the interrupts from the TOY/battery-backed
>>clock, usually running off a 32 KHz watch crystal.  I got surprised
>>by this a few years ago.  The main complication with using the main
>>CPU clock is SMP systems.
>>
>>It's fairly easy to compare the two crystals.  Both track temperature
>>very well.
> 
> 
> For NTP, Windows uses one of the CPU clocks (I forget now if it's RDTSC or 
> the Performance Counter) to interpolate between the Windows ticks (which 
> are at 10 - 15ms intervals).  That's why I asked the OP to try the simple 
> test of disabling the "spread-spectrum" in the BIOS - to see if it did 
> make a difference.
> 

It's currently using the Performance Counter.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> John Allen wrote:
>> Moral of the story: if NTP seems to stop working properly and you have
>> an nForce2 motherboard (a) the problem is quite possibly not NTP and (b)
>> you may not need a new motherboard...

> Can you add this to the our Support Twiki? It's always useful to have
> this kind of thing easily available and not to have to stumble across it.

Yes, I've registered as a user and I will try and add this over the weekend,

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
[]
> David,
>
> Yes, I have checked with and without FSB Spread Spectrum with both
> HALs.
> My observations for the 4 combinations are:
>
> Motherboard: A7N8X-X (nForce2)  Windows XP SP 2
>
> HAL: "ACPI Uniprocessor PC" (with APIC, halaacpi.dll):
> 1) FSB Spread Spectrum = 0.50% :  system clock unstable, NTP did not
> synchronise 2) FSB Spread Spectrum = disabled :  system clock
> unstable, NTP did not synchronise
> HAL: "Advanced Configuration and Power Interface (ACPI) PC" (no APIC,
> Halacpi.dll) 3) FSB Spread Spectrum = 0.50% :  system clock stable,
> NTP synchronised 4) FSB Spread Spectrum = disabled :  system clock
> stable, NTP synchronised
> It's a bit anecdotal, but it seems that FSB Spread Spectrum may not
> make a big difference. However, I'm still running (3), I'll have to
> check its behaviour over a longer period.
>
> It should be mentioned that according to the Microsoft KB article
> http://support.microsoft.com/?kbid=821893
> there is a quite fundamental difference between the two DLLs:
> - Halaapic.dll: uses the Real Time Clock (RTC) to generate clock
> interrupts - Halacpi.dll: uses the 8254 Programmable Interval Timer 
> (PIT) to
> generate clock interrupts
>
> John

That's most interesting, John.  I suppose with the spread-spectrum its 
effect on NTP would depend on what period the spread is over, i.e. if the 
spread is over microseconds but NTP measures over milliseconds, the 
frequency may appear stable.  You might want to enable the statistics 
collection and use a program like Meinberg's NTP Time Server Monitor:

  http://www.meinberg.de/english/sw/time-server-monitor.htm

to see what the stability actually is.  I'm also unclear whether the FSB 
speed will actually have any direct effect on the clocks seen by the 
processor, although it will obviously affect memory retrieval speed.

The information on the HALs was of interest - I have a book in which some 
of this stuff is written up, but not the timing stuff (IIRC).  "Windows 
Internals", fourth edition, is a good read (if you like that sort of 
thing).

I would also appreciate seeing this type of information in the Support 
Twiki (as well as searchable by Google).

Cheers,
David 

Folks,

It seems that since on my PCs I have had the MM timer set to its fastest 
1ms resolution, the poor timekeeping which I had recently seen on my 
Windows XP Pro PC has stopped and, as additional benefit, the timekeeping 
on my Windows 2000 PC has also dramatically improved.

Windows XP:
  http://www.david-taylor.myby.co.uk/mrtg/odin_ntp.html

Windows 2000:
  http://www.david-taylor.myby.co.uk/mrtg/stamsund_ntp.html

This change has been running for the last week or so, on the XP system via 
a program I wrote which runs continuously, and on the Windows 2000 system 
first by my own program, and secondly via a modified NTP.

I haven't made detailed measurements, but have been advised that the 
jitter may not be as good in this mode, but the complete removal of the 
timing transients previously seen more than makes up for this.

I do hope that the NTP with this capability soon becomes generally 
available.

Many thanks to those who helped.

David 

David J Taylor wrote:

> I would also appreciate seeing this type of information in the Support 
> Twiki (as well as searchable by Google).

I added this:
http://ntp.isc.org/bin/view/Support/KnownHardwareIssues#Section_9.1.7.

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
> David J Taylor wrote:
>
>> I would also appreciate seeing this type of information in the
>> Support Twiki (as well as searchable by Google).
>
> I added this:
> http://ntp.isc.org/bin/view/Support/KnownHardwareIssues#Section_9.1.7.
>
> John

Thaanks for that, John.

I tried to edit the information on operating systems to include the 
discover about Windows and the MM timer, but I didn't see a simple way to 
add an entry.  It seemed that I had to edit the whole section.  All I got 
was an Edit link, which produced a whole dialog box of gobbledegook! 
Clicking on either the Cancel or Undo links produced a JavaScript "Error 
on page" message, so adding that information will have to wait until a 
Wiki expert is available.  <G>

David 

David J Taylor wrote:
> John Allen wrote:
>> David J Taylor wrote:
>>
>>> I would also appreciate seeing this type of information in the
>>> Support Twiki (as well as searchable by Google).
>> I added this:
>> http://ntp.isc.org/bin/view/Support/KnownHardwareIssues#Section_9.1.7.

> 
> I tried to edit the information on operating systems to include the 
> discover about Windows and the MM timer, but I didn't see a simple way to 
> add an entry.  It seemed that I had to edit the whole section.  All I got 
> was an Edit link, which produced a whole dialog box of gobbledegook! 
> Clicking on either the Cancel or Undo links produced a JavaScript "Error 
> on page" message, so adding that information will have to wait until a 
> Wiki expert is available.  <G>

Editing the Twiki is a bit strange the first time but I just inserted a new 
section by copying the heading from the previous sub-section and changing the 
name, then I pasted in the text from my emails and used a few basic formatting 
instructions from here
https://ntp.isc.org/bin/view/TWiki/TWikiShorthand

However, I was also blocked by the Javascript "Error on page" every time I tried 
to do work in Internet Explorer. I switched to Firefox and it worked fine. I 
don't know if this is a Twiki bug or an IE settings problem. Even if you don't 
already have Firefox it's a quick and painless installation to solve this problem.

I'd never touched a Wiki before but the technology is interesting, this  was for 
me an excuse to look into it.

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

John Allen wrote:
> David J Taylor wrote:
>> John Allen wrote:
>>> David J Taylor wrote:
>>>
>>>> I would also appreciate seeing this type of information in the
>>>> Support Twiki (as well as searchable by Google).
>>> I added this:
>>> http://ntp.isc.org/bin/view/Support/KnownHardwareIssues#Section_9.1.7.
>
>>
>> I tried to edit the information on operating systems to include the
>> discover about Windows and the MM timer, but I didn't see a simple
>> way to add an entry.  It seemed that I had to edit the whole
>> section.  All I got was an Edit link, which produced a whole dialog
>> box of gobbledegook! Clicking on either the Cancel or Undo links
>> produced a JavaScript "Error on page" message, so adding that
>> information will have to wait until a Wiki expert is available.  <G>
>
> Editing the Twiki is a bit strange the first time but I just inserted
> a new section by copying the heading from the previous sub-section
> and changing the name, then I pasted in the text from my emails and
> used a few basic formatting instructions from here
> https://ntp.isc.org/bin/view/TWiki/TWikiShorthand
>
> However, I was also blocked by the Javascript "Error on page" every
> time I tried to do work in Internet Explorer. I switched to Firefox
> and it worked fine. I don't know if this is a Twiki bug or an IE
> settings problem. Even if you don't already have Firefox it's a quick
> and painless installation to solve this problem.
> I'd never touched a Wiki before but the technology is interesting,
> this  was for me an excuse to look into it.
>
> John

Thanks, John.

Well, if it doesn't work with the world's most popular Web browser, as far 
as I am concerned it needs fixing so that it does.  Sorry, but you won't 
be seeing any Wiki entries from me until it is fixed.  I will not install 
a third-party browser just for this one application.

Why they have to invent yet another mark-up language as well also beats 
me.  We have HTML thanks very much - that's what I use and I'm sticking 
with it for now.

This Wiki implementation, on my first visit as a potential author, seems 
foreign and unfriendly, although the basic idea is one I like.

Cheers,
David 

I edited with IE for quite a while before I converted to firefox, so it was
working with IE.  I haven't checked lately.

H

On 2005-12-17, John Allen <allen{at}vo{dot}lu> wrote:

> David J Taylor wrote:
>
>> I tried to edit the information on operating systems to include the
>> discover about Windows and the MM timer, but I didn't see a simple
>> way to add an entry. It seemed that I had to edit the whole section.

You either add information to an existing topic (aka page) or you start
a new topic.

When you edit an existing topic you edit the whole thing, not just a
portion of it.

>> All I got was an Edit link, which produced a whole dialog box of
>> gobbledegook!

That's the Wiki mark-up (which is explained through various links at the
top of the LHS Memu on the edit page).

There are two ways to start a new topic:

1) Add the TitleOfTheNewTopic (as a WikiWord) to an existing topic. Then
click that link to start editing the new topic.

2) Enter the TitleOfTheNewTopic in the Search/Go box in the upper left
corner of any topic and hit [Enter] or click the GO button. Then click
the edit link on the next page.

>> Clicking on either the Cancel or Undo links produced a JavaScript
>> "Error on page" message, so adding that information will have to wait
>> until a Wiki expert is available. <G>
>
> Editing the Twiki is a bit strange the first time but I just
> inserted a new section by copying the heading from the previous
> sub-section and changing the name, then I pasted in the text from
> my emails and used a few basic formatting instructions from here
> https://ntp.isc.org/bin/view/TWiki/TWikiShorthand
>
> However, I was also blocked by the Javascript "Error on page" every
> time I tried to do work in Internet Explorer.

Please post the actual error (from your browser's Javascript console).

I don't use Microsoft Windows so I can't use MSIE to check this report
out.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

On 2005-12-17, David J Taylor <david-taylor@blueyonder.co.uk> wrote:

> Well, if it doesn't work with the world's most popular Web browser, as
> far as I am concerned it needs fixing so that it does.

Providing detailed error information (i.e. more than just "Page error")
will help us address this issue.

> Why they have to invent yet another mark-up language as well also
> beats me. We have HTML thanks very much - that's what I use and I'm
> sticking with it for now.

(from: http://fishbowl.pastiche.org/2004/03/19/in_defense_of_wiki_markup)

| Wiki markup solves a set of problems that are important for Wikis to
| solve:
|
| 1. Pages are editable solely in the web browser, not requiring any
| additional software to be installed or called up for editing.
|
| 2. The page in the text area gives visual clues as to what the
| finished page will look like: bullet-points look like bullet-points,
| and the various kinds of in-line emphasis look like the sort of thing
| we've been using in email for years.
|
| 3. The markup is simple enough that it can be described very quickly.
| The important parts of Confluences markup can be described succinctly
| in a side-bar on the edit page.
|
| 4. The Wiki doesn't have to worry about defending itself against the
| latest Cross-Site Scripting technique or whatever markup crashes
| Internet Explorer today.

<snip>

| Sure, you end up with something thats significantly less powerful than
| HTML. This is a feature. A wiki page isn't a place for complicated
| markup, it's for writing stuff down. The more power you put in the markup
| language, the more people are going to be wanking around with the
| precise arrangement of angle-brackets that will make their paragraphs
| step from left-to-right in pixel-perfect harmony in lieu of saying
| something.

> This Wiki implementation, on my first visit as a potential author, seems 
> foreign and unfriendly, although the basic idea is one I like.

Wikis all work in pretty much the same way, although the mark-up tends
to be implementation-specific.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke wrote:
> On 2005-12-17, David J Taylor <david-taylor@blueyonder.co.uk> wrote:
>
>> Well, if it doesn't work with the world's most popular Web browser,
>> as far as I am concerned it needs fixing so that it does.
>
> Providing detailed error information (i.e. more than just "Page
> error") will help us address this issue.

- I go into the topic

- click on the edit link

- I make some changes

- I click on the preview link (I don't see a "Save changes" button?)

- in the status bar of my browser, I get the message "Error on page"

Of the links at the top right:
  Edit is disabled and coloured red when I'm editing.
  Undo works OK
  Preview, Change form, Save and Cancel all produce the error message

David 

Steve Kostecke wrote:
[]
> Please post the actual error (from your browser's Javascript console).
>
> I don't use Microsoft Windows so I can't use MSIE to check this report
> out.

Thanks for the information, Steve.

There is nothing listed in the Sun Java Console, if that's what you mean, 
when I enable this from the browser.

David 

Steve Kostecke wrote:
[]
> Wikis all work in pretty much the same way, although the mark-up tends
> to be implementation-specific.

Thanks for all the information about the Wiki, Steve, but it still seems 
unfriendly to me (as someone who is more used to a more visual approach to 
editing).

David 

Steve Kostecke wrote:
>> However, I was also blocked by the Javascript "Error on page" every
>> time I tried to do work in Internet Explorer.
> 
> Please post the actual error (from your browser's Javascript console).

The error was reported by IE as:

Line: 50
Char: 3
Error: Object doesn't support this property or method
Code: 0
URL: https://ntp.isc.org/bin/edit/Support/KnownHardwareIssues?t=1134919033

John

--

John Allen
Bofferdange, Luxembourg
allen{at}vo{dot}lu
http://www.homepages.lu/allen

On 2005-12-18, John Allen <allen{at}vo{dot}lu> wrote:

> The error was reported by IE as:
>
> Line: 50
> Char: 3
> Error: Object doesn't support this property or method
> Code: 0
> URL: https://ntp.isc.org/bin/edit/Support/KnownHardwareIssues?t=1134919033

Thanks! That information helps alot.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

On 2005-12-16, David J Taylor
<david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
wrote:

> I would also appreciate seeing this type of information in the Support 
> Twiki (as well as searchable by Google).

The Support Web of the NTP Public Services Project web-site (aka the
Support TWiki) _is_ indexed by Google.

BTW: The 'site:blah' Google search keyword is useful for restricting a
search to a particular web-site.

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

Steve Kostecke wrote:
> On 2005-12-16, David J Taylor
> <david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk.invalid>
> wrote:
>
>> I would also appreciate seeing this type of information in the
>> Support Twiki (as well as searchable by Google).
>
> The Support Web of the NTP Public Services Project web-site (aka the
> Support TWiki) _is_ indexed by Google.
>
> BTW: The 'site:blah' Google search keyword is useful for restricting a
> search to a particular web-site.

Excellent, Steve.  I just checked a keyword of:

"-XX:+ForceTimeHighResolution"

with no site keyword, and ntp.isc.org came in as number 8 out of 80 
matches.

Thanks,
David