Date: Thu, 18 Jul 2002 15:45:29 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: ticso@cicely.de Cc: Jeremy D'Hoinne <jeremy.dhoinne@netasq.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: select() behavior when system date changes Message-ID: <3D374509.DA9EF368@mindspring.com> References: <20020718162622.60f83271.jeremy.dhoinne@netasq.com> <20020718221728.GB39237@cicely5.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote: > > I have a problem with many server daemons. > > select() might block for a long time if system date changes. > > > > --------- > > Example : > > at 10h00am > > I call select() with a timeout argument set to 2min, > > > > at 10h01am, time changes to 09h59am. > > > > select() returns at 10h02am, it has blocked during 5 minutes. > > Normaly time only goes forward and never skips. There are three ways of measuring timer intervals: o Absolute delta The timer expires after an elapsed interval, counted on real ticks o Relative delta The timer expires after the wall clock indicates an elapsed interval, counted in effective ticks o Absolute endpoint The timer expires on or after an endpoint Right here, you seem to be complaining about "absolute endpoint", where an endpoint was calculated from the current time at the time of the call to set the timer. Arguably, select(2)'s timer *should* be a delta timer, rather than an endpoint timer, but... absolute, or relative? The answer depends on the application, doesn't it? Also, power management has made it nearly impossible to account "ticks" for a delta timer these days, no matter what (you can not expect a delta timer to fire and do work while a machine is suspended or hibernating pending wakeup). Normally, you won't see wide swings in the endpoint comparison time... if you are running NTP, and seeing wide swings, then yur hardware has a large clock drift, and your update time interval needs to be significantly decreased. Given your other postings, it appears that your complaint is that the daylight savings time changes are reflected in your time base from your hardware itself: the CMOS clock moves a full 3600 seconds, all at once. The only real fix for this, as I've stated three times now, is to make your hardware not do that, even if you have to reflash your BIOS after talking to the vendor. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D374509.DA9EF368>