Timezone problems on -current

[Paul Mather]

On May 4, 2021, at 12:20 AM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Tue, May 04, 2021 at 04:38:56AM +0100, tech-lists wrote:
>> On Mon, May 03, 2021 at 06:52:22PM -0700, bob prohaska wrote:
>> 
>>> Up to now I've used only the line
>>> ntpdate_enable="YES"
>> 
>> Seems ntpdate isn't required if these are set in /etc/rc.conf
>> 
>> ntpd_enable="YES"
>> ntpd_sync_on_start="YES"
>> 
>> even on boards with no RTC.
> 
> Indeed it looks as if ntpdate is going away, replaced by
> enhancements to ntpd. 
> 
> Still, I think the timekeeping errors are caused by a somewhat
> unconventional network setup on the machine having problems.
> The rest of the hosts in my "data center" use ntpdate and 
> have no trouble keeping their clocks right, but those hosts
> all have wired ethernet. The host with the wrong clock setting
> uses an ethernet-to-wifi adapter. Can't be sure until more 
> testing is done. And, I might be wrong again.....


The problem with ntpdate is that it is a one-time clock adjustment whereas ntpd is a continuous time monitoring/adjustment.  So, if your system has problems with clock drift or just keeping accurate time, ntpdate run on boot will not help in the long term.  Ntpd, on the other hand, will.

Note also that 'ntpd_sync_on_start="YES"' is effectively the same as running ntpddate.  The 'ntpd_sync_on_start="YES"' setting lets ntpd perform a one-time large step time adjustment (via the "-g" option), which is essentially what you are achieving when running ntpdate.  Normally, ntpd will baulk if the clock is off by 1000s, which can easily happen with systems that have no RTC, hence the need for the 'ntpd_sync_on_start="YES"' flag.

When I ran FreeBSD/arm, I used the net/ntimed port to maintain time, which is a simple, low-resource alternative to ntpd for keeping time on FreeBSD/arm clients.

Cheers,

Paul.