> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] 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" <[email protected]> writes: > > >> -----Original Message----- > >> From: [email protected] [mailto:rsyslog- > >> [email protected]] 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<[email protected]> 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
