From owner-freebsd-hackers@freebsd.org Fri Oct 5 12:08:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 405FE10A9B57 for ; Fri, 5 Oct 2018 12:08:28 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [IPv6:2001:8b0:151:1:c4ea:bd49:619b:6cb3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CD1947DB54 for ; Fri, 5 Oct 2018 12:08:27 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from leaf.local (unknown [88.202.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 1947991A8 for ; Fri, 5 Oct 2018 12:08:19 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/1947991A8; dkim=none; dkim-atps=neutral Subject: Re: ntpd strange problem To: freebsd-hackers@freebsd.org References: <20181005061829.GG21091@server.rulingia.com> From: Matthew Seaman Message-ID: Date: Fri, 5 Oct 2018 13:08:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 12:08:28 -0000 On 05/10/2018 10:24, Wojciech Puchar wrote: >>> 0x2041: Clock Unsynchronized >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> It will take 5-10 minutes for ntpd to synchronise to its upstream >> servers. >> Until then, the clock will report that it's unsynchronised.  If "ntptime" >> is still reporting that it's unsynchronised after a long period, you will >> need to do more troubleshooting. > > yes the problem is that: > > after starting ntpd time is exactly fine > > ntpd_sync_on_start=YES > ntpd_enable=YES > > > but then while ntpd works, time seems to get out of sync to the extent > of normal RTC imprecission - in order of few seconds per day. > > ntpd seems like not to update time properly. > > restarting ntpd fixes time again. > > what should i look at to find a source of problem Is this a virtual machine or bare metal? VMs tend to have a lot more problems with clock drift -- they lose time when the hypervisor switches them off the CPU. Then if the clock gets more than a certain amount out of sync, ntpd just gives up. You can add: tinker panic 0 to ntpd.conf to make that less likely to happen. If it's bare metal then it sounds like your system clock is running much faster or slower than ntpd can manage to correct. That's a hardware problem, but there are some tunings that may allow ntpd to cope. If you enable a drift file (which I think is enabled by default): driftfile /var/db/ntpd.drift then ntpd will record how fast or slow the clock tends to run so it can immediately account for that across restarts, rather than having to work it out de-novo everytime ntpd gets restarted. Cheers, Matthew