[ntp:questions] Odd reachability with local clock on XP

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Oct 10 13:19:39 UTC 2013


On 2013-10-09 20:28, Philip Prindeville wrote:
>
> On Oct 9, 2013, at 6:26 PM, unruh <unruh at invalid.ca> wrote:
>
>> On 2013-10-09, Philip Prindeville <philipp_subx at redfish-solutions.com> wrote:
>>> Hi,
>>>
>>> I'm running ntp-4.2.6p5 on Windows XP (SP3).  I have, amongst other things, the following in my config:
>>>
>>> server 127.127.1.0 noselect minpoll 4 maxpoll 6
>>> fudge 127.127.1.0 stratum 10
>>
>> Why would you have that? It is really dumb in almost all cases.
>
> I have it for instrumentation purposes.  I'm trying to track the accuracy of an XP box as a local reference clock (it will not be peered with any other time servers nor have any external clocks) versus a reliable time source such as an appliance with a CDMA or GPS receiver.
>
> A customer believes that PC time is "good enough" for their purposes, and I need to convince them otherwise.
>
>
>>
>>>
>>> and I'm running ntpd as a system service, not from the command line.
>>>
>>> I've disabled the firewall, though for loopback it shouldn't make a difference.
>>>
>>> When I start the service, I see:
>>>
>>> D:\>ntpq -n -p
>>>      remote           refid      st t when poll reach   delay   offset  jitter
>>> ==============================================================================
>>> 72.14.188.52    129.7.1.66       2 u    1   16    1   57.919    2.743   2.143
>>> 149.20.68.17    66.220.9.122     2 u    1   16    1   28.563   -1.284   3.361
>>> 204.2.134.164   253.235.63.48    3 u    2   16    1   28.708   -2.060   3.291
>>> 173.244.211.10  204.42.158.152   2 u    1   16    1   16.708    0.080   3.606
>>> *10.9.160.101    .GPS.            1 u    2   16    1    0.292    0.229   0.082
>>> 127.127.1.0     .LOCL.          10 l    7   16    1    0.000    0.000   0.000
>>>
>>> but after a while this deteriorates and I see:
>>>
>>> D:\>ntpq -n -p
>>>      remote           refid      st t when poll reach   delay   offset  jitter
>>> ==============================================================================
>>> 72.14.188.52    129.7.1.66       2 u    5   16    7   57.919    2.743   2.258
>>> 149.20.68.17    66.220.9.122     2 u    5   16    7   28.563   -1.284   3.117
>>> 204.2.134.164   253.235.63.48    3 u    4   16    7   26.888   -1.318   2.446
>>> 173.244.211.10  204.42.158.152   2 u    3   16    7   16.708    0.080   3.399
>>> *10.9.160.101    .GPS.            1 u    2   16    7    0.251    0.213   0.050
>>> 127.127.1.0     .LOCL.          10 l   37   16    4    0.000    0.000   0.000
>>>
>>> ...
>>>
>>> D:\>ntpq -n -p
>>>      remote           refid      st t when poll reach   delay   offset  jitter
>>> ==============================================================================
>>> 72.14.188.52    129.7.1.66       2 u   13   16  377   59.664    3.959   2.797
>>> 149.20.68.17    127.67.113.92    2 u   12   16  377   28.795   -1.356   3.391
>>> 204.2.134.164   129.250.35.250   3 u   12   16  377   26.953   -1.621   3.173
>>> 173.244.211.10  204.42.158.152   2 u   11   16  377   23.353    2.167   1.134
>>> *10.9.160.101    .GPS.            1 u   10   16  377    0.289   -0.112   0.016
>>> 127.127.1.0     .LOCL.          10 l  77m   16    0    0.000    0.000   0.000
>>>
>>> Not really sure why only the first packet gets through and no subsequent ones do.
>>>
>>> Anyone else seen a similar issue?
>>
>> This sounds like a "Doctor, it hurts when I bang my head against a brick
>> wall." question.
>> Also why are you polling public servers with poll 4? Seems a bit
>> unfriendly to me.
>
> That part I didn't set up.  But I can trim the maxpoll to 6.

I would increase the remote servers minpoll to 6 or 8, maxpoll to 10, set them 
and the ref clock to noselect, and set the undisciplined local clock to prefer, 
forcing it to be selected. The undisciplined local clock driver will be ignored 
and effectively disabled if any other time source is selectable. Also ensure the 
1 ms MM timer is disabled (no ntpd -M option), enable a normal Power Plan 
(Balanced or whatever), and set Spread Spectrum etc. in the BIOS setup.

That will allow you to collect loop and peer stats showing how far the 
undisciplined local clock gets from your ref clock and the remote peers.

After a few days of drift you could also set up Windows Time Service (or w32time 
on XP?) to check the remote servers every 1024 seconds and monitor how well that 
does, but remember to disable Windows Time Service when testing that is complete.

Wait a week to collect stats, then remove prefer from the undisciplined local 
clock, set the ref clock to prefer, remove noselect from the remote peers, set 
the ntpd -M option to enable the the 1 ms MM timer, set the Power Plan to High 
Performance or equivalent and disable all Sleep states, disable Spread Spectrum 
etc. in the BIOS setup, restart ntpd and collect stats for another week.



More information about the questions mailing list