Re: time: Should real time usage account discontinous jumps?

Petr Pisar <[email protected]> Thu, 1 Dec 2016 07:17:32 +0100

Newsgroups	gmane.comp.gnu.utils.bugs
Message-ID	<[email protected]>

On Thu, Sep 26, 2013 at 08:09:16AM -0700, Charles Swiger wrote:
> On Sep 25, 2013, at 11:37 PM, Petr Pisar <[email protected]> wrote:
> > On 2013-09-26, Bob Proulx <[email protected]> wrote:
> >> Petr Pisar wrote:
> >>> The GNU time as well as bash built-in compute real time process usage as
> >>> a simple difference between two real time points. If there was a time
> >>> adjustement in between (by NTP or manual), the meassured value would be
> >>> affected.
> >> 
> >> NTP will never step the clock.  NTP will adjust the time of each clock
> >> tick to keep the clock on time and so that every tick is present.  If
> >> the clock is being step'd it would be due to other reasons such as
> >> manually.
> > 
> > NTP does not step, NTP slows or accelerates real time. But the effect is
> > the same---the time point difference mismatches physical duration.
> 
> NTP calls adjtime() or similar to adjust the rate that the system clock [1]
> increments it's notion of time to match "real time" obtained from the NTP
> timesource, which is either a lower-stratum NTPd server via the Internet,
> or a primary time reference like a GPS sensor or atomic clock.
> 
> >> But why would there be a time adjustment between?  Stepping the clock
> >> is an abnormal condition.  It isn't something that should ever happen
> >> during normal system operation.  If your clock is being stepped then
> >> that is a bug and needs to be fixed.
> > 
> > NTP per definition refuses to adjust clock if the difference is too big.
> > Thus distributions usually step the clock on first NTP contact, and then
> > keep adjusting. With mobile hosts loosing and getting network
> > connectivity on the fly, it's quite possible the system will experience
> > time steps.
> 
> Oh, agreed.
> 
> For the normal case, ntpd won't change time faster than 0.5 ms per second,
> but if the sample interval is long enough to contain network dropout and
> re-acquisition, then ntpd might be restarted and do an initial step of time
> rather than the slew rate.
> 
> However, on a good day, ntpd will have already figured out the intrinsic
> first-order deviation of the local HW clock versus "real time", and the
> device will continue to keep better time as a result even thru a network
> outage than it would otherwise.
> 
> >>> I have found any hint nowhere if this is intended behavior or if one
> >>> should meassure some kind of monotic time line.
> >> 
> >> Since stepping the clock is not a normal condition I don't think it
> >> matters.  It certainly isn't a problem if the system is running NTP
> >> and the clock is running normally.
> > 
> > I agree one can consider NTP-adjusted clock as `running normally'. Because
> > the reason for adjustment is that local real clock is not accurate
> > enough. In this light, CLOCK_MONOTONIC seems good enough.
> 
> Yes, if you want to compute "how long something took" via delta between start
> and finish, then using CLOCK_MONOTONIC is likely the best choice.
> 
Please excuse resurrecting this old story. I forgot it and now I found it.
Two patches are attached that should implement the idea discuessed in this
thread.

The first patch corrects configure.in because the old syntax does not work
with my autotools anymore. The second patch is the implementation of the time
measurement with clock_gettime(CLOCK_MONOTONIC).

-- Petr

0001-Modernize-configure.in.patch (text/plain, 1010 B)

From 6b86491be92970163d94323959aff3ba2390bfcf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <[email protected]>
Date: Wed, 30 Nov 2016 17:38:37 +0100
Subject: [PATCH 1/2] Modernize configure.in
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

After editting configure.in and running autoreconf with autoconf-2.69
and automake-1.15, make command failed because configure.in did not
hook Automake. This patch allows to regenerate the scripts with
contemporary autotools.

Signed-off-by: Petr Písař <[email protected]>
---
 configure.in | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/configure.in b/configure.in
index 1531bad..2380b76 100644
--- a/configure.in
+++ b/configure.in
@@ -1,9 +1,6 @@
 dnl Process this file with autoconf to produce a configure script.
-AC_INIT(time.c)
-VERSION=1.7
-AC_SUBST(VERSION)
-PACKAGE=time
-AC_SUBST(PACKAGE)
+AC_INIT([time], [1.7])
+AM_INIT_AUTOMAKE()
 
 AC_ARG_PROGRAM
 
-- 
2.7.4

0002-Prefer-clock_gettime-CLOCK_MONOTONIC.patch (text/plain, 2.7 KB)

From e1c7f33e09f1d741de0f4d3a094a5d57337c4bac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= <[email protected]>
Date: Wed, 30 Nov 2016 17:13:16 +0100
Subject: [PATCH 2/2] Prefer clock_gettime(CLOCK_MONOTONIC)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

gettimeofday() reports wrong elapsed real time if a time step was
inserted while running a program. This can happen on initial time
adjustment from NTP server or by manual adjustement by date command.

This patch uses clock_gettime(CLOCK_MONOTONIC) instead (if available)
that does not suffer from the issue.

<http://lists.gnu.org/archive/html/bug-gnu-utils/2013-09/msg00008.html>

Signed-off-by: Petr Písař <[email protected]>
---
 configure.in |  1 +
 resuse.c     | 27 +++++++++++++++++++++++++--
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/configure.in b/configure.in
index 2380b76..658a254 100644
--- a/configure.in
+++ b/configure.in
@@ -29,6 +29,7 @@ dnl Checks for library functions.
 AC_FUNC_VPRINTF
 AC_FUNC_WAIT3
 AC_CHECK_FUNCS(strerror)
+AC_CHECK_FUNCS(clock_gettime)
 
 AC_MSG_CHECKING(for getpagesize)
 AC_TRY_LINK([#include <sys/param.h>],
diff --git a/resuse.c b/resuse.c
index 4133941..da0da64 100644
--- a/resuse.c
+++ b/resuse.c
@@ -23,7 +23,14 @@
 #include "wait.h"
 #include "port.h"
 
-#if !HAVE_WAIT3
+#if HAVE_WAIT3
+# if HAVE_CLOCK_GETTIME
+#  ifndef _POSIX_C_SOURCE
+#   define _POSIX_C_SOURCE 199309L
+#  endif
+#  include <time.h>
+# endif
+#else
 # include <sys/times.h>
 # ifndef HZ
 #  include <sys/param.h>
@@ -48,7 +55,14 @@ resuse_start (resp)
      RESUSE *resp;
 {
 #if HAVE_WAIT3
+#if HAVE_CLOCK_GETTIME
+  struct timespec res;
+  clock_gettime(CLOCK_MONOTONIC, &res);
+  resp->start.tv_sec = res.tv_sec;
+  resp->start.tv_usec = res.tv_nsec / 1000;
+#else
   gettimeofday (&resp->start, (struct timezone *) 0);
+#endif /* !HAVE_CLOCK_GETTIME */
 #else
   long value;
   struct tms tms;
@@ -56,7 +70,7 @@ resuse_start (resp)
   value = times (&tms);
   resp->start.tv_sec = value / HZ;
   resp->start.tv_usec = value % HZ * (1000000 / HZ);
-#endif
+#endif /* !HAVE_WAIT3 */
 }
 
 /* Wait for and fill in data on child process PID.
@@ -76,6 +90,9 @@ resuse_end (pid, resp)
   int status;
 
 #if HAVE_WAIT3
+#if HAVE_CLOCK_GETTIME
+  struct timespec res;
+#endif
   pid_t caught;
 
   /* Ignore signals, but don't ignore the children.  When wait3
@@ -86,7 +103,13 @@ resuse_end (pid, resp)
 	return 0;
     }
 
+#if HAVE_CLOCK_GETTIME
+  clock_gettime(CLOCK_MONOTONIC, &res);
+  resp->elapsed.tv_sec = res.tv_sec;
+  resp->elapsed.tv_usec = res.tv_nsec / 1000;
+#else
   gettimeofday (&resp->elapsed, (struct timezone *) 0);
+#endif
 #else  /* !HAVE_WAIT3 */
   long value;
   struct tms tms;
-- 
2.7.4

signature.asc (application/pgp-signature, 213 B)