1

I'm working on a project where an RTC (DS3231) is needed since the RPi will not have continuous access to the internet. I've been able to set the clock on time and keep it but I've observed that a delay in time appears when I reboot the system. Around 1 second each 5 reboots.

I've tried to set the clock both with the rc.local method and the overlays method (I'm running Jessie), and none of them solve this delay on reboot issue.

Any idea about why this could happen? It is not a problem with my clock as I've checked two differents DS-3231.

EDIT. What I've tried until now:

  1. First Method

    -Including rtc-ds1307 in /etc/modules (It doesn't with "rtc-ds3231", so I use ds1307 driver instead)

    -Including in /etc/rc.local:

    echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
    hwclock -s
    
  2. Second Method (recommended for Jessie)

    -Including dtoverlay=i2c-rtc,ds3231 at the end of /boot/config.txt

    -Commenting out the following lines in /lib/udev/hwclock-set:

    #if [ -e /run/systemd/system ] ; then
    #    exit 0
    #fi
    

How I set up and read time

sudo date -s "01 AUG 2017 1:00:00"
sudo hwclock -w
sudo hwclock -r; sudo date
  • Are we supposed to guess how you set your RTC up? Who knows what "the rc.local method" is, or why you wouldn't use the kernel module. – Milliways Jul 31 '17 at 8:32
  • Maybe you save your time into RTC after reading? – Mark Jul 31 '17 at 9:03
  • 1
    Edited. @Mark, Yes, it is normal to have some drift between system time and hwclock time, so the most logical option is that something is saving the system time to the rtc, but I can't see why or how. In fact, if I change the Linux clock, it doesn't overwrite the rtc when I read it or reboot the system. – user71095 Aug 1 '17 at 10:44
-1

One reason may be that many of the various RTC chips, such as the DS3231, store time only with second prevision, when read from or written to. Thus, I would expect a normal variation of +/- 0.5s depending on when Linux read the hardware clock on each boot. Also, when setting the hardware clock initially, only seconds are stored, so you may end up with +/-1s overall. However, you should see only a random fluctuation in this range, but not accumulated deviation. Except, in case you constantly update the hardware clock from the Linux clock: this would quickly accumulate these errors. As you didn't give details in your question this is only speculation at this time.

  • I edited the main post. That's what I thought but if I change the Linux time and date, the rtc is not overwritten when I reboot the system. – user71095 Aug 1 '17 at 10:33
  • You need to manually set the HW clock, using sudo hwclock -w. – TheDiveO Aug 1 '17 at 11:49
  • 1
    What I mean is that if I don't use sudo hwclock -w the rtc is not writen (everything ok), so I don't know why this error accumulates then. – user71095 Aug 1 '17 at 12:07
-1

Even accurate RTCs have some drift. The DS3231 claims ±2ppm from 0°C to +40°C. A million seconds is about 11½ days, so the clock could be a second off in about a week.

If you need better accuracy than that, you'll need an external precision clock source like a GPS (needs satellite sync, not always possible indoors) or rubidium clock (expensive, power hungry, fiddly).

Do you need to be rebooting so often?

  • 1
    The normal drift produced by the passing of time is admissible to me, as you said, a second off per week doesn't bother me too much. The problem is the accumulated drift produced in reboots, that besides I can't mesure or predict. I would need to reboot once a day approx, but it's pretty irregular. – user71095 Aug 1 '17 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.