From owner-freebsd-standards@freebsd.org Wed Feb 21 22:14:29 2018 Return-Path: Delivered-To: freebsd-standards@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 971D5F059E5 for ; Wed, 21 Feb 2018 22:14:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 28129762E2 for ; Wed, 21 Feb 2018 22:14:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id p78so3783721iod.13 for ; Wed, 21 Feb 2018 14:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=gU4gYF1qpfETgnItMhM2xAKe23OyQi6rDGGjyVLoC3A=; b=hNvvv21ItYmBdFJIk0EN7ir0OjTvkFu/ymmDGi4cXnlBNiNLNcBzsUF9H7kUsxuB2V U2BV5YRwRdWHoop4HIQgb3h5oZFHV3yxQRR0x/9peSe0UqQsg2p1MKXOxfjNU0C8iNuG vrTmZuC/JIzlW+lRG+x54NeuZ/6YSgayBTkkJKV7JM0QEcyaizJSEzVUQ3C7h+e5gAyJ RN/tt+chqj4HR/dovzk+NOdZo5V13ysF6O8/FjJTSWqH521aBomLY2RIETg+uVx91AMZ O0Xw7+UBQjxG1wZgLI4Ig9wtxwNxeSxrTGACauMu/vBn+jUxRHGPkt8QXUMwUO65qO7d CKDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=gU4gYF1qpfETgnItMhM2xAKe23OyQi6rDGGjyVLoC3A=; b=JLWy0VyyaM2WJ5GOG0iHMzMSZAeeLYifMb3S2sve7sPe8lUfpttjh/Ri/aK2RCGvZ2 kmjas0Y17P732WWNPxeNQvIihjDknAnxq36yTcA4Rfg9OqBYdW0ug7AcuRzShWDk2IWO BzaCDWLOjwwXp17uk0LC2GjMd+RjeksncLCeA6FvXgE7AnMOfuTvn1AP5PIkXQowdtge X/GKBjISbsr+mBN5AAVvkZxA7dHr6FKShLvPEJQl5uyVfLx3aX4vYZZCe+FoU4+dqUZ5 xe1UMhcodrzjyi/pdminOZSeOXtMReq3xf+eWxEyMfcMSC1TvU6ieZy3JwCqFkU/Rf9E r2iA== X-Gm-Message-State: APf1xPAckqn/xYEtQ3VSWUnIMOKyhpuokVR0i7LeJqjLunzRZZVyAeny 5Q7NzjUDbBPTsUOS4FOfNxcIw7PmTowe4qd+F1BJLw== X-Google-Smtp-Source: AG47ELucDLY+tvsPIvnWoHH8/PcXLY7fzvmjWhyuCscQWEJ0ncZbYeXk5vnXadMq9tZeHHG2SMYYeE5LCOZbzZwH8UQ= X-Received: by 10.107.180.83 with SMTP id d80mr6113764iof.168.1519251268439; Wed, 21 Feb 2018 14:14:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Wed, 21 Feb 2018 14:14:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: References: From: Warner Losh Date: Wed, 21 Feb 2018 15:14:27 -0700 X-Google-Sender-Auth: FAA8Cp-9QH7eEuvt3tELm5oqJ9A Message-ID: Subject: Re: Using the monotonic clock in time(1)? To: Alan Somers Cc: freebsd-standards@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 22:14:29 -0000 On Wed, Feb 21, 2018 at 2:33 PM, Alan Somers wrote: > time(1) currently uses the realtime clock, which is undesirable for timing > short-lived commands while ntpd is active. I opened a review to add an > option to use the monotonic clock instead, but jilles suggested that time > should use the monotonic clock unconditionally, since that's almost always > better for measuring short durations. However, the Open Group's > specification seems to require the real time clock. What do the standards > folks think? Is the Open Group spec sufficiently ambiguous and/or wrong > that we should switch to the monotonic clock instead? > > https://reviews.freebsd.org/D14032 > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/time.html The issue with ntpd should only be the initial step. After that it steers the frequency of the base clock which affects all clocks. It should be a rare issue that the two clocks give different results. Having said that I see no issue with using a monotonic clock here. I think there's enough wiggle room in the standard to support it. It's really the only clock you can t2-t1 with and get a guaranteed to be meaningful answer. I can't imagine the OpenGroup specifies what happens over a time step the real time clock for programs timed with time. The (real) is in parens, which is not a normative form for specifying the time. I'm not a professional standards lawyer, but my amateur reading says this is a good change. Warner