From owner-freebsd-current  Sun Jul 14 01:06:20 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id BAA01281
          for current-outgoing; Sun, 14 Jul 1996 01:06:20 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA01274
          for <current@freebsd.org>; Sun, 14 Jul 1996 01:06:14 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA20603; Sun, 14 Jul 1996 18:05:15 +1000
Date: Sun, 14 Jul 1996 18:05:15 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199607140805.SAA20603@godzilla.zeta.org.au>
To: dfr@nlsys.demon.co.uk, terry@lambert.org
Subject: Re: NFSv3 fixes for review
Cc: current@freebsd.org, dfr@render.com
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>This fix seems to work right for me. I'm nervous about the use of the
>timeval, mostly because I'm not sure that it is monotonically
>increasing in the ntpd time synchronization case (and haven't
>looked deep enough to verify that the reported time from the
>microtime is not affected by adjustments.

xntpd only does tiny adjustments which can't possibly make the clock
go backwards.  OTOH, ntpdate or ordinary `date' can set the clock back
by years.

>Is there a seperate monotonically increasing clock, which is not
>modified by time adjust?  I guess this would be a factor only on a

mono_time.

>system with a relatively high drift rate (such that a reboot could
>occur such that the delay did not exceed the drift, causing the XID
>to go backward).

Oops, mono_time isn't monotonic across reboots.  I think it is reset
by reboot so it is very unsuitable.

Bruce