[ntp:questions] Re: Questions and ruminations regarding NTPD 4 config and XP's bad behavior.

elickd at one.net elickd at one.net
Mon Jan 17 22:41:38 UTC 2005


Of all the questions facing me, the most vexing is how 170 odd XP boxes
are showing up in the "ntpq -p" output of our stratum 3 servers (Linux,
NTPv4); said boxes certainly are not enumerated in their "ntp.conf".
The only difference between these XP machines and the hundreds of
identical units that do not show up is that they're set to auto-sync.
their time once a week.

I can't think of any other mechanism for their associations other than
there is some wierd interaction between them and the strat. 3 servers
when they poll. Perhaps that multicast is turned on (on the servers) is
a factor?
All our stratum 3 NTP4 servers have the following stanzas in their
config.:

multicastclient
broadcastdelay	0.008

What other possible mechanism could account for them showing up like
this?

I can also confirm that if one specifies a random XP box that's been
updated sometime in the past as a peer or server to a SCO NTPv3
"client", that SCO machine will happily query and update. If the XP box
hasn't been updated in quite a while, it'll show up as a stratum 16
source, but as soon as it is, it'll ascend to one stratum lower than
it's source (as quasi-expected).  What's surprising however, is one can
manually change the clock time fowards and back (being sure to "apply")
and the poor SCO box will try to follow for a while before it marks the
XP box "insane".  What's also interesting is after an undetermined
period of time, the offset for our chatty XP friend as listed by ntpq
or ntpdate becomes a static number.


Normally I'd agree that a couple rogue XP boxes 1 stratum lower than
the time servers should not be a factor. What happens when you have
170+ of them, though?  What happens if your stratum 3 time servers,
which all have their system clocks fudged to 10, cannot reach the
strat. 2 boxes?  Suddenly all those insane Stratum 4 XP boxes start to
look mighty attractive, don't they? Yikes!

But why then are my NTP servers paying attention to XP stations at all?
The fact is that regardless of what *should be* possible, I'm seeing a
great many evil XP boxes being polled by our NTP servers. Perhaps the
Micro$oft time implementation is more FUBARed than we realize?  This is
not to say the network I'm dealing with isn't as equally "special".

To the rest of you who've been offering much appreciated suggestions as
well, I wholeheartedly agree that a stratum 1 time server within the
company would be preferred. If I had the authority, I'd make a great
many changes; however, I do not. Right now I need to assemble a
business case for every single change I propose.  I work at a very
large company where one does not tinker with the
network/servers/software without months of testing and approval.
Anyone have any suggestions how one might word an "Executive Summary"
explaining why they should spend money/man hours on the hardware
neccessary to operate a Stratum 1 time source?  I'm all ears.

Bewteen the lack of information about machines out of my "domain", XP
acting on undocumented "features" and she sheer quantity of variables
to deal with, I'm at wit's end.

Any thoughts?

Thanks in advance,

Doug

David L. Mills wrote:
> Doug,
>
> XP is normally configured not to operate as a server, as I just now
mave
> confirmed. If so, they violate not only the NTP protocol (using
> symmetric rather than client mode) but violate the SNTP prohibition
not
> to opeate as a server unless directly synchronized to a broadcast or
> modem source.
>
> A server with nominal frequency error of 100 PPM will be in error
8.64
> seconds after one day and one minute after one week. The same thing
> holds for ntpdate. If the error expectations are less than a minute
or
> so, not to worry. However, clock errors over such periods are
dominated
> by random-walk phenomena, so there is a chance, althoug a small one,
> that a chain of servers like that can accumulate errors of many
minutes 
> at the end of the chains.
> 
> Dave
> 
>




More information about the questions mailing list