Disabling (part of the) timers ?

[Christiaan den Besten]

Hi !

Sorry for that, meant to reply to the list .....

Just updated to STABLE-20050608, but I am still seeing "Jun  9 02:07:57 spool8 nnrpd[29749]: cache6.multikabel.net time 32740 idle 
12561(15) readart 101(14) nntpwrite 19867(59)" in my log. So the timers are not diabled are they?

--
[root at spool8 etc]# grep timer inn.conf
timer:                  0
[root at spool8 etc]#
--

That is what you meant to disable the timers right ?

bye,
Chris

PS: OS is Linux ia32, Fedora Core 3.

----- Original Message ----- 
From: "Russ Allbery" <rra at stanford.edu>
To: <inn-workers at isc.org>
Sent: Tuesday, June 07, 2005 8:52 PM
Subject: Re: Disabling (part of the) timers ?


(Please reply to the mailing list rather than to me individually.
Thanks!)

Christiaan den Besten <chris at prolocation.net> writes:

> The first time I 'notices' the 'timers' were using more CPU than
> estimated was when Heith patched (as a request) the ovdb_server with the
> same 'timers' to see where it was spending its time. The server could
> barely serve more than 350mbit of feed (towards clients). After removing
> the timers again, we had no problem reaching 450mbit. So I decided to
> remove the timer from nnrpd and decrease the client-timeout check a
> factor (i++; if i>100 (now = time (); check possible timeout value;
> i=0)) etc... This did seem to decrease the CPU load.

> But you think we should have less overhead from all these 'gettimeofday'
> syscalls. nnrpd does a gettimeofday after each read/write sequence by
> default ... With 1000+ nnrpd's running probably makes some sence ?

It really shouldn't make a difference.  If it is making a difference,
that's really a problem with your OS, I think, although some OSes
admittedly do have slow system calls.  Tons of stuff uses gettimeofday.

That being said, I did incorporate a patch into STABLE and CURRENT that
would let you turn off the timer for nnrpd as well in inn.conf.

> PS: Are the patches for CNFS_BLOCKSIZE integrated into 2.4-STABLE or
> 2.4-CURRENT ? (or both or none ?).

If you're talking about the patch that zero-fills writes to CNFS_BLOCKSIZE
boundaries, it's in both STABLE and CURRENT.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>