Unix Programming - Is time(NULL) a slow operation?

Author

Is time(NULL) a slow operation?

A. Farber

2008-01-24, 8:19 am

Hello,

I have non-forking daemon polling several TCP sockets
and running under Linux, OpenBSD and Cygwin.

In several spots I call time(NULL) to register the last
time I've read something from a socket and to be able
to close connections to inactive clients:

http://rtmpd.cvs.sourceforge.net/rt....c?revision=1.2
(just search for "time(NULL)" please).

I wonder, if time(NULL) is an expensive operation or
is it just a quick read of some value stored in OS anyway?

I.e. should I maybe introduce a global variable like

static time_t now;

at the top of rtmpd.c and just update it once - right
after the poll() call - or isn't that worth the hassle?

Regards
Alex

Stephane Chazelas

2008-01-24, 8:19 am

On Thu, 24 Jan 2008 04:41:12 -0800 (PST), A. Farber wrote:
[...]
> I wonder, if time(NULL) is an expensive operation or
> is it just a quick read of some value stored in OS anyway?
[...]

It's expensive in that it is a system call, but that's probably
the least expensive system call as it does indeed only return a
value stored in OS.

If it's a loop that you need to optimise at the instruction
level, then yes, you probably want to take it out of the loop, a
system call is always expensive.

--
Stephane

William Ahern

2008-01-24, 7:24 pm

A. Farber <Alexander.Farber@gmail.com> wrote:
> Hello,
>
> I have non-forking daemon polling several TCP sockets
> and running under Linux, OpenBSD and Cygwin.
>
> In several spots I call time(NULL) to register the last
> time I've read something from a socket and to be able
> to close connections to inactive clients:
>
> http://rtmpd.cvs.sourceforge.net/rt....c?revision=1.2
> (just search for "time(NULL)" please).
>
> I wonder, if time(NULL) is an expensive operation or
> is it just a quick read of some value stored in OS anyway?

Yes and no. On many Linux kernels with proper timer drivers (and hardware),
its very cheap; about as cheap as a system call can be made, and sometimes
cheaper. (RTDSC tricks on x86, in the future hopefully use of shared
memory.)

This is compared to, say, OpenBSD, where it can be 10x slower because the
system call usually involves reading directly from a hardware clock every
call, instead of making use of high performance timers. Horrible
performance.

> I.e. should I maybe introduce a global variable like
>
> static time_t now;

> at the top of rtmpd.c and just update it once - right
> after the poll() call - or isn't that worth the hassle?

It's certainly not a bad idea. I keep meaning to do it. But if you're
actually using poll(), instead of epoll(), kqueue(), etc, your major
bottleneck will almost certainly be with copying the descriptor information
in and out of the kernel, plus redundant work in the kernel, making it
prohibitive to scale, and so the cost of time() in that equation would be
quite negligible.

Rainer Weikusat

2008-01-24, 7:24 pm

William Ahern <william@wilbur.25thandClement.com> writes:
> A. Farber <Alexander.Farber@gmail.com> wrote:

[...]

>
> Yes and no. On many Linux kernels with proper timer drivers (and hardware),
> its very cheap; about as cheap as a system call can be made, and sometimes
> cheaper. (RTDSC tricks on x86, in the future hopefully use of shared
> memory.)

Linux (and presumably all UNIX(*)- and UNIX(*)-like kernels) does not
use the hardware for timekeeping, only to provide 'clock tick events'.

> This is compared to, say, OpenBSD, where it can be 10x slower because the
> system call usually involves reading directly from a hardware clock every
> call, instead of making use of high performance timers. Horrible
> performance.

If this was true (I cannot access the WWW at the moment), OpenBSD
could never be ported to devices without an RTC and it could never
support NTP-synchronized time.

Rainer Weikusat

2008-01-24, 7:24 pm

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> William Ahern <william@wilbur.25thandClement.com> writes:

[...]

>
> If this was true (I cannot access the WWW at the moment), OpenBSD
> could never be ported to devices without an RTC and it could never
> support NTP-synchronized time.

I have just checked this: The code to actually read the PC-RTC (yuck!)
is still in FreeBSD, but OpenBSD does not use it anymore, but the
'usual' software-adjusted hardware tick based mechanism.

William Ahern

2008-01-24, 7:24 pm

Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> William Ahern <william@wilbur.25thandClement.com> writes:
<snip>
>
> If this was true (I cannot access the WWW at the moment), OpenBSD
> could never be ported to devices without an RTC and it could never
> support NTP-synchronized time.

Admittedly, I was being imprecise. I'm certainly not well versed in
hardware. But, I'm not claiming that the OpenBSD kernel actually goes out to
the clock on the motherboard, w/ the quartz and the battery. Whatever you
call it, it's not, for instance, the HPET on modern x86 chipsets, or any of
the newer alternatives. It's whatever the original mechanism the i286 or
i386 provides, and its damn slow. Literally 10x slower, by my calculations.
This is on the same hardware (Sun Fire x2100), and also alternative hardware
(forget the specs).

Rainer Weikusat

2008-01-24, 7:24 pm

William Ahern <william@wilbur.25thandClement.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> <snip>
>
> Admittedly, I was being imprecise. I'm certainly not well versed in
> hardware. But, I'm not claiming that the OpenBSD kernel actually goes out to
> the clock on the motherboard, w/ the quartz and the battery. Whatever you
> call it, it's not, for instance, the HPET on modern x86 chipsets, or any of
> the newer alternatives. It's whatever the original mechanism the i286 or
> i386 provides, and its damn slow.

The default implementation is to use the i8254 timer chip on PCs,
calling the routine cited below for every gtod-call, possibly multiple
times:

