← Back to context Comment by TylerE 5 days ago Step One of most disaster plans is not to create a second emergency. 13 comments TylerE Reply ronjakoi 4 days ago Or even just a microsecond emergency. f5129cac 4 days ago Bravo amelius 5 days ago But can't NTP server downtime cause a disaster? Vosporos 5 days ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 5 days ago General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server. 1 reply → PunchyHamster 4 days ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies → idiotsecant 4 days ago 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 4 days ago And if things are that critical, you might have other references besides just GPS... 1 reply →
amelius 5 days ago But can't NTP server downtime cause a disaster? Vosporos 5 days ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 5 days ago General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server. 1 reply → PunchyHamster 4 days ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies → idiotsecant 4 days ago 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 4 days ago And if things are that critical, you might have other references besides just GPS... 1 reply →
Vosporos 5 days ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 5 days ago General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server. 1 reply → PunchyHamster 4 days ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies →
macintux 5 days ago General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server. 1 reply →
PunchyHamster 4 days ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies →
idiotsecant 4 days ago 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 4 days ago And if things are that critical, you might have other references besides just GPS... 1 reply →
geerlingguy 4 days ago And if things are that critical, you might have other references besides just GPS... 1 reply →
Or even just a microsecond emergency.
Bravo
But can't NTP server downtime cause a disaster?
One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time.
General rule of thumb: a misbehaving/slow server in any well-architected distributed system is vastly worse than a dead server.
1 reply →
technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality
3 replies →
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
And if things are that critical, you might have other references besides just GPS...
1 reply →