[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/56322: Excessive clock drift
The following reply was made to PR kern/56322; it has been noted by GNATS.
From: Frank Kardel <kardel%kardel.name@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
Subject: Re: kern/56322: Excessive clock drift
Date: Thu, 22 Jul 2021 07:47:33 +0200
Can you post
I assume the with the
ERROR: 2607 cycle TSC drift observed
TSC was not picked as timecounter on your system.
Can you try
sysctl -w kern.timecounter.hardware=i8254
and see whether that improves the situation.
I agree that ntpd is unlikely to curb that large drift.
ntpd will on correct a drift up to 43 seconds per day (500ppm).
On 07/22/21 02:15, dholland%NetBSD.org@localhost wrote:
>> Number: 56322
>> Category: kern
>> Synopsis: Excessive clock drift
>> Confidential: no
>> Severity: serious
>> Priority: medium
>> Responsible: kern-bug-people
>> State: open
>> Class: sw-bug
>> Submitter-Id: net
>> Arrival-Date: Thu Jul 22 00:15:00 +0000 2021
>> Originator: David A. Holland
>> Release: NetBSD 9.99.85 (20210623)
> System: NetBSD valkyrie 9.99.85 NetBSD 9.99.85 (VALKYRIE) #7: Wed Jun 23 18:32:25 EDT 2021 dholland@valkyrie:/usr/src/sys/arch/amd64/compile/VALKYRIE amd64
> Architecture: x86_64
> Machine: amd64
> Four days ago (and a couple hours) I noticed the clock was badly
> behind, and synced it with ntpdate.
> It is now on the order of 1:30 (that's one and a half minutes) behind,
> by comparison to another machine that runs ntpd. This machine does
> not, for no particular reason.
> This is a regression - prior to updating to 9.99.85 the clock lagged
> but nowhere near so much.
> This is the relevant material I see in dmesg, which isn't much use.
> [ 1.000000] timecounter: Timecounters tick every 10.000 msec
> [ 1.000000] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
> [ 1.000003] timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
> [ 1.051023] timecounter: Timecounter "TSC" frequency 3517182870 Hz quality 3000
> Before this update I used to get messages of the form
> autoconfiguration error: ERROR: 2607 cycle TSC drift observed
> These have gone away, but I suspect the underlying problem is that the
> TSC is bad and this is no longer being detected.
> Machine is a 6-way AMD Family 15h.
> I don't want to be fixing the time regularly because I'm sure it will
> regularly remind me of PR 56097. I could turn on ntpd, but that's at
> best a bandaid, and with this much drift it might just lose sync
Main Index |
Thread Index |