u_int
i8254_get_timecount(struct timecounter *tc)
{
u_char hi, lo;
u_int count;
u_long ef;

ef = read_eflags();
disable_intr();

outb(IO_TIMER1 + TIMER_MODE, TIMER_SEL0 | TIMER_LATCH);
lo = inb(IO_TIMER1 + TIMER_CNTR0);
hi = inb(IO_TIMER1 + TIMER_CNTR0);

count = rtclock_tval - ((hi << 8) | lo);

if (count < i8254_lastcount) {
i8254_ticked = 1;
i8254_offset += rtclock_tval;
}
i8254_lastcount = count;
count += i8254_offset;
write_eflags(ef);

return (count);
}
[sys/arch/i386/clock.c]

This needs three I/O-operations going over some bus and is of course a
lot slower than accessing a CPU register (like the TSC).

This is not 'a hardware clock' but a programmable interval timer. But
you were arguably more correct than I would have believed before
reading through all of this.

John Tsiombikas

2008-01-25, 4:33 am

On 2008-01-24, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
>
> I have just checked this: The code to actually read the PC-RTC (yuck!)
> is still in FreeBSD, but OpenBSD does not use it anymore, but the
> 'usual' software-adjusted hardware tick based mechanism.
>

Of course it does. Most systems read the RTC at bootup to read the time,
then forget about it and increment internal timekeeping variables on
every timer interrupt. So you can't really get rid of the RTC code, but
no sane system would read it to implement any sort of syscall with it.

--
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/

John Tsiombikas

2008-01-25, 4:34 am

On 2008-01-24, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> The default implementation is to use the i8254 timer chip on PCs,
> calling the routine cited below for every gtod-call, possibly multiple
> times:
>
> u_int
> i8254_get_timecount(struct timecounter *tc)
> {
... [snip] ...
> }
>
> This needs three I/O-operations going over some bus and is of course a
> lot slower than accessing a CPU register (like the TSC).
>
> This is not 'a hardware clock' but a programmable interval timer. But
> you were arguably more correct than I would have believed before
> reading through all of this.

The PIT is an entirely different story, as you said it has nothing to do
with the RTC. It's a reliable and compatible timer interrupt source,
used almost universally on the PC platform, unless there is a better one
available like the HPET, which IIRC is only available on *very* recent
intel processors only.

the TSC (timestamp counter) is NOT a good timing source, and it doesn't
generate interrupts which is essential for any OS's timing needs. It's
just a value on *each* processor, which increments on every clock cycle.
Now this means that each processor of an SMP system would have a
*different* TSC value, and if frequency scaling is used, the TSC
frequency would vary wildly over time.

--
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/

Rainer Weikusat

2008-01-25, 8:19 am

John Tsiombikas <nuclear@siggraph.org> writes:
> On 2008-01-24, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> ... [snip] ...
>
> The PIT is an entirely different story, as you said it has nothing to do
> with the RTC. It's a reliable and compatible timer interrupt source,
> used almost universally on the PC platform, unless there is a better one
> available like the HPET, which IIRC is only available on *very* recent
> intel processors only.
>
> the TSC (timestamp counter) is NOT a good timing source, and it doesn't
> generate interrupts which is essential for any OS's timing needs.

You should have read the code instead of just deleting it. Its
function is to read the current counter value from this chip to
determine the fractional parts of 'the current time' with a higher
precision than the system clock has. This is comletely useless for
calls to time, because the granularity of the result is in seconds,
but nevertheless done because the time system call, if there is any,
is (for Linux 2.6.23 and the OpenBSD version accessible via OBSD CVS)
implemented on top of gettimeofday, which (in theory) has microsecond
precision, although no specific precsision is required (AFAIK) by the
UNIX-specification (and I had assumed that people implementing this
would just return the value with the system clock precision, because
that would be faster).

On Linux, the TSC is actually used to provide the same function, if it
is usable, the respective code is in arch/i386/tsc.c

John Tsiombikas

2008-01-25, 8:19 am

On 2008-01-25, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> John Tsiombikas <nuclear@siggraph.org> writes:
>
> You should have read the code instead of just deleting it. Its
> function is to read the current counter value from this chip to
> determine the fractional parts of 'the current time' with a higher
> precision than the system clock has.

Your previous statement that compared TSC with the PIT, suggested that
you think TSC would be a suitable alternative to PIT, which it clearly
isn't and that's what I pointed out. I didn't say it's useless, I just
said it's not a timing source. If the OS can find a way to use it
reliably to correct fractional parts of seconds or whatnot, that's fine.

> On Linux, the TSC is actually used to provide the same function, if it
> is usable, the respective code is in arch/i386/tsc.c

Not on SMP systems, and not if the CPU frequency changes dynamically, as
I already said.

--
John Tsiombikas (Nuclear / Mindlapse)
http://nuclear.sdf-eu.org/

Rainer Weikusat

2008-01-25, 8:19 am

John Tsiombikas <nuclear@siggraph.org> writes:
> On 2008-01-25, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
> Your previous statement that compared TSC with the PIT, suggested that
> you think TSC would be a suitable alternative to PIT,

That you complelely missed the context of this disucssion, which was
NOT about generating timer interrupts, but about how the value
returned by time (and other 'get the time' routines) is determined,
suggest exactly nothing about me.

> which it clearly
> isn't and that's what I pointed out. I didn't say it's useless, I just
> said it's not a timing source. If the OS can find a way to use it
> reliably to correct fractional parts of seconds or whatnot, that's fine.
>
>
> Not on SMP systems, and not if the CPU frequency changes dynamically, as
> I already said.

Which part of 'if it is usable' managed to whizz by you?

Sponsored Links