Date: Thu, 16 Dec 1999 13:39:39 -0700 From: Warner Losh <imp@village.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Serious server-side NFS problem Message-ID: <199912162039.NAA73855@harmony.village.org> In-Reply-To: Your message of "Thu, 16 Dec 1999 21:33:32 %2B0100." <17546.945376412@critter.freebsd.dk> References: <17546.945376412@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <17546.945376412@critter.freebsd.dk> Poul-Henning Kamp writes: : 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. Don't know if I'd go so far as to say evil, but there are some pola issues. : 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. It will be called 3600*hz softclock ticks after the original timeout was called, which could be >> a wall time of 1 hour. I'd guess that it would be after 1 hour and 30 minutes. : 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). Uggg. That's right. The current approach is to step the current time by the amount of time we slept, based on rtc measurements (high precision time keeping at its absolute worst). : 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. Yes. Some timeouts don't matter over a suspend (eg make sure that this card isn't wedged) while some should take the suspend into account (need to expire routes, arp entries, etc) Warner 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?199912162039.NAA73855>