From owner-freebsd-hackers@freebsd.org Sat Oct 6 19:46:01 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 8BB4010C4910 for ; Sat, 6 Oct 2018 19:46:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 123E08117D for ; Sat, 6 Oct 2018 19:46:00 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 6e6c220d-c9a0-11e8-aed8-99744f00ac98 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 6e6c220d-c9a0-11e8-aed8-99744f00ac98; Sat, 06 Oct 2018 19:45:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w96JjptT006341; Sat, 6 Oct 2018 13:45:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1538855151.14264.54.camel@freebsd.org> Subject: Re: ntpd strange problem From: Ian Lepore To: Wojciech Puchar Cc: freebsd-hackers@freebsd.org Date: Sat, 06 Oct 2018 13:45:51 -0600 In-Reply-To: References: <20181005061829.GG21091@server.rulingia.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 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: Sat, 06 Oct 2018 19:46:01 -0000 On Sat, 2018-10-06 at 20:43 +0200, Wojciech Puchar wrote: > > > > > > > > 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  > bare metal. > > > > > > > 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. > > > # cat /var/db/ntpd.drift > 35.586 > > what else can i do? The original output you posted showed the time as unsynchronized when ntpd started up. That seems normal to me, it can't be synchronized until ntpd has been running for a while. In a followup message you seemed to say that it doesn't stay synchronized, but you haven't provided much info about that. What's in the logs when it become unsynchronized or when you notice the time is several seconds off? What does the output of ntptime show when the time is drifted off? How about the output of "ntpq -p" and "ntpq -c rv"? What's in your ntp.conf? If you set sysctl kern.timecounter.stepwarnings=1, do you see any warnings about the clock stepping as time drifts out of sync? -- Ian