Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752259AbeAERXW (ORCPT + 1 other); Fri, 5 Jan 2018 12:23:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:20903 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752121AbeAERXV (ORCPT ); Fri, 5 Jan 2018 12:23:21 -0500 From: Miroslav Lichvar To: linux-kernel@vger.kernel.org Cc: John Stultz , Prarit Bhargava , Richard Cochran , Miroslav Lichvar Subject: [PATCHv2 0/2] Improve stability of system clock Date: Fri, 5 Jan 2018 18:23:19 +0100 Message-Id: <20180105172319.14806-1-mlichvar@redhat.com> In-Reply-To: <20180105171448.14533-1-mlichvar@redhat.com> References: <20180105171448.14533-1-mlichvar@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 05 Jan 2018 17:23:21 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: (resending with fixed CC) v1->v2 - rebased to current code - improved commit messages This patch set improves stability and accuracy of the system clock when synchronized to precise time sources like the new PTP KVM clock or NTP/PTP with hardware timestamping. The biggest difference is expected on mostly idle systems running with NOHZ (i.e. having infrequent updates of the clock). The stability is affected by the error which accumulates in the ntp_error register and its correction, which is performed by adjusting the timekeeping multiplier. After removing the old vsyscalls, which added an error due to nanosecond rounding, there are now three sources of the error: - alignment of frequency adjustments to ticks - iterative correction of the multiplier - limited resolution of the multiplier Instead of trying to correct the error faster, which is difficult to do without causing instability due to irregular updates of the clock, the patches remove the first two sources of the error. With the only remaining source the correction logic can be significantly simplified and the frequency of the clock is much more stable and accurate. The freq-step selftest (with PTI disabled to pass the check of the precision of the MONOTONIC_RAW clock) shows a significant improvement: Before: Checking response to frequency step: Step 1st interval 2nd interval Freq Dev Max Freq Dev Max 40960 +0.131 22 147 +0.136 1 3 [OK] 40960 +0.012 51 347 +0.005 1 3 [OK] 40960 +3.832 25038 171297 -0.169 1 2 [OK] 40960 +2.151 13165 89429 +0.113 1 3 [OK] 40960 -0.095 1 2 -0.095 1 3 [OK] 640 -0.154 1 6 -0.154 1 3 [OK] 640 +0.003 1 6 +0.003 1 3 [OK] 640 -0.131 2 9 -0.131 1 2 [OK] 640 -0.026 19 125 -0.029 1 3 [OK] 640 -0.175 1 3 -0.175 1 3 [OK] 10 +0.001 3 9 +0.000 3 6 [OK] 10 +0.002 7 41 +0.000 2 5 [OK] 10 -0.000 2 5 +0.000 3 5 [OK] 10 +0.001 5 23 -0.000 2 5 [OK] 10 +0.000 2 5 -0.000 6 15 [OK] After: Checking response to frequency step: Step 1st interval 2nd interval Freq Dev Max Freq Dev Max 40960 +0.000 2 5 -0.000 2 5 [OK] 40960 -0.000 2 5 -0.000 3 8 [OK] 40960 -0.000 3 7 +0.000 3 6 [OK] 40960 +0.000 3 6 -0.000 2 6 [OK] 40960 -0.000 2 5 +0.000 3 7 [OK] 640 +0.001 2 9 -0.000 2 5 [OK] 640 -0.000 3 6 +0.000 2 5 [OK] 640 -0.001 2 4 +0.000 1 3 [OK] 640 -0.000 2 5 +0.000 2 4 [OK] 640 +0.000 3 6 -0.000 3 6 [OK] 10 -0.000 2 5 +0.000 2 5 [OK] 10 -0.000 2 5 +0.000 2 5 [OK] 10 +0.000 2 5 +0.000 2 5 [OK] 10 +0.000 2 5 +0.000 2 5 [OK] 10 +0.000 3 12 +0.000 4 11 [OK] Miroslav Lichvar (2): timekeeping: Don't align frequency adjustments to ticks timekeeping: Determine multiplier directly from NTP tick length include/linux/timekeeper_internal.h | 2 + kernel/time/timekeeping.c | 140 ++++++++++++------------------------ 2 files changed, 48 insertions(+), 94 deletions(-) -- 2.9.5