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.
This is pretty widely fixed now, but often overzealously. Clock changed unexpectedly? User is a dirty pirate and the license should deactivate.
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.