----- On Jul 2, 2019, at 2:05 PM, Youssef Ghorbal <youssef.ghor...@gmail.com> wrote:
> Good question indeed. I'd say that I want both for my internal pool (S2 > servers) > (as accurate as possible and also accurate with respect to each other.) > Regarding actual clients, I'd say that I want them to be only accurate with > respect to each other. Tough order there (everything) :) > Ah OK, i've looked into it from another point of view. In fact, I was trying > to > be conservative of S1 I'm querying, only one host will query and distribute > the > information to its friends and thus avoiding to have 4 hosts on my network > querying the same S1 (kinda being the good citizen) It sounds like a good idea when you state it like this, but NTP is naturally fairly conservative bandwith-wise once it stabilizes. I doubt many public S1 providers would have a problem with you configuring all 4 hosts. > As a matter of fact all my S2 are in the same location. > So you are saying If I want to keep the infra in sync with itself I should do > a > full mesh of my S2 (each one is poiting to the three others and an S1 as a > backup) ? > And if I want tight ref sync I can share some common S1(s) on all my S2 but > keep > a diffrent S1 for evry S2 (diversity) and in that case no need for my S2 to be > aware of each other ? So, having 4 hosts in the same location is purely so you can have quorum function properly in your end clients' ntpd setup? If you want the best chance of the best time for the most hosts, you should let ntpd do what it's best at: monitoring a variety of valid sources and choosing among the best of them for the best time. Since all your S2 servers are in one location, they will likely chose among a common S1 population identically, making them very consistent, but without much diversity. You want at least a LITTLE diversity if you're using public sources. Free-like-beer is great until someone has a really bad malfunction on their time source (see the mailing list from earlier today). If only one of your stratum2 servers is locked on that bad talker, then your overall infrastructure will be unaffected as ntpd will identify that time as out of spec and use one of your other hosts. You can try to get super clever and tweak things, but I'd start out simple and see how well ntpd does on its own (usually quite well). I'd start with something like this: Sources: S1-0 = internal GNSS-based source (future?) S1-1 = public stratum1 that you know is probably good most of the time, e.g. one of the "navobs" hosts if in the US or a European (or local to you) equivalent (check with providers' published usage rules). S1-2 = public stratum1 S1-3 = public stratum1 S1-4 = public stratum1 S1-5 = public stratum1 S1-6 = public stratum1 Your servers: - S2-1: - S1-0 - S1-1 - S1-2 - S1-3 - S2-2: - S1-0 - S1-1 - S1-4 - S1-5 - S2-3: - S1-0 - S1-1 - S1-2 - S1-4 - S2-4: - S1-0 - S1-1 - S1-3 - S1-5 That will reduce the likelihood that any single upstream having a problem will trickle-down to your end clients. Once you get your GNSS source up and running, the 4 S2 hosts will likely use it whenever it's available unless it's reporting a time that is WAY off. Again, this is just one way it can be done. You may very well get 99.9 percent of the same performance by any number of variations with reputable upstream S1s. Just try it out and keep an eye on the quality of time you're getting and adjust as necessary. Oh and yes, "node" == "service node" == "host providing whatever service you're talking about". It's terminology common in my technology space. -- Dan _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
