Date: Sat, 27 Mar 2010 01:38:36 +0100 From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> To: Peter Jeremy <peterjeremy@acm.org> Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon <avg@icyb.net.ua> Subject: Re: periodically save current time to time-of-day hardware Message-ID: <86pr2qlhtf.fsf@ds4.des.no> In-Reply-To: <20100326213022.GD32799@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sat, 27 Mar 2010 08:30:23 %2B1100") References: <4BACC791.70502@icyb.net.ua> <86zl1v84vy.fsf@ds4.des.no> <4BACD88E.2040803@icyb.net.ua> <86vdcj82qx.fsf@ds4.des.no> <20100326213022.GD32799@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@acm.org> writes: > It's not especially important how regularly the RTC is updated, just > that it _is_ updated. This suggests that an alternative approach > would be for adjtime() / ntp_adjtime() to directly call resettodr() if > it's more than P minutes since resettodr() was last called. It just occurred to me that resettodr() is very slow (it usually involves writing to NVRAM over an I2C bus), so it might not be a good idea to call it from adjtime(). > As a general comment, whilst resettodr() needs to be serialised, there > is no need for it to block. If thread B wants to call resettodr() > whilst thread A is doing so, thread B can just skip the call because > calling resettodr() twice in quick succession has no benefit. It does if thread B set the system clock before calling resettodr() (think ntpd -gq). Actually, it might be a good idea to call resettodr() any time the clock is stepped. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86pr2qlhtf.fsf>