I've recently done a multi-site upgrade from GW7 to GW8, and
unfortunately only at the same time turned on the config to have senders
get "delayed" status messages (in the past, they only got the
complete-failure notification.) So I'd have to dig *way* back in logs
to know if I have a problem or not ....

We're receiving more-than-usual, since "usual" in the past was "none",
TCP Read Errors with sending delays. I interpret this as either not
enough threads allocated for sending, or possibly an error on the part
of the ISP in how many connections we can make concurrently (as the GW
docs say that if multiple messages are being processed concurrently,
each uses one connection ... and then we are going through the same
gateway as all the internet users in the office.)

The level is in the range of 30 TCP status (delayed) messages for
perhaps 2000 sent. But it still makes people gripe. They gripe if they
don't know messages are delayed, and they gripe when they do know. They
even gripe when a message is bounced by someone *else's* server because
they've tacked on some humongous attachment and the recipient's server
doesn't allow attachments that large. They're a pretty gripe-y bunch
when it comes to email, in fact, because they have to send large
attachments all the time & they almost always (incorrectly) think the
error is on the sending side ... because, as y'all know, the status info
comes from the sender's server. [I have had to repeat, at least 20
times in past weeks including office-wide emails, that there is no
outbound filtering or size limit imposed.]

Which is to say: do I have a problem at this level of delay? Can I fix
it by allocating more threads? Should I be checking into how many
connections the ISP allows? Should I take it as good fortune that the
level is that low? As far as my users are concerned, 1.5% delayed is
too much!

This is on a Netware 6.5 SP8 server, 4GB memory, dual Xeon, nice & fast,
not doing anything of significance except the various components of
Groupwise and, of course, the tape backup and UPS agents. (Whew, that
UPS agent tends to suck up resources, but that's another gripe altogether.)



-- DE