| according to the ntp.conf doc on Digital UNIX,
peer vs. server seems to control who can update whom
(peer is symmetrical, if you chose server, it updates you,
but won't accept updates from you). In fact, I expect
you can choose either, but those who run the ntp servers
in MRO probably would ignore you, anyway).
I don't think either of those choices affect how you
act as a server to other clients. This assumes that
xntpd on NT is similar to UNIX, but I expect it is in
this area, anyway.
|
| > I don't think either of those choices affect how you
> act as a server to other clients. This assumes that
> xntpd on NT is similar to UNIX, but I expect it is in
> this area, anyway.
Actually, it's stronger than that. It's the same code recompiled
for NT.
Danny
|
| You can have a, b, and c all updating each other by having
a:
server b
server c
and b:
server a
server c
and c:
server b
server c
What this says is that a will set its time only when it has queried b and c
for the time.
IF you substitute peer for server, then a will set its time both when it queries
b and c, but also when b and c query it.
The actual messages on the wire are the same in both cases, but there are more
data points when you use peer.
(I use the term "set its time" loosely; no single time sync results in a
specific time adjustment. All time adjustments for NTP (and DTSS) require
a set of time samples which are then combined to compute an estimate of the
correct time.)
There is one fundamental difference between NTP and DTSS and that is that NTP
is trying to get all clocks to tick in synchrony. In order for this to happen
you need to have lots of data points so that you can filter out the jitter
caused by the relatively low precision of the ticker (100 to 1000 per second)
and the effects of LAN and WAN queuing delays which varies depending on
whether you get in behind a small or large packet. The value is a timestamp
rapidly decays with NTP so that its effect isn't noticed an hour later.
DTSS uses a different algorithm with a different result being produced so that
a timestamp from an hour ago can have more influence than one just this second.
So, to satisfy the requirement for more samples, NTP can be setup to generate
a lot of traffic which will scale at order n*s where n is the total node count
and s is the number of servers. (Gee, that is worse than "evil" LAT.) So, to
address that problem, NTP also has a broadcast mode. The idea is that you
join a broadcast group and get your samples at the same time that other
clients and servers do. I believe that this mode is in "beta test".
What I don't like about NTP is that
its setup is complicated
the architecrure is complicated
the implementation are complicated with a lot of tuning knobs whose
values have been resulted in recommended architectural constants
but most important, a server is either the best or not so best, whatever
the system manager decided when he setup either the server or the
client (server)
"I happen to know that the mro time servers are fed by a time feed on the roof,
so they should be regarded as accurate."
Whether they should be regarded as accurate is irrelevant; if the system manager
who set them up says they are, and you don't override him by specifying a
stratum for them in your conf, then they are accurate even if they are totally
bogus.
Here in NIO, Dave Fox had setup two Netclock/2s which had been very reliable
and accurate for years. Then about 4-5 months ago we noticed that they didn't
seem to be syncing up with WWV. These things operate in the 60kHz range,
but as best as we can determine they are being interfered with by pager and
cell traffic in the 900mHz range. There are actually three units in NIO with
three separate antennas spread over the roof, and all are having trouble.
My advice.
Do not depend on time from a single management source.
Do not depend on time from a single geography/building.
Spend some time learning how to interpret the output from NTP's management
interface. DTSS is much less complicated, but it has taken me a long time
to be able to verify the output from it management to determine if things
are working as expected and when they are, why the time is, or is not, screwed
up.
For example, you should figure out if this is something to worry about:
"status=0606 clk_badtime, last_clk_badtime"
All three of those servers are reporting that for their Spectracom WWVB receiver
(are there really three Spectracoms in mro?)
|