To: djb@koobera.math.uic.edu (D. J. Bernstein)
Cc: drums@cs.utk.edu
Subject: Re: proposed agenda for 8 March WG meeting 
In-Reply-To: Your message of "05 Mar 1996 15:31:14 GMT."
             <19960305153114.4101.qmail@koobera.math.uic.edu> 
Date: Wed, 06 Mar 1996 02:45:25 +1100
Message-Id: <1051.826040725@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        5 Mar 1996 15:31:14 GMT
    From:        djb@koobera.math.uic.edu (D. J. Bernstein)
    Message-ID:  <19960305153114.4101.qmail@koobera.math.uic.edu>

    My 14.4k and 56k lines, however, are wonderful testbeds. Everyone who
    has actually tried this out rather than shouting ``That's ridiculous!''
    has come to the same conclusion.

There's no question, parallelising mail delivery certainly
speeds it up over doing everything serially, I do that where
it really helps (that is, where the difference is measureable
without a stop watch).

However, I'd certainly never run connections in parallel in
order to avoid a RCPT delay, even without pipelining.  Sure, you
may improve latency by a few seconds (per recipient), or so, but
to do that you duplicate the whole message content.  That's insane,
and a totally stupid waste of bandwidth.  The gain isn't worth
the cost.   You probably don't notice it much when there's no per
byte (or packet) costing, and as long as you stay within your
pipe's bandwidth (you will certainly slow delivery if you overload
your thin pipe with dozens of duplicate copies of the same message
body in order to save dozens of serial RCPT commands).

kre