[Tfug] Linux kernel tcp delay options

[Bexley Hall]

Hi Adrian,

>>> opening a folder on mdir with 20k+
>>> messages starts to slow down considerably, about 24sec on a 101k message
>>> folder just to read and process the index in Kmail.
>>
>> Have you tried other clients to see if the delays are comparable?
>
> Part of this is also the process of moving everything off my old laptop onto a
> new one... But I don't want to store everything on my new laptop until Ive
> configured the new the way I want. Im looking at possibly trying Sylpheed,
> but I generally haven't liked other clients (I want a mail client, plain and
> simple, not a contact/IM/etc manager).

Agreed.  I was just thinking you might try accessing the server
from another OTS box just to see what the performance differences
might be (given that you can do some operations without altering
the contents irreparably).

>>> Trying to upload off my
>>> laptop mailstore to Cyrus, I'm only getting 15-20msg/sec transfer rate
>>> with minimal CPU and bandwidth usage on both sides, no I/O waits evident
>>> on the server, seems to be purely some sort of TCP delay (~3ms away from
>>> the server).
>>
>> So, the times for connecting to Cyrus are orders of magnitude slower
>> than accesses on the mailstore local to your laptop (using the same
>> client?)  Or, are you comparing apples and orangutans, here?
>> ("read and process the index" vs. "upload (message bodies) off my
>> laptop")
>
> Yes apples to oranges, but the first step is to actually get the mail copied
> to another store. Then I can compare different clients/access methods against
> the same store.

Understood.  I was trying to clarify that you were, in fact, doing
two different types of operations.

In particular, I wonder if the "message transfer" (body/header)
might be happening as a series of individual "transactions".
I.e., the client setting up a connection for a *single* transfer;
then, tearing it down and starting all over for the *next*
transfer!  This could explain a bit of the delay you are
seeing...

(Admittedly, this sounds inefficient but I've seen stranger things coded
up!  :-/ )

--don