Date: Tue, 26 Nov 2019 15:28:13 -0700 From: Ian Lepore <ian@freebsd.org> To: James Shuriff <james@opentech.cc>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: rpi3 clock drift Message-ID: <c5942861c2aa0929239e59a000ce76407f4fd191.camel@freebsd.org> In-Reply-To: <MWHPR06MB3134CD05551D36CC3B45D368AA450@MWHPR06MB3134.namprd06.prod.outlook.com> References: <MWHPR06MB3134CD05551D36CC3B45D368AA450@MWHPR06MB3134.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c5942861c2aa0929239e59a000ce76407f4fd191.camel>