Stealth NTP failure

We have two Shakes within a kilometer of each other in Montreal. When I checked on today’s large Alaska and Haiti earthquakes, the two showed different timings. So I checked back to an earlier Alaska EQ:

Looking at one of the Shakes webpages showed that the clock was off by 27 minutes, but the Shake was happily forwarding data to the server, with no errors shown (compare the UTC reported versus the MacOS time in the upper right corner, UTC-4):

Since we’re in a city, and away from active tectonics, there are just a few events back in time I could easily cross-correlate:
Shake_TimingDifferences
Timings were off by 20-27 minutes since mid-June; we had a large power outage on June 10th, and the logs (below) show that the NTP daemon didn’t start. ‘ntpq’ would not run -it seems to have been corrupted somehow. ntp.conf was not changed from the v.18 distribution.
I reformatted the SD card, and wrote and read from each block without error; the card seems fine. So I reloaded v.18 of the softare and restarted the Shake. I’ve turned on NTP logging to see if anything strange turns up.
So, two questions remain:

  1. why did the Shake happily continue to forward data for two months with a bad clock and a failed NTP daemon?
  2. how can I inform the data repositories that the timings are wrong for R9499 from Jun 10 through August 14?

Cheers,
Bill
RSH.R9499.2021-08-14T14 22 24.logs.tar (2.2 MB)

Hello Bill,

Stealth indeed! Thank you very much for this notification! It appears to be strange that such an unsynchronized Shake would continue to transmit data without issues to our servers, because there are very strict protocols in place to guarantee that the NTP services will do their part.

I will pass all the information you have kindly provided to our software team, so that they will be able to cross-reference it and identify (hopefully it will be clear from the start) what needs to be corrected.

I will update you on the situation as soon as I have new information.

Thank you again!