Howdy, Well, from looking @ the patch I can't see much delay: - The code is bigger and a little more slower, if it is 0.001 of a second slower(in the CPUs nowadays), in a system with 1000 msgs/seg it will have a 3 seconds (store, local, remote) delay.... so why bother. - What this patch does is allow for a bigger qmail queue, which IMHO is the best.
I don't see what's the point in this discussion because qmail is not CPU intensive, but a I/O intensive... soo loosing seconds in messages that take sometimes 1 hour of delay is somewhat of a ">/dev/null", IMHO. My Euro, Rui Lapa PS: Not exact values, and not considering external conditions On Fri, 2001-09-28 at 06:52, Henning Brauer wrote: > [Franky, where did your linewrapping get lost?] > > On Thu, Sep 27, 2001 at 10:05:25PM +0200, Franky Van Liedekerke wrote: > > I experienced the same problem, and no, the big-todo patch won't help you > > a bit. > > In the situation the previous poster described it whould help. > We won't know it for sure until he tries it ;-)) > > > What I did, and what I recommend to everyone, is that you buy a SCSI > > controller that has at least 64MB NVRAM cache on it (and preferably > > 128MB) with battery-backup. This results in mails being processed *much* > > quicker, > > Another possibility is using a solid state disk. This thingy needs a battery > backup too, of course. Usually your queue disk should not need to be too > big, a ssd is an option here. > > Greetz > > Henning > > -- > * Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de * > * BS Web Services, Roedingsmarkt 14, 20459 Hamburg, Germany * > Unix is very simple, but it takes a genius to understand the simplicity. > (Dennis Ritchie) > -- --------------------------------------------------------------- Rui Lapa DeSCT-OniSolutions [EMAIL PROTECTED] Fingerprint: 4C8F 2593 6813 55F5 8FA1 74B7 245F 9138 1C02 9331 ---------------------------------------------------------------
