Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
Brian Utterback wrote:
Be careful with this generalization.
While it may be trivial, it isn't automatic.
I deal with customers all the time that have configured
exactly two servers on their clients and then are
surprised later when all of the clients become
unsynchronized and start free drifting.
I always recommend against it.
I still think that it takes four to guarantee a majority
but I don't have proof of that.
Someday I will spend some time to either prove or disprove it,
but alas, time is something I don't generally have extra to spend.
But you are better off with one than two from an operational standpoint.
While not disagreeing; Several things can be done to minimize
the two NTP servers don't agree issue.
If as Rob pointed out they both get GPS PPS,
and they are peered with each other,
they won't get far apart except when one has issues.
In many cases the TOS mindist would already be increased
from 1ms due to NEMA vs PPS skew from the GPS.
e.g.
# in ntp.conf for ALL Primary Servers
# Start ntpd with -g, the -g will prevent a panic stop if the time needs to be
stepped when started
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict source nomodify
tos cohort 1 orphan 11 mindist 0.4
keys /etc/ntp.keys # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY ,
...
trustedkey 123 321
broadcastclient
multicastclient 224.0.1.1 key 123 preempt
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
# Corp LAN S1/S2(s)
peer a.ntp.lan.corp.example.com key 321 iburst preempt minpoll 4 # 16sec
peer b.ntp.lan.corp.example.com key 321 iburst preempt minpoll 4 # 16sec
pool pool.ntp.remote.corp.example.com key 321 iburst preempt minpoll 7 # 2min
pool ntp.isp.example.net iburst preempt minpoll 7 # 2min
pool ntp.osvendor.example.net iburst preempt minpoll 8 # 4min
pool ntp.regional.timebase.org iburst preempt minpoll 8 # 4min
pool pool.ntp.org preempt minpoll 8 # 4min
... GPS Config prefer minpoll 4 maxpoll 4 # 16sec prefer only the GPS
If the Clients also had an increased TOS mindist set,
that would increase the clients likelihood of accepting
both servers (when the servers don't have issues).
In addition, if manycast orphan is also configured
on the servers / clients, they will still follow
each other around, instead of drifting apart
if the primary NTP servers have issues;
{which actually makes it more than 2 servers also}.
e.g.
# in ntp.conf for ALL Clients
# Start ntpd with -g, the -g will prevent a panic stop if the time needs to be
stepped when started
restrict -6 default limited kod nomodify notrap nopeer noquery
restrict ::1
restrict -4 default limited kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 224.0.1.1 mask 255.255.255.255 nomodify
restrict source nomodify
tos cohort 1 orphan 11 mindist 0.4
keys /etc/ntp.keys # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY ,
...
trustedkey 123 321
broadcastclient
multicastclient 224.0.1.1 key 123 preempt
manycastserver 224.0.1.1
manycastclient 224.0.1.1 key 123 preempt
# Corp LAN S1/S2(s)
server a.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 # 1min
server b.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 # 1min
pool pool.ntp.lan.corp.example.com key 321 iburst preempt prefer minpoll 6 #
1min
pool pool.ntp.remote.corp.example.com key 321 iburst preempt minpoll 7 # 2min
--
E-Mail Sent to this address blackl...@anitech-systems.com
will be added to the BlackLists.
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-03, Brian Utterback brian.utterb...@oracle.com wrote: On 12/2/2014 4:00 AM, Rob wrote: The whole have 3 servers to select a majority thing is absolutely not required when your servers are accurately synchronized themselves and your requirements are only within-a-second. It is true that when you have two servers the clients cannot know which one is right, but it is trivial to keep servers within a millisecond of eachother with GPS and within 10 milliseconds using only network peering. To that is two orders of magnitude better than you require. Be careful with this generalization. While it may be trivial, it isn't automatic. I deal with customers all the time that have configured exactly two servers on their clients and then are surprised later when all of the clients become unsynchronized and start free drifting. I always recommend against it. I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. One or three. Three allows two to outvote one rogue time source. One has no idea what the time is except what that one says. Four will often allow 2 to outvote each of two rogue sources, if those two rogues are not going rogue in exactly the same way. (No matter how many GPS time sources you have, they will all go rogue in the same say if the GPS sattelite system goes crazy for example. However if a couple of the receivers develop some harware fault they will probably deliver different times from each other) Five will allow three to outvote two rogue, even if the two collude with each other. etc. So you decide on the level of redundancy you want, and take your choice. Brian Utterback ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Number of Stratum 1 Stratum 2 Peers
On 2014-12-03, Jan Ceuleers jan.ceule...@computer.org wrote: On 12/03/2014 02:58 PM, Brian Utterback wrote: I still think that it takes four to guarantee a majority but I don't have proof of that. Someday I will spend some time to either prove or disprove it, but alas, time is something I don't generally have extra to spend. But you are better off with one than two from an operational standpoint. It takes three servers *at all times* to enable clients to use majority voting. So if you want to guard against a single failure (i.e. not a single falseticker, a single server that goes offline), then you need four. Offline IS a false ticker. And no, you need three. In fact to gaurd against offline, you only need two. Guarding against falseticking is harder than guarding against offline. Just as it is harder to guard against a liar than a dead man. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
