[rsyslog] high-performance, low-precision time API under linux?

[Rainer Gerhards]

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Jeff Moyer
> Sent: Monday, June 15, 2009 5:13 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] high-performance, low-precision time API under
linux?
> 
> "Rainer Gerhards" <rgerhards at hq.adiscon.com> writes:
> 
> >> -----Original Message-----
> >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> >> bounces at lists.adiscon.com] On Behalf Of Aaron Wiebe
> >> Sent: Monday, June 15, 2009 4:56 PM
> >> To: rsyslog-users
> >> Subject: Re: [rsyslog] high-performance, low-precision time API under
> > linux?
> >>
> >> I'm slightly confused - whats wrong with gettimeofday()?  It may be
> >> higher precision, but it still
> >> gives you the ability to find the nearest second with a few extra
> > operations.
> >>
> >> -Aaron
> >
> > Much too slow. For example, you can often write a sector quicker to disk
> than
> > gettimeofday() returns...
> 
> Really?  That doesn't sound right to me.  Writing a sector to disk can
> take 8ms or more.  One would hope gettimeofday would be faster than
> that, given that it reports microseconds.  ;)  The exact resolution, of
> course, depends on how your kernel is configured.  Here are the
> measurements (in CPU cycles) I get running each call (time(NULL) and
> gettimeofday(&tv, NULL)) 1000 times:
> 
> $ ./some-cycle-costs
>                                     fewest cycles  avg cycles
> syscall(NR_time)                    2134           2721.99
> syscall(NR_gettimeofday)            2156           2622.87

I've updated the blog post with my test program and some numbers:

http://blog.gerhards.net/2009/06/high-peformance-low-precision-time-api.html

(sorry for keeping this on the blog, but that makes it far easier to also ask
at other places...)

> If I understand your original question properly, you don't need to
> always have a timer running.  You can only schedule a timer when there
> is I/O buffered.  I'm not sure whether your code lends itself to that or
> not.

The code in question would not just be used for buffered writes. The problem
is also that I need to frequently re-set the timer, because it must not write
data if any new has arrived. In order to do this re-set handling properly, I
also need to know the system time.

Of course, I can schedule a specific timer while data is unwritten. But that
is just another tick processing if I don't reset the timer when there is no
need. But... all suggestions are welcome. The overall idea is that I would
like to implement something like the original callouot table. However,
callout worked on a tick. I intended to replace that with timers (more
precisely their pthreads-equivalent, which would give me some aids in awaking
the system in unexpected cases). That was the plan, but I overlooked that it
required many of the costly time() calls.

Rainer

> I would be interested in hearing more about what conditions cause
> gettimeofday to be so slow.
> 
> Cheers,
> Jeff
> 
> >> On Mon, Jun 15, 2009 at 10:48 AM, Rainer
> >> Gerhards<rgerhards at hq.adiscon.com> wrote:
> >> > Hi all,
> >> >
> >> > I am having a hard time finding a suitable-fast but tickles solution
to
> >> > obtaining low-precision time API under Linux. Please read here:
> >> >
> >> >
> >
http://blog.gerhards.net/2009/06/high-peformance-low-precision-time-api.html
> >> >
> >> > If I don't find a better solution, I'll probably be forced to run
> > rsyslogd
> >> on
> >> > a tick, which would not be a good thing from a power consumption point
of
> >> > view.
> >> >
> >> > Comments and suggestions are highly appreciated.
> >> >
> >> > Thanks,
> >> > Rainer
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com