From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 65F9B4028FC for ; Tue, 19 May 2026 14:22:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200541; cv=none; b=fT/M5NxMz61e0gKpd2BnmgTBUZi7u28avuGNbycPLsPDAm4Ve2brkKFVz7PjpDzbrbGaEI+++N0I7bPcJIIlaXmLErLtA/vy3fCJNCxhbP14TCF0qe77jhmFN4HjOXYA2kxQSfFpYx1N1XijSgGX3FmjP9T6pHwp8HixKAmBbQU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779200541; c=relaxed/simple; bh=3TZPgbE9Sm32EwSMvnz0jOZGU56pW5BJgccrGZCO2zU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fytRvkXoiuHUrSrz/vappVjsQquJiUkSFAGaiO+HO09l1Afh5QIN/mRykv+BOxPzEByD1J7AYp33vqNKoC/VQ5xgpb8FIQIiTp8URDOwZzTx+rL+jBtOjRqy4yP/PnIOSWJvqN4rR49MsJyrGbJh3uWdh6aEqp5ixnHchZKDegs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Pr9pnjbG; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Pr9pnjbG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1779200538; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XTfx/y3MosxXMoSJxnLMGLqCYVI9sgQYVd0Xr7RWvB8=; b=Pr9pnjbGB0cMw38twNzMZe7Z2/z8UmjBOFVm+gomgKU51hKsJt+q51SRCS5M8GdhaHNlbN bVLXoX4Wj98Mf8DEna4O7MvpJOH6tp5i3GgUboH9wZHw5/RK/bI214Xwl+DIWGkGmPvajf p3mnU6ox91+6Mvcna3AAe0DlUIk/bKo= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-676-LosedL1-Oy-0uIw-bhMecw-1; Tue, 19 May 2026 10:22:11 -0400 X-MC-Unique: LosedL1-Oy-0uIw-bhMecw-1 X-Mimecast-MFC-AGG-ID: LosedL1-Oy-0uIw-bhMecw_1779200525 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A7DB21A26D16; Tue, 19 May 2026 14:17:53 +0000 (UTC) Received: from localhost (unknown [10.43.135.229]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AE1E81684; Tue, 19 May 2026 14:17:48 +0000 (UTC) Date: Tue, 19 May 2026 16:17:44 +0200 From: Miroslav Lichvar To: David Woodhouse Cc: Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Thomas Gleixner , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 3/8] timekeeping: Clamp time_offset delta to prevent infinite tail Message-ID: References: <20260517220326.4625-1-dwmw2@infradead.org> <20260517220326.4625-4-dwmw2@infradead.org> 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=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 On Tue, May 19, 2026 at 02:31:41PM +0100, David Woodhouse wrote: > On Tue, 2026-05-19 at 15:25 +0200, Miroslav Lichvar wrote: > > I don't think that is an acceptable change of the filter. The impact > > could be measured on a sufficiently stable clock. > > > > To me that looks like using a wrong tool for the job. > > I chose 20ns/s because it's fairly much in the noise of the existing > jitter. The idea here is that there's no change in the initial part of > the exponential delivery of time_offset, but the long asymptotic tail > ends up applying a skew per second which is *far* smaller than the > inter-tick jitter of the output anyway, which seems pointless? It changes the initial part too. Consider a case where the PLL time constant is set to 0 and the application is updating the PLL once per second. ntp_offset_chunk() returns 1/4th of time_offset. If the NTP/PTP measurements are stable to about 20 nanoseconds, the clock corrections will be 4 times larger than expected. By inter-tick jitter you mean the +1/0 multiplier changes? That can be below 1 nanosecond if the clock is updated frequently enough and the multiplier is sufficient large. > Without it, the output basically *never* converges to the desired line. I think it's not supposed to get to zero. It is expected to be updated regularly with new measurements. If the cancellation threshold was based on the time constant and the time since last update (e.g. 32 seconds for time constant 0), that would probably make more sense to me. -- Miroslav Lichvar