Since the Raspi2 runs out of a uSD card, minimizing writes seems like a good thing for long term reliability. The version of Raspi OS that I am using, offers "RAM Overlay Root File System" as an option on the raspi-config program. Reading on this indicates that the uSD card is marked read only and a RAM file system accepts the write data, making it non-persistant over resets or power cycles.

Since the Raspi2B does not have a battery backed real time clock to fetch clock time from at start up, it appears to take the real time from somewhere in the file system, approximating the time that the system shut down. This gets into trouble with the RAM Overlay File System, because the time and date that it fetches looks to be the time and date that the system was changed over to run the RAM Overlay File System instead of the last shutdown time.

Yesterday, we had a power line drop out for a few seconds. It was long enough to cause the Raspi2B in the time server to re-boot. After the re-boot, the ntpd daemon refused to stay connected to the GPS and PPS time sources.

When ntpd starts up, it looks at the system time and if it differs too much from the GPS time, it stops listening to the GPS. There is a command line option ( -g) that looks like it should force the system time to match the GPS time, even if the difference is large. The man page on ntpd indicates that this large jump can only occur once. It seems like this should solve the issue of the startup time, but it appears not to be working. Maybe the GPS system had not recovered a 3D fix before the ntpd daemon tried to do the one-time jump, don't know yet. If the ntpd daemon runs for 7 or 8 hours without access to the GPS or PPS time sources (peers), it shuts down. When I noticed the issue with the real time being hours out of sync and ntpd not listening to the GPS, ntpd was still running. I manually set the system time with the date command, and ntpd immediately hooked up with the PPS source again and has been running fine since.

It's possible that a battery backed real time clock is the answer. It seems like there should be a simpler answer.

2/12/2023  I think I dodged a bullet on this one. I have some little clock boards with a PCF2127 clock chip, and a battery (as well as an un-needed EEPROM chip) that I designed a few years ago for another project. It turns out that Raspi OS already has drivers for that clock chip included in the distribution. I set it up on my test platform and it works just fine. It also insures that the system clock is very close to GPS time at startup because those PCF2127 clock chips are quite accurate.

I considered writing a piece of code that will read time out of the GPS data stream and just force the system clock to that value at startup. There are a couple of problems beyond gracelessness with this approach. The amount of time that a GPS unit takes to get a fix can be pretty variable, depending on the environment. It can be up to a minute or so in extremely low signal environments and I don't want to whack the time setting that late in the boot process. Also, the effect on ntpd of doing that are unknown, by me anyway. This box already has a bunch of boards in it, one more will hardly be noticable.

2/14/2023 The ntp server program ntpd is a large, complex piece of code. I looked through the documentation to see if there was more information on the behavior of the -g option to see if there was an obvious reason that it was not setting the time at startup and could not find one. Resorting to the source code, I followed the track of the -g (force_time_step) option in from the command line parser. It was not obvious why the time step was not doing what I expected.

There is a place to mount the new clock board in a place where it is easy to access the battery for later changes.