When a Raspberry Pi -- which doesn't have a hardware clock -- boots, the time can be set thanks to NTP. It usually works well enough to be totally transparent.
Trouble usually starts if there is a power cut. By the time the Raspberry is up and running, the modem-router is usually still booting/synchronising with the ISP and no clock is set. Programmes start using the Epoch, i.e. 1st of January 1970!
The best hardware workaround is certainly to use an external clock like "real" computers. Maxim's DS1307 has been a reference for years but is both 5V and not reputed for its accuracy.
Raspberry Pi's I²C being in 3.3V, I tried to use a cheap RTC Clock using a DS3231 also from Maxim.
There are loads of webpages explaining how to setup Linux to use this hardware clock and if at first everything worked fine, I then started to notice some problems.
Symptoms
With Raspbian, the main problem was that after a while, I couldn't SSH to the server anymore. The Raspberry being headless, it wasn't easy to guess what was going on but it turned out this behaviour was the result of the disappearance of the root directory.
And this was itself caused by an I/O error on the SD Card. It seems that the 2 main reasons for this to happen are:
- Problem with the power supply
- Faulty (or incompatible) SD Card
The power supply was bought from RS with the first Raspberry and is rated 1.5A. Swapping with the second one (from Farnell this time) rated 2A didn't change anything. I then decided to use the other SD Card with a brand new Arch Linux on it.
At first, no failure but then 2 problems also showed up:
- Loads of log lines related to mmcblk or
- An extremely slow Raspberry Pi with an non-explicable high load (~ 6)
Solution?
I was a bit lost but I found a forum message which gave me a very important clue:
Second: disconnected the Dallas RTC DS3231, as it was pulling the 3.3v line too low, along with the DHT22 sensor.
Another test
Since I use a Level Shifter (3.3V/5V) on the I²C bus, it was very easy to move the DS3231 IC to the 5V side and try this theory. Unfortunately, this didn't make any difference.
Reason?
My best guess would be that the DS3231 or the AT24C02 EEPROM on the same module trigger the (in)famous Raspberry Pi I²C Hardware bug.
Since I removed the module, the Raspberry Pi is no longer slow and load is now ~0.05.
Software workaround
With Arch Linux, I now force the application to start only when the network setup has completed (this includes proper NTP initialisation) by adding in the [Unit] section the following lines:
After=network-online.target
Wants=network-online.target