Dan, you're awsome !

>> 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.

Understood.

>> 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?

Exactly that. Trying to follow the best practices in NTP FAQ basically.
Is it overkill ?

> 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.

Very clear ! Exactly what I had in mind.

> 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

Reply via email to