Text 282, 80 rader
Skriven 2005-06-15 20:39:59 av Michiel Broek (2:280/2802)
    Kommentar till text 281 av Maurice Kinal (1:340/401.1)
Ärende: Re: ZLIB compression
============================
Hi Maurice,

Maurice Kinal wrote to Michiel Broek:
MK> Hey Michiel!
MK> 
MK> Jun 14 20:54 05, Michiel Broek wrote to Maurice Kinal:
MK> 
MK>  MB> For small pkts it doesn't help much, the the time is spent on opening 

MK>  MB> the
MK>  MB> file and removing it from the outbound.
MK> 
MK> Right.  However the actual processing time isn't costing the dialups so 
MK> even if that time is increased it really doesn't matter when compared to 
MK> the transfer times.  If gzipping does indead lower transfer times then it 
MK> is worth it simply due to economics.

True, and also saves bandwidth on larger filehubs.

MK>  MB> It speeds things up on a lan too, but it will depend on the cpu power 

MK>  MB> too.
MK> 
MK> Somewhat true.  Makes no difference if all the cpu's on the network are 
MK> faster then the connection though.
MK> 
MK>  MB> mbcico[27760] Binkp: receive file "FSP-1018.002" date Jun 07 03:28:01 

MK>  MB>   size 83568 offset 0
MK>  MB> mbcico[27760] Binkp: compressed 59899 bytes, compression 71.7%
MK>  MB> mbcico[27760] Binkp: OK 83568 bytes received in 0.299 seconds 
MK>  MB> (272.941 Kb/s)
MK> 
MK> That is pretty good.  I am going to try transferring a fullblown iso over 

Normal compressed files look around 80 Kbs.

MK> the LAN via ftp and binkd and see how that compares.  Also will try your 
MK> above experiment with plain text and then compressed between two binkd 
MK> machines but will try with a HUGE text file.  Obviously there will be a 
MK> noticeable difference on the latter experiment but I'd like to see what 
MK> difference there will be to the overall speed when the target has to 
MK> ungzip it later.  I think with a HUGE file the total time (including the 
MK> uncompression time) should prove to be favourable.  Offhand I think adding 

MK> compression abilties to binkd is a good idea, nevermind just dialups.

The larger the file the better of course. Iso files have a mixed
improvement, it just depends what is on the iso. I tried these too on the
lan and because the compression we use adapts itself to the compression you
can see in debug mode how it works during long transfers. What we do is
based on the compression rate of the last block transmitted we increase the
blocksizeread from disk so that the average blocksize on the line remains
around 2 kbytes. We do this to avoid sending very small blocks which would
cause extra overhead. As a failsave we never read a block larger then the
maximum binkp blocksize which is with this method 16 kb.

This is different then the compression build in binkd, I think that one just
send one file compressed and another not, that depends on a table file
filename patterns. Our scheme always tries to compress and sends the
smallest possible block and marks the state of that block so the receiver
"knows" if it must decompress or not.

The disadvantage of our scheme is that bzip compression is useless since
that only works good on large files.






    Greetings, Michiel Broek

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

... A grenade with a seven second fuse will always burn down in four seconds.

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