[ntp:questions] Advice on a private stratum 2 pool
youssef.ghorbal at gmail.com
Tue Jul 2 18:05:54 UTC 2019
Thank you very much for taking the time to write this overview.
On Tue, Jul 2, 2019 at 3:17 PM Dan Geist <dan at polter.net> wrote:
> Hi, Youssef. First, it all depends a lot on how you want your timing
architecture to behave. Do you want the vast majority of your clients to be
accurate with respect to EACH OTHER or do you want each and every
individual client to be as accurate as possible (i.e. if a small number of
client devices skew a little vs. the reference source, does that matter as
long as they still match each other?)
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
Regarding actual clients, I'd say that I want them to be only accurate with
respect to each other.
> The peer directive works like the server, but in both directions, so it's
helpful for situations where you have a free-run with multiple devices, but
not really otherwise.
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 avoinding to have 4
hosts on my network querying the same S1 (kinda being the good citizen)
> The DNS round-robin is a good way to go on the end clients. Be careful if
you add more service nodes and also if you use IPv6. The limitations of the
DNS response message size may limit the number of devices in the pool.
That's what I was intending for my end clients. Thank you for the hint
regarding DNS response size.
> There is nothing wrong with configuring the same offsite S1 clocks as
your reference, but know that if your stratum2 devices are in different
geographies, they'll likely lock onto different S1s anyway. You could also
have a few S1 sources that are in all your configs, then select an
additional one that is different between all of them. That gives you a bit
better diversity. if your goal is to have all your infrastructure exactly
in sync with itself, then 3rd party S1 sources probably aren't the right
way to go (except for backup)
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 ?
> If you can afford it, consider adding at least one on-network GNSS or
terrestrial radio source for reference time. You can protect/abstract it by
having only your S2 devices point to it. It's good to have piece of mind if
there are issues traversing partner networks or upstream providers.
That's on my TODO list, for now I'm evaluating cabling constraints going
from the datacenter (in the basement) to the building roof.
> Finally, capture metrics! They are invaluable, and things like traffic
counts, and especially the ones from ntpd such as jitter, offset from
referenced source, etc. lets you know if your infrastructure is performing
as you expect. For linux-based servers, the combination of the "telegraf"
agent on each node and "influxdb" and "grafana" for data storage and
graphing/alerting is what I've used with good success.
That’s on the roadmap indeed. When you are talking about nodes, are you
referring to ntpd running on clients or only my 4 S2 pool ?
> ----- On Jul 1, 2019, at 6:12 AM, Youssef Ghorbal
youssef.ghorbal at gmail.com wrote:
> > Hello,
> > I'm seeking advice on what would be the best configuration to build a
> > private/internal stratum 2 pool. The idea is to provide internal
> > hosts/servers (~5000) with an NTP pool to sync to.
> > I'm not seeking very high precision/accuracy, I'm just hoping to
> > provide reliable and uniform time reference.
> > I've settled on running 4 ntpd on 4 different servers (the "4" comes
> > from NTP FAQ regarding the minimum number of hosts) I've also selected
> > 4 stratum 1 available and public servers in my area.
> > I'm currently reviewing NTP FAQ regarding what would be the best
> > architecture but I've no clue :
> > - Option 1 : each one of the ntpd is configured to sync to one and
> > only one upstream stratum 1 server. In this option my stratum 2 hosts
> > are not aware of each other. On the client side I configure a pool
> > pointing to a DNS Round Robin enslaving my 4 NTP servers.
> > => This works OK but it does not seem to be the one described in this
> > NTP architecture http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm where
> > stratum n-1 are peered together
> > - Option 2 : Starting from Option 1, I add on each stratum 2 server a
> > peer directive pointing to the 3 others. After some time, an NTP
> > hierarchy is created stratum 3 and sometimes 4 gets created. For
> > exemple ntp03 becomes a stratum 3 poiting to ntp01 which is pointing
> > to an upstream stratum 1. ntp03 totally ignores it's configured
> > stratum 1 (for many valid reasons I guess)
> > => On the client side too, the one ntp the peer "elected" as the best
> > is also the one chosed by the client. This Option seems to be more
> > aligned with previsously referenced architecture but I can't tell why
> > I don't like it (maybe that I'm expecting that my pool would be
> > stratum uniform)
> > Do you think that I should be using the same 4 upstream NTP stratum 1
> > servers on all my stratum 2 servers? My failure scenario is if one of
> > those upstream is faulty, my pool detect it and everything continues
> > to work (and if my Internet connection is dead, I have more bigger
> > problems than NTP going out of sync)
> > How would you do it ? Do you have any pointers to reference NTP
> > Thank you for your help
> > Youssef Ghorbal
> > _______________________________________________
> > questions mailing list
> > questions at lists.ntp.org
> > http://lists.ntp.org/listinfo/questions
> Dan Geist dan(@)polter.net
More information about the questions