From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757554AbcFAMA0 (ORCPT ); Wed, 1 Jun 2016 08:00:26 -0400 Received: from ns.omicron.at ([212.183.10.25]:35061 "EHLO ns.omicron.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757265AbcFAMAY (ORCPT ); Wed, 1 Jun 2016 08:00:24 -0400 X-Greylist: delayed 1002 seconds by postgrey-1.27 at vger.kernel.org; Wed, 01 Jun 2016 08:00:23 EDT DKIM-Filter: OpenDKIM Filter v2.10.3 ns.omicron.at u51BhOQ4020980 Subject: Re: [PATCH] timekeeping: Fix 1ns/tick drift with GENERIC_TIME_VSYSCALL_OLD To: John Stultz References: <1464699966-26521-1-git-send-email-thomas.graziadei@omicronenergy.com> CC: lkml , Thomas Gleixner , Tony Luck , Benjamin Herrenschmidt From: Thomas Graziadei Message-ID: <574ECA5C.4040005@omicronenergy.com> Date: Wed, 1 Jun 2016 13:43:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.22.33.56] X-ClientProxiedBy: EXC02-ATKLA.omicron.at (172.22.100.186) To EXC01-ATKLA.omicron.at (172.22.100.185) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/01/2016 01:11 AM, John Stultz wrote: > On Tue, May 31, 2016 at 6:06 AM, Thomas Graziadei > wrote: >> From: Thomas Graziadei >> >> The user notices the problem in a raw and real time drift, calling >> clock_gettime with CLOCK_REALTIME / CLOCK_MONOTONIC_RAW on a system >> with no ntp correction taking place (no ntpd or ptp stuff running). > > Hmm.. Curious. Was it actually drifting, or was it just > oscillating/ringing near the RAW clock's value? It is actually drifting. This is the output from a little test program: realtime : 1464775074:846282133 raw time : 1054:851963700 drift_real: 999402ns total duration: 1000s 158517540ns > >> The problem is, that old_vsyscall_fixup adds an extra 1ns even though >> xtime_nsec is already held in full nsecs and the remainder in this >> case is 0. Do the rounding up buisness only if needed. > > The patch looks ok. But I'm curious what architecture you were seeing > this on (ia64, powerpc?), as it would be much nicer to have those > architectures migrate off of the old low-res vsyscall calculation and > use the newer method with sub-ns precision, instead of trying to > further fix up the deprecated method. > > I had submitted a patch to convert ia64 awhile back, but I don't > recall getting much feedback. > We are using a powerpc architecture. I guess you are right, it would be nicer to use the new method but then on the other hand, this timing topic is rather new to me. > thanks > -john > thanks, Thomas