[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::dtss

Title:DTSS_NOTE
Moderator:TUXEDO::BARYIAMES
Created:Mon Jul 31 1989
Last Modified:Wed May 28 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:624
Total number of notes:2671

623.0. "time-provider and DTSSservers on LAN" by NNTPD::"[email protected]" (Martin Fuehwirth) Tue May 27 1997 13:16

Xposted in DTSS and DECNET-OSI_for_VMS

hi,

i've troubles solving a DTSS problem.

config:

four DTSSservers;
one DTSSserver is equiped with a time-provider,
and three DTSSservers, all on the same LAN.

problem:

the three DTSSserver synchorize with each other, but all
three together drift away from the DTSSserver with the time-provider.

all four DTSSservers are configured as NONCOURIER (no WAN at all).

the time of the DTSSserver with the time-provider is correct -
        - checked with PTT telephon time service.

the idea is to have a working DTSSserver environment in the case
that the time-provider hardware breaks.


there is one comment from my customer, which i also don't understand
and what i can't verify:
the whole configuration sould have worked fine until changing from 
winter to daylight-saving-time last march.

what they have done as an workaround is configuring 
server/clerk-environment, where the DTSSserver that one with 
the time-provider.

question:

is the desired config valid?
what could be wrong?

thanks in advance for your help
martin
[Posted by WWW Notes gateway]
T.RTitleUserPersonal
Name
DateLines
623.1my guessTWICK::PETTENGILLmulpWed May 28 1997 23:3128
when time changed, my guess is that the TDF got screwed up on either the
one node with the time provider or on the three nodes without the time
provider.

If this were the case, the displayed system time would be correct, but the
UTC time that DTSS uses would have been off by an hour.  Since this would
have not intersected with the current time interval, there would have been
a fault.  The way that faults is resolved is by looking for the smallest
interval that includes the maximum number of systems (and the local system
doesn't have a higher weight than any of the others, so the local server
can be declared faulty).  With four servers, it would require that three
servers agree.

Now there is an exception to this "majority rule" rule: the Time Provider
is King.  This means that the system with the external TP will not pay
any attention to the other servers as far as setting the time is concerned.

However, all of this will be noisily reported in the DECnet event log
as time server faults and non-intersecting times.  If you enable the
event logger and look at the output after 24 hours, I think that you
will see where the disagreement lies.  As long as you have control over
the systems, its easy to resolve the problem.

(The problem I have is figuring out shich time server is faulty when they are
scattered around the world; if I can issue a "ncl sho node foo dtss all" then
I can pretty much track down the source of a time fault in a global environment,
but the event logging is what points out the problem and provides the starting
point.)