Re: Question about NTP.CONF master and local-master commands

On Jul 6, 7:44 pm, John Santos <john.san...@xxxxxxxxxxxxxxxx> wrote:
In article <3ec340fb-9aad-4166-800b-
6eb395883...@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, spamsink2...@xxxxxxxxx
says...
On Jul 3, 10:37 pm, John Santos <j...@xxxxxxx> wrote:
AEF wrote:
[...]

Can you explain the point of the peer command? I still don't get that.

I think your later questions about peers stem from this, so if I
explain it adequately, I won't have to answer them :-)

Peers compare their clocks and average them. This gets a more
accurate time and converges on an accurate time more quickly
than a single client trying to sync with a server. The farther
away the server is (in hops, latency, etc., rather than in
pure physical distance, though of course physical distance
matters), the more inaccurate the clock will be. NTP attempts
to compensate for delays and variations in the round-trip time
between the clients and the servers, but on the Internet, strange
things can happen (dropped packets, routes changing due to circuits
going up an down or due to congestion, etc.) A bunch of peers at
one site can compare their clocks and average them. They can
also compare the round-trip times to the server(s) and get a
better idea of how to compensate.

If the link to the remote server goes down, the local servers,
by peering, can keep time for the local network much more
accurately than a single server could. They can compensate for
inaccurate hardware clocks, missed interrupts etc. (These things
are unlikely to affect all the local servers identically, so if
two of them notice the third is out of whack, they'll all set their
times to most closely match the 2 still in sync, and the odds are
it it will be a more accurate time.)

