From owner-cvs-all@FreeBSD.ORG Fri Oct 21 19:04:25 2005 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14F8516A41F; Fri, 21 Oct 2005 19:04:25 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541EE43D46; Fri, 21 Oct 2005 19:04:24 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j9LJ4MXR087858; Fri, 21 Oct 2005 12:04:22 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <4359216B.68A42960@networx.ch> References: <30805.1129910750@critter.freebsd.dk> <0D10B55A-A82D-433F-81CA-A5A02B36DA75@xcllnt.net> <4359216B.68A42960@networx.ch> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F6E14D5-73B2-448A-9440-32DFFBF4E9C4@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 21 Oct 2005 12:04:20 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.734) Cc: src-committers@FreeBSD.org, Andre Oppermann , Bruce Evans , cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Poul-Henning Kamp Subject: Re: Timekeeping [Was: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c] X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 19:04:25 -0000 On Oct 21, 2005, at 10:12 AM, Andre Oppermann wrote: > Marcel Moolenaar wrote: > >> >> On Oct 21, 2005, at 9:05 AM, Poul-Henning Kamp wrote: >> >> >>> In message <20051022011020.T5554@delplex.bde.org>, Bruce Evans >>> writes: >>> >>> >>> >>> >>>> How do you resync laptops after suspending them for long enough for >>>> the clock to drift? Use ntpd and let it step, or use ntpd -x >>>> and let >>>> it take hours to resync? The right thing to do is step the >>>> clocks to >>>> the current time immediately so that they are correct while the >>>> system >>>> is actually being used. >>>> >>>> >>> >>> Ahh, and now we get into interesting territory: What _is_ the >>> definition of uptime for a laptop which has been suspended ? >>> >> >> I don't think the definition has to change, but I don't know what >> the *exact* definition of uptime is. Wikipedia says this: >> >> "Uptime is a measure of the time a computer system has been up and >> running. It came into use to describe the opposite of downtime, >> times when a system was non-operational." >> >> Given this, suspend is downtime and the uptime is therefore defined >> as the amount of time since resume. >> >> Doesn't seem unreasonable to me. >> >> >>> Again, if you have been sitting in DDB, what exactly is the >>> definition >>> of "uptime" ? >>> >> >> Since the kernel is non-operational while in DDB, uptime is to >> reset when leaving DDB. Again, according to the Wikipedia definition >> of uptime. I'm having more problems finding this reasonable, but >> it's not unacceptable. >> >> The question therefore is: which definition of uptime do we try to >> implement? >> > > The question is "up and running" since when? Since the last > interruption (suspend or ddb) or since the last initialization > of the kernel (boot or reboot)? IMO the latter minus the former > in SI seconds. I think the accepted property is that uptime is continuous. Put differently: the Wikipedia definition defines uptime as the opposite of downtime. Since downtime is non-qualified, there's no distinction between boot, reboot, suspend or in-debugger. Non-operational is non-operational. Thus the question of "since when" can be answered as: the first time it became operational after being non-operational. Note also that the state of being non-operational is unqualified as to its duration. It is, theoretically speaking, possible to define a missed clock interrupt as having had a state of non- operation because operation implies being able to service clock interrupts... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net