In article <[EMAIL PROTECTED]> "Maarten Wiltink" <[EMAIL PROTECTED]> writes: >"Per Hedeland" <[EMAIL PROTECTED]> wrote in message >news:[EMAIL PROTECTED] >[...] >> Actually you'd likely want to configure those "main" servers as peers >> to each other even if you weren't using orphan mode, thus orphan mode >> just becomes a simple addition for increased reliability in case your >> Internet link goes down - and much better than the "local clock with >> minimum of 2 stratum difference" hack that has been the standard >> recommendation, of course. > >Allow me to play devil's advocate. How is it 'much better'?
Well, maybe not "much", but I definitely think it's "better".:-) > You're >still picking a single clock to follow, only now it's a random one. I guess this is correct for the current implementation, though there ought to be a potential for an "intelligent" selection - e.g. taking the drift value into consideration to reduce the risk of this problem: >If you had good sync before, all your servers will be running at close >to 1 sec/sec already and there isn't much of a problem, but on an >isolated site it may still happen that a very slow or very fast server >is randomly selected and very fast or very slow clients run afoul of >the 500 PPM limit where they didn't really need to. So this would still be true (though maybe not very likely, nor disastrous). But orphan mode is much simpler to configure than "local clock with stratum diff": - a naive user may not even realize that the stratum diff "should" be used, and end up with servers that start drifting apart as soon as the external sync is lost - if you start at the recommended stratum 10, you run out of strata at the third server (or earlier if you have more than one tier of clients). Furthermore, the "stratum diff" really *is* a hack in the bad sense, i.e. it may not work - it is probably likely that the server with local clock at stratum N will select his buddy advertising N-1 rather than his own local clock, but certainly not guaranteed. --Per Hedeland [EMAIL PROTECTED] _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
