rpi3 clock drift

[James Shuriff]

Bakul,

I have previously set the date manually and with ntpdate and I turned on ntp_sync_on_start so I don't think the issue is the initial date.

Ian,

The drift file is at 0.000. Here is timecounter:

kern.timecounter.fast_gettime: 1
kern.timecounter.tick: 1
kern.timecounter.choice: ARM MPCore Timecounter(1000) dummy(-1000000)
kern.timecounter.hardware: ARM MPCore Timecounter
kern.timecounter.alloweddeviation: 5
kern.timecounter.timehands_count: 2
kern.timecounter.stepwarnings: 0
kern.timecounter.tc.ARM MPCore Timecounter.quality: 1000
kern.timecounter.tc.ARM MPCore Timecounter.frequency: 54000000
kern.timecounter.tc.ARM MPCore Timecounter.counter: 3604619156
kern.timecounter.tc.ARM MPCore Timecounter.mask: 4294967295

As of this moment the clock has fallen behind 40 minutes.

- James Shuriff

-----Original Message-----
From: Ian Lepore <ian at freebsd.org>
Sent: Tuesday, November 26, 2019 5:28 PM
To: James Shuriff <james at opentech.cc>; freebsd-arm at freebsd.org
Subject: Re: rpi3 clock drift

On Tue, 2019-11-26 at 22:03 +0000, James Shuriff wrote:
> My Raspberry Pi 3 Model B is having some serious clock drift issues.
> Ntpd doesn't function even with ntpd_sync_on_start, which calls ntpd
> with -g and allows the initial adjustment to exceed the panic
> threshold. This doesn't help me much because the system will continue
> to drift very quickly and that option only helps for the initial
> adjustment.
>
> I was thinking of ordering an I2C RTC but I'm unsure how to make
> FreeBSD aware of the clock.
>
> There is a file in the Raspberry Pi firmware repo called i2c-rtc.dtbo
> and it contains defs for clocks like DS1307 so I am assuming I can add
> this to config.txt, build U-Boot with CONFIG_RTC_DS1307 (or whatever
> model), and build the kernel with device support for the clock but I'm
> not completely sure if I'm going about this the right way. Beyond just
> getting FreeBSD to see the clock I'm unsure how to tell FreeBSD to use
> it. Any advice?
>
> Thanks,
>
> - James Shuriff
>

You're on the right basic track for the RTC... you need to enable the overlay for the model you choose in config.txt, and add the right driver to your /boot/loader.conf (such as nxprtc_load=YES).  The ds1307 is about the most generic you can get.  I prefer the ones that can do sub-second precision; most of the NXP chips can do so (PCF85x3 or PCx2129).  This is a nice rpi-ready one:

   https://www.sunfounder.com/pcf8563-real-time-clock.html

But adding an rtc isn't going to fix the ntpd clock drift at all.
There are 3 things I can think of that might cause that:

 - actual hardware trouble (some clock running too fast/slow).
 - bad data somewhere (clock isn't running at speed we think it is).
 - somehow a bad value got into /var/db/ntp/ntpd.drift

It would be interesting to know what's in the ntpd.drift file now.
If it's the problem, it's easy to fix, you can just rename the file to ntpd.drift.bad and restart ntpd so it'll regenerate the file.

It would also be interesting to see the output of

  sysctl kern.timecounter

from that system.

-- Ian

________________________________
 DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).