Comment by TylerE 2 months ago Step One of most disaster plans is not to create a second emergency. 13 comments TylerE Reply ronjakoi 2 months ago Or even just a microsecond emergency. f5129cac 2 months ago Bravo amelius 2 months ago But can't NTP server downtime cause a disaster? Vosporos 2 months ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 2 months 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 2 months ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies → idiotsecant 2 months 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 2 months ago And if things are that critical, you might have other references besides just GPS... 1 reply →
amelius 2 months ago But can't NTP server downtime cause a disaster? Vosporos 2 months ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 2 months 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 2 months ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies → idiotsecant 2 months 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 2 months ago And if things are that critical, you might have other references besides just GPS... 1 reply →
Vosporos 2 months ago One (amongst many) NTP server going down creates less issues than an NTP server spreading wrong time. macintux 2 months 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 2 months ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies →
macintux 2 months 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 2 months ago technically if you have 3 or more sources that would be caught; NTP protocol was designed for that eventuality 3 replies →
idiotsecant 2 months 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 2 months ago And if things are that critical, you might have other references besides just GPS... 1 reply →
geerlingguy 2 months 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 →