Subj : Re: ZLIB compression
To   : Maurice Kinal
From : Michiel Broek
Date : Fri Jun 17 2005 12:43 am

Hi Maurice,

Maurice Kinal wrote to Michiel Broek:
MK> Hey Michiel!
MK> 
MK> Jun 15 20:39 05, Michiel Broek wrote to Maurice Kinal:
MK> 
MK>  MB> True, and also saves bandwidth on larger filehubs.
MK> 
MK> Good point.  I imagine it would.
MK> 
MK>  MB> The larger the file the better of course. Iso files have a mixed
MK>  MB> improvement, it just depends what is on the iso.
MK> 
MK> Just regular data iso's here.  Nothing fancy.  :-)

Most data is compressed?

MK>  MB> around 2 kbytes. We do this to avoid sending very small blocks which 
MK>  MB> would
MK>  MB> cause extra overhead. As a failsave we never read a block larger then 

MK>  MB> the
MK>  MB> maximum binkp blocksize which is with this method 16 kb.
MK> 
MK> Sounds good.  Maybe I'll play with that a tad but we'll see.

Now I'm trying to figure out how the binkd version of compression is done.

MK>  MB> The disadvantage of our scheme is that bzip compression is useless 
MK>  MB> since
MK>  MB> that only works good on large files.
MK> 
MK> I don't use bzip myself.  I have it onboard when downloading those files 
MK> but have been sticking to gzip locally.  I am thinking about doing the 
MK> online messaging that way for both reading and writing.  Outbounds would 
MK> be normal Fido pkt's of course.  Might even do offline messaging that way. 

MK>  We'll see when I get there.  :-)

It saves some additional space, but files have to be at least 100k to let
bzip2 win over gzip. With the current mailvolume that might be hard to
reach.




    Greetings, Michiel Broek

Email:   mbse@mbse.dds.nl
Fidonet: Michiel Broek at 2:280/2802

.... Not quite human any longer.

--- MBSE BBS v0.71.3 (GNU/Linux-i386)
 * Origin: MBSE Linux BBS. Made in the Netherlands (2:280/2802)

.