[ntp:questions] Odd reachability with local clock on XP
Philip Prindeville
philipp_subx at redfish-solutions.com
Thu Oct 10 02:28:48 UTC 2013
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.
-Philip
More information about the questions
mailing list