Step One of most disaster plans is not to create a second emergency.

Or even just a microsecond emergency.

	▲	f5129cac 2 days ago \| parent [-]
		Bravo

▲

amelius 2 days ago | parent | prev [-]

But can't NTP server downtime cause a disaster?

▲

Vosporos 2 days ago | parent | next [-]

One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time.

▲

macintux 2 days ago | parent | next [-]

General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server.

	▲	xeonmc 2 days ago \| parent [-]
		i.e. a gaslighting husband is vastly worse than a dead husband.

▲

PunchyHamster 2 days ago | parent | prev [-]

technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality

▲

throw0101c 2 days ago | parent | next [-]

> technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality

Either go with one clock in your NTPd/Chrony configuration, or ≥4.

Yes, if you have 3 they can triangulate, but if one goes offline now you have 2 with no tie-breaker. If you have (at least) 4 servers, then one can go away and triangulation / sanity-checking can still occur with the 3 remaining.

	▲	ufocia 2 days ago \| parent [-]
		Your probably meant trilaterate.

▲

da_chicken 2 days ago | parent | prev [-]

Sure, but not needing a failure to cascade to yet another failsafe is still a good idea. After all, all software has bugs, and all networks have configuration errors.

▲

idiotsecant 2 days ago | parent | prev [-]

If your application is so critical that NTP timing loss causes disaster and your holdover fails in less than a day and you aren't generating your own via gps, you are incompetent, full stop

▲

geerlingguy 2 days ago | parent [-]

And if things are that critical, you might have other references besides just GPS...

	▲	throw0101c 2 days ago \| parent [-]
		E.g., * https://www.meinbergglobal.com/english/products/