From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EBA2E2727F3 for ; Thu, 21 May 2026 18:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779388214; cv=none; b=nA2qGRWw4wOuDDGJ1+GNTWuULfBmmJJyqHSxRPABw9Jz9DqAqs6IIDT+MUk0CWZmXnWXAjNayuQkyUO2ImOWtuTcb5BQ+53zjvR3Uxm9z/YZrtkPpndoaCH9Jl5QRsm4VmflVHLs8SUS0cjjs3K3tjsS/Q42BOG6BPOCRo+/Z7M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779388214; c=relaxed/simple; bh=+N4FQI59kWRap4CJaCf7HPKAlOiCSyLmVam6TLicvOU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=dq++vDfftUs8F0cr32Utusiz+49xm/h4tEfqqx3+bAKRpwsrFCEjSck3U7idPTnWo9jx9EyYZlrJCEZYenNkYLP9jsScKHmEv0OGpuW9dfX/2WHpCry5iAKRVMgO022CuI8UwMXeBLSQ+oO8OJjK5qFW17Cw7Vq7qEUkxNsXB1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WPmEQQy5; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WPmEQQy5" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id A02241F000E9; Thu, 21 May 2026 18:30:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779388212; bh=ECWaFkdV+4cBSuz9HojLDK9llcCfMbzABWVVyhnQq0E=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=WPmEQQy5NHpFDD/wkIRi6g9EaurN6Mq0YwCRl6vTxBg9ROVbBD+pyA6swWeIgNsBM TqZv+t5kjN3RsLk/61tRJJMc0Ru73X+g4W1QwdQ6vz4m1rO9LkeOQqVWydOvt9l2D+ 7EFHHokc+TRNnn1Tbvbks36oFE0FGo4GK3WQ56zZZSPVpKHziKkh07toyqueF5Zp8l Gr7gR58Q+k3UzRpggNx/XzWA7EnMWzmE/WVJVucK7jmOfyXs0Riu3FWbWlVv/+6MZS k92SDjwu/fmWwDYVLW1wXPmPYlRJAgT6Qj+6oyGEJAcI1Auy2Nq9ZzEIhQYjKY/u2p ulcdroFBRvg0g== From: Thomas Gleixner To: David Woodhouse , Miroslav Lichvar Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock In-Reply-To: References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> Date: Thu, 21 May 2026 20:30:09 +0200 Message-ID: <87o6i8vcni.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, May 20 2026 at 13:21, David Woodhouse wrote: > On Wed, 2026-05-20 at 12:39 +0200, Miroslav Lichvar wrote: >> It isn't adjusted, but it can be used as a stable reference avoiding >> the multiplier-induced jitter, interference from other processes, and >> synchronization loops, e.g. when an NTP client is synchronizing to an >> NTP server running on the same system (in different containers).=20 > > We could just use the TSC for this, insted of MONOTONIC_RAW, couldn't > we? Do all our clock discipline of the *TSC* against the external > sources, and then use the same timekeeper_set_reference() to ask the > kernel's core timekeeping to track the TSC-to-realtime relationship > that we desire? > > That's exactly what I'm planning to do for a dedicated hosting > environment. I think the patches which allow PTP to return paired > timestamps with reference to TSC instead of CLOCK_MONOTONIC landed in > the net-next tree today? Bah. > (for TSC, read 'arch counter, timebase, etc.' =E2=80=94 none of this is x= 86- > specific but 'TSC' is quicker to type...) As I said in the other thread, that's just creating yet another private mechanism instead of collecting the counter value together with e.g. CLOCK_REALTIME or utilizing the PMT correlated one which is available in get_device_crosstime_stamp(). Can we please stop creating specialized interfaces and instead make them generic, so they can be used for everything? Then you can go and extend the posix-timer interface with clock_set_time_reference() (or whatever name we come up with) and provide the functionality for all steerable clocks. That'd allow chronyd to completely ignore the kernel side NTP PLL and do everything in user space. That obviously needs some thought and input from the chrony folks, but that's a long term useful solution and not some 'scratch my itch' side channel. Thanks, tglx