| ▲ | amelius 2 days ago |
| 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. | | | |
| ▲ | 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... | | |
|