I'm not sure you actually want to use local-master on any of the
local servers unless you *know* that particular server has an
extremely accurate clock (like it's being set by an atomic clock
or radio time signal, rather than just by counting cycles of a
typical PC-grade clock chip, which is what most Alphas, Itaniums,
and "recent" VAXes use. I think you are better off just declaring
a bunch (3 or so) of them as peers, and letting them average
their clocks. When the link to the remote master is up, all the
local servers will sync off it anyway, so it doesn't matter if
they are local-masters or not. It's only when they've lost
contact that it matters.

Well, if the remote server goes down, and if one of them is synching
up to some (well, it's got to be some other) external NTP server, then
what's the point? I'd just have all 3 of them synched to it anyway.


[...]
But why do I need the peer commands as opposed to server commands?

[...]

If the server is down, the peers will sync with each other. If any of
them had previously synced with the server (before it went down),
they'll collectively keep better time until the server comes back.

I tried setting up two test servers to peer each other. Just one line
each in their respective NPT.CONF files:

peer <the other server>

and nothing useful happened as far as I could tell. Perhaps I should
have waited a day or two to see if they stayed synched up. Here's what
happened:

3 Jul 18:23:46 selected new sync source 10.1.10.24, now at stratum 3
NODE15$ type ntp.conf
peer NODE08
slewalways
NODE15$ @restart ntp
%RUN-S-PROC_ID, identification of created process is 000003EA
NODE15$
%%%%%%%%%%% OPCOM 5-JUL-2008 20:10:05.64 %%%%%%%%%%%
Message from user SYSTEM on NODE15
%TCPWARE_NTP-I-ACQUIRED, acquired peer 10.1.10.181



NODE15$ type ntpserver.log;
5 Jul 20:09:33 NTPD started
5 Jul 20:10:05 acquired peer 10.1.10.181
NODE15$
%%%%%%%%%%% OPCOM 5-JUL-2008 20:18:37.60 %%%%%%%%%%%
Message from user SYSTEM on NODE15
%TCPWARE_NTP-I-LOSTCONTACT, lost contact with peer 10.1.10.181

On the other node:

NODE08$ TYPE NTPSERVER.LOG
5 Jul 20:10:20 NTPD started
NODE08$ TYPE NTPSERVER.LOG
5 Jul 20:10:20 NTPD started

Therefore, I thought I needed the local-master commands.

The 3 NYC server VAXes would all have

server NYC-NTP-SERVER
peer NYCVAX2
peer NYCVAX3

(or NYCVAX1 & NYCVAX3 for NYCVAX2, or NYCVAX1 and NYCVAX2 for
NYCVAX3)

The 3 London server VAXes would have

server NYCVAX1
server NYCVAX2
server NYCVAX3
peer LondonVAX2
peer LondonVAX3

(substituting appropriately for LondonVAX2 and 3.)

Looks fine, but I still don't see why you need peer instead of server
or why it's better. Can you please explain it?

What do you mean "instead of"? Do you want to tell system A that it's
server is system B, and tell system B its server is system A? That
makes no sense to me, and I think would keep the systems from ever
syncing their clocks.

I'd chain them, I guess: A --> B --> C.


Is your question "why have peers at all?" or is it "Why use the keyword
peer instead of server for the other servers in the same LAN?" I think

The former, but I understand "peers" a lot better now.

I explained why to have peers above. Why to treat the NYC servers as
servers and the other London ones as peers, is the NYC servers are
"closer" to the official NTP server (which is presumably either syncing
with a more accurate clock on the Internet, or getting it's time from
some other, accurate source, such as a WWV receiver). You could ADD
the NTP server (which I called NYC-NTP-SERVER above) as a 4th NTP server
in the London configs, but once the NYC VAX servers have synced, they
would be just as good, and it's considered bad manners to bother the
higher up servers excessively. (That's why you don't just put
"server NYC-NTP-SERVER" as the entire ntp.conf file on *all* the VAXes.
Doing it heirarchically drastically reduces the network traffic on the
WAN links and the load on the higher stratum servers, while not
affecting accuracy very much.

I thought the NTP protocal was a very small load. I never see anything
significant going on.


Also, in the example in the TCPware Mgmt. manual, they have peer
commands that "peer" with themselves! Example:

; NTP configuration on 192.168.67.3
local-master 12
server 192.168.67.1
server 192.168.34.1
server 192.168.34.2
peer 192.168.67.3

What's the point of that, or is it a typo on TCPware's part?

Maybe so you can use the same ntp.conf on all the nodes. I didn't
know this worked, if it does, it would reduce management headaches
since you would only have to maintain 2 or 3 different NTP.CONF
files instead of a different one for each server. (One for all
clients (or one all clients in each area), one for all local servers,
and maybe a global one for higher stratum servers.) In your case,
you could have 4 distinct NTP.CONF's (NYC clients, London clients,
NYC servers and London servers) vs. 8 NTP.CONFs (NYC clients,
London clients, and one for each of your 6 servers.)

Well, they do suggest a different one for each of the servers in the
work area while the three in the server commands above are in the
"climate-controlled room".

I was hoping the online manual would have the example in it, but it
doesn't. So here goes some typing:

In the text and diagram we find that the first three servers are in
the climate-controlled room with 192.168.67.1 on a radio link and the
x, y, z, ... are "on the floor".

===============================================================================
; NTP Confuguration on 192.168.67.1

master-clock 1
===============================================================================
===============================================================================
; NTP Config on 192.168.67.2

local-master 10
server 192.168.67.1
server 192.168.34.1
server 192.168.34.2
peer 192.168.67.2
===============================================================================
; NTP Config on 192.168.67.3

local-master 12
server 192.168.67.1
server 192.168.34.1
server 192.168.34.2
peer 192.168.67.3
===============================================================================
; NTP Config for Computer RoomHost 192.168.67.x

server 192.168.67.1
server 192.168.67.2
server 192.168.67.3
peer 192.168.67.y
peer 192.168.67.z
..
..
..
===============================================================================

Comments?

All the other NYC VAXes would have:

server NYCVAX1
server NYCVAX2
server NYCVAX3

and all the other London VAXes would have:

server LondonVAX1
server LondonVAX2
server LondonVAX3

in there respective NTP.CONF files.

Yes, this is what I was going to do for them.

But... would it make sense to add "server NYC-NTP-SERVER" to all the
VAX systems in case the three local-masters in NYC go down or are
taken down, or am I being to paranoid, or is that a bad idea for some
other reason? Or should I just add "peer <remaining VAX systems in
this city" as in the example in the TCPware manual?

BTW, my motivation is to have all the times correct based on UTC, and
if I lose connection to the data center's NTP server, at least have
all the VAX systems synchronized to each other.

Thanks again.

NTP *always* works on UTC. For VMS systems which are usually/often
based on the local time zone, the NTP client has to convert the UTC
time to local time before setting the clock, and the NTP server has
to convert the local clock time to UTC before supplying it to clients.

I didn't mean to imply that it didn't. Ideally I want all the VAX
systems to be UTC or my designated number of hours away from UTC as
some servers are set to UTC, some to UTC+2, and some to ET. Failing
that, I want them to at least be synchronized together. If they drift
a few seconds from being based on UTC when the company NTP server is
down for a few days it's no big deal.


It doesn't matter if your systems are all running on UTC or if some
are on London time and others are on NYC (Eastern US) time, or anything
else, TCPware and/or HP TCP/IP's NTP software takes care of this.

Yes, I know.


I assume windows NTP clients do the same. Most (all?) Unix systems
keep their system clock in UTC, so it isn't an issue for them.

Thanks again for your help.

--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

AEF

--
John

AEF
.

Relevant Pages

  • Re: Correcting my time servers clock drift on AlphaES40s / Tru64
    ... of a working NTP setup, but is not a design objective of NTP. ... is then a stratum 1 time server, Phillip looks to Terrance as its time server, ... with Terrance reading it's system clock. ... In that case, you need to create a clear server hierarchy, not to peer, ...
    (comp.protocols.time.ntp)
  • Re: Which release notes say sts$manager:utc$configure_tdf is obsolete
    ... >>in UTC, and after comparing it to the time as determined from its ... I think it will only attempt to change the clock if it is less than ... or a ST clock just after the spring forward, and NTP would fix it. ... guess of the real time that it makes from polling the time server. ...
    (comp.os.vms)
  • Re: NTP Loses sync over time.
    ... SNTP is not NTP and one can expect SNTP implementations to drift by ... the full clock frequency error between polls. ... A minute a day exceeds the capture range of the full version 4 NTP ... If the server is using a broken source ...
    (comp.protocols.time.ntp)
  • Re: Isolated Network Drift Problem
    ... No. PCs keep time even without NTP installed. ... clock reference will be able to provide time to NTP clients. ... page at ntp.org I'm thinking that a combination of a master server using ... If it is not possible for you to have your own stratum 1 time server, there are a fair number of them on the internet. ...
    (comp.protocols.time.ntp)
  • Re: Correcting my time servers clock drift on AlphaES40s / Tru64
    ... Keeping several machines together is a pleasant side-effect of a working NTP setup, but is not a design objective of NTP. ... is then a stratum 1 time server, Phillip looks to Terrance as its time server, and all is well. ... use ntp on phillip to get time from ntpd on Terrance, with Terrance reading it's system clock. ... In that case, you need to create a clear server hierarchy, not to peer, ...
    (comp.protocols.time.ntp)