4 ms·

This is a terrible idea when dealing with an application other than "users checking the time on their system clock". Performing hard resets of the clock contin

This is a terrible idea when dealing with an application other than "users checking the time on their system clock". Performing hard resets of the clock continually is a catastrophic infrastructure failure. A high performance 24/7 application that relies on sub millisecond let alone sub microsecond accuracy across multiple physical systems will be utterly destroyed by this approach.

pjc50 12y ago
If the clock is drifting substantially then your high-precision application will already be in serious trouble.
- easytiger 12y ago
  If your clock solution, GPS + Sync, is drifting then your infrastructure is broken and your platform is not fit for service.
jacquesm 12y ago
Not just that, monotonicity could be impaired.
- wlesieutre 12y ago
  To elaborate, monotonicity means that a value is either always increasing or always decreasing, and never changes direction. If a program is built on the assumption that time always goes forward, it may not like you setting the clock back 0.000000001sec every hour.
  - shadowfox 12y ago
    Many license management software are especially bothered by time changes of this sort.
    - wlesieutre 12y ago
      Very true, a lot of software with time limited trials or features like "check out a network license for 30 days of offline use" used to be easy to bypass by turning your clock back so that it never expired. This is pretty widely fixed now, but often overzealously. Clock changed unexpectedly? User is a dirty pirate and the license should deactivate.
lamontcg 12y ago
Reading comprehension... I had 30,000 servers, all but 6 of them were not getting hard resets. 6 of them were getting hard resets every hour because they were sick. Occasionally a ntpd on a server would go a little crazy and it would get a few hard resets. This script got it back into spec so that it didn't need hard resets. I mentioned specifically that you can't send hard resets to ntpd more than about once an hour or it won't have time to settle and you'll wind up in a situation where you are constantly sending hard resets to it (which is bad). I took out the nightly forced hard resets of ntpd specifically because it affected monotonic time. If you look at the algorithm I wound up with ntpd will only be reset if: a. it is already crashed and not running b. it is self-reporting that it is out of synch c. is is more than 50ms out of synch with an upstream time server In all of those cases, you have already lost the battle to get sub-microsecond accuracy.

pjc50 12y ago

If the clock is drifting substantially then your high-precision application will already be in serious trouble.

easytiger 12y ago
If your clock solution, GPS + Sync, is drifting then your infrastructure is broken and your platform is not fit for service.

jacquesm 12y ago

Not just that, monotonicity could be impaired.

wlesieutre 12y ago
To elaborate, monotonicity means that a value is either always increasing or always decreasing, and never changes direction. If a program is built on the assumption that time always goes forward, it may not like you setting the clock back 0.000000001sec every hour.
- shadowfox 12y ago
  Many license management software are especially bothered by time changes of this sort.
  - wlesieutre 12y ago
    Very true, a lot of software with time limited trials or features like "check out a network license for 30 days of offline use" used to be easy to bypass by turning your clock back so that it never expired. This is pretty widely fixed now, but often overzealously. Clock changed unexpectedly? User is a dirty pirate and the license should deactivate.

lamontcg 12y ago

Reading comprehension... I had 30,000 servers, all but 6 of them were not getting hard resets. 6 of them were getting hard resets every hour because they were sick. Occasionally a ntpd on a server would go a little crazy and it would get a few hard resets. This script got it back into spec so that it didn't need hard resets. I mentioned specifically that you can't send hard resets to ntpd more than about once an hour or it won't have time to settle and you'll wind up in a situation where you are constantly sending hard resets to it (which is bad). I took out the nightly forced hard resets of ntpd specifically because it affected monotonic time. If you look at the algorithm I wound up with ntpd will only be reset if: a. it is already crashed and not running b. it is self-reporting that it is out of synch c. is is more than 50ms out of synch with an upstream time server In all of those cases, you have already lost the battle to get sub-microsecond accuracy.