Date: Fri, 28 Oct 2005 16:44:35 -0400 From: Chuck Swiger <cswiger@mac.com> To: Benjamin Lutz <benlutz@datacomm.ch> Cc: current@freebsd.org Subject: Re: Timers and timing, was: MySQL Performance 6.0rc1 Message-ID: <43628DB3.6070402@mac.com> In-Reply-To: <43627CCB.2060508@datacomm.ch> References: <26845.1130452524@critter.freebsd.dk> <436167D5.2060104@mac.com> <43627CCB.2060508@datacomm.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Lutz wrote: > Chuck Swiger wrote: >>For one case, I have some code which needs to update statistics like >>"packets sent per second" (or "per minute" or "per hour") on a periodic >>basis. I use a reasonable timeout-- ~50ms-- for a call to select() (or >>pcap_dispatch(), etc) so I check time() perhaps 20 times a second, and >>then update my per-second stats when I notice that time(&now) returns a >>different value. >> >>Is there a better way of running code once a second, as close to the >>time the clock ticks? > > Once you've seen the clock tick, you can then probably use a longer > timeout in the next select, something in the 700ms range? I use alarm() to schedule period wakeups at one-minute, hourly etc intervals, after doing a shuffle to sync with localtime() and the fractional second part so that they are neatly aligned. Well, the issue is that these calls don't always return within the time you give them, and the pcap_dispatch() timer doesn't even start counting until it sees a packet, so my choice of timeout length is driven more by how much off am I willing to be if the call returns late. Giving them a half-second timeout sometimes seems to mean up to a 1.5 or 2 second pause if the network is completely quiet. [1] Take care, -- -Chuck [1]: If I don't use threaded DNS resolver code that was foisted upon me and avoid -pthreads it's better. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43628DB3.6070402>