[Top] [All Lists]

Re: compressed content-transfer-encoding?

1999-08-01 11:06:26
I don't know about you, but in my experience, modem compression (and  
similar schemes) typically does a fairly poor job.

There's a fairly simple reason. This type of compression must keep  
latencies from growing too much. This *really* hurts compression.

actually my experience is just the opposite ... modem compression
(usually based on LZW) does a reasonably good job ... not as good
as gzip or bz2 but close enough.   and yes, one difference between
the effectiveness of these algorithms is the amount of latency/
lookahead that is needed.  LZW is amazingly good for an algorithm
needing only a fixed amount of memory and one octet lookahead.

but for me the disappointing thing about modems is that they add far 
more latency than you would expect given their speed.  I don't think 
this is the fault of the compression so much as the error correction
(I suspect that many modems rely on error correction to compensate 
for marginal analog circuitry)

you'll get more connection time savings from pipelining smtp than you
will from compressing the data.

That's only true if the time is dominated by RCPT TO: handling, that is,  
you're sending many small mails. When you're sending a few large mails,  
pipelining is completely irrelevant, and compression is very important,  
because you spend most of the time in the DATA phase anyway.

right.  but even these days most messages are small.  and I was assuming 
that this traffic was already going over compressing modems, which would 
save almost as much bandwidth as compressing smtp data.