From owner-freebsd-hackers Thu Nov 6 15:35:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22067 for hackers-outgoing; Thu, 6 Nov 1997 15:35:08 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA22052 for ; Thu, 6 Nov 1997 15:35:02 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id XAA13772; Thu, 6 Nov 1997 23:43:10 GMT Date: Thu, 6 Nov 1997 23:43:10 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Mike Smith cc: hackers@hub.freebsd.org Subject: Re: gettimeofday() overhead In-Reply-To: <199711041315.XAA00406@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 4 Nov 1997, Mike Smith wrote: > OTOH, if +/- 1 second is good enough, a once-a-second timer and a local > call to gettimeofday() would be a simple and straightforward technique, > as was also suggested. But for the application which (IIRC) started this discussion - NATD, that might be worse overall. Since NAT is often used with dial-up links, and hence not used at all for long periods, the cost of keeping the daemon in core and servicing the 1Hz ticks when it has no useful work to do could well add up to more overall system load than the individual calls per packet - gettimeofday() is quite cheap. Of course you could keep flags such that you turn off the timer when there is nothing going on (traded against a small overhead in maintaining flags to know when this is), but this seems unduly complex for a rather minor gain.