> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Aaron Wiebe > Sent: Monday, June 15, 2009 5:36 PM > To: rsyslog-users > Subject: Re: [rsyslog] high-performance, low-precision time API under linux? > > As more followup... > > I would suggest running a timer per thread. I assume every thread > would contain some type of > event-trigger loop, and I would make your timer calls in that loop, > caching for the remainder of > that iteration. I'm not quite sure how well this would work, but you > can most certainly get away > with a fair bit of drift, especially if high-precision timers are not > required for log output.
But that makes me running on that tick... (more below) > > -Aaron > > On Mon, Jun 15, 2009 at 11:32 AM, Aaron Wiebe<[email protected]> wrote: > > I went over your post... > > > > You shouldn't be seeing a 4ms response time on a gettimeofday() call - > > this is my test: > > > > gettimeofday({1245079355, 445434}, NULL) = 0 <0.000004> > > gettimeofday({1245079355, 445503}, NULL) = 0 <0.000004> > > gettimeofday({1245079355, 445560}, NULL) = 0 <0.000003> > > gettimeofday({1245079355, 445629}, NULL) = 0 <0.000004> > > > > That's 3-4 microseconds. Oops, sorry, yes, that is what I meant... > > For the sake of argument, I checked time() as well, which is obsoleted > > by gettimeofday()... > > > > ime(NULL) = 1245079501 <0.000008> > > time(NULL) = 1245079501 <0.000007> > > time(NULL) = 1245079501 <0.000004> > > time(NULL) = 1245079501 <0.000008> > > time(NULL) = 1245079501 <0.000004> > > > > About half the speed, but still in the microsecond range. > > > > gettimeofday() is one of the fastest syscalls you can issue. > > Obviously you don't want to beat on it, but I wouldn't worry about > > calling it a few dozen times per second. It's not about a few dozen times. I need to re-set the timer when I logically write something to the file. The problem is that I don't know how long it was since I did this the last time. So I would end up with calling time once per logical write, that is a in the range of tenthousand to hunderedthousand times per second. A solution for this case may be to not reset any started timer and simply let it fire whenever that be. So if there is a time started, don't care about the other writes but do this only once the timer is done. That, of course, comes at the cost of thread synchronization. Again, atomics may help here. And while it is tempting to assume atomic writes for simple 32 bit values, this is not always the case. So in the extreme case, and without (reliable) atomics, one may end up with timers not being started where they should be. Using sync primitives, however, is also very costly... Rainer > > > > -Aaron > > > _______________________________________________ > 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
