From owner-freebsd-current Thu Dec 16 12:33:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 29B9F14FBB for ; Thu, 16 Dec 1999 12:33:49 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA17548; Thu, 16 Dec 1999 21:33:32 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Warner Losh Cc: freebsd-current@FreeBSD.ORG Subject: Re: Serious server-side NFS problem In-reply-to: Your message of "Thu, 16 Dec 1999 13:24:37 MST." <199912162024.NAA73705@harmony.village.org> Date: Thu, 16 Dec 1999 21:33:32 +0100 Message-ID: <17546.945376412@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199912162024.NAA73705@harmony.village.org>, Warner Losh writes: >In message <16722.945365564@critter.freebsd.dk> Poul-Henning Kamp writes: >: If people do a "settimeofday" we change the boot time since the >: amount of time we've been up *IS* known for sure, whereas the boottime >: is only an estimate. > >There is one problem with this. The amount of uptime isn't the same >as the amount of time since the machine booted. How can this happen? >When a laptop suspends, it doesn't update the update while it is >asleep, nor does it update the uptime by the amount of time that has >been slept. IS this a bug in the apm code? Well, I don't think anybody has seriously thought about what the right semantics for APM is, and consequently the code we have is rather evil. What to do is a definition question more than anything, and I guess the answer to the question: if I call timeout(bla bla bla, 3600*hz) and suspend the machine for half an hour, how long time after it resumes will I be called ? will point the direction. In other words: Do routes expire while suspended ? Do TCP timers tick ? I would say "they sure should do, because they relates to external events" (if we accept that as the answer we need to to call softclock a LOT of times when we come out of suspend). In reality we have not clear definition of "suspend" for a unix system, and the kernel may need to learn about "timeouts on the kernel consious timescale" vs. "timeouts on the wallclock timescale" and similar hair. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message