Date: Thu, 16 Dec 1999 21:33:32 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Warner Losh <imp@village.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Serious server-side NFS problem Message-ID: <17546.945376412@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 16 Dec 1999 13:24:37 MST." <199912162024.NAA73705@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17546.945376412>