Dynamic Rubin compression performance in JFFS2 on iPAQ

[Christian, Andrew]

We recently updated the iPAQ bootldr (version 2.15.0 on  www.handhelds.org)
to support booting the kernel out of JFFS2.  In the process of doing this,
we ran into difficulties uncompressing kernel images from non-sorted lists
of file fragments - in particular, we had troubles with DYNRUBIN
decompression.

That caused us to look at the benefits of the different compression
algorithms in JFFS2.  On a typical iPAQ with approximately 45 Mbytes of
uncompressed data, we see the following numbers:
				
        Fragments	    Compressed Uncompressed   Saved     Saved
				(bytes)     (bytes)    (bytes)     (%)

NONE          813         248473      248473          0      0%   
ZLIB        12287       20886586    46882145   25995559     55%   	
DYNRUBIN       70	         20864       21490        626	 3%
RTIME           5	            94         115         21     18%

Total       13175       21156017    47152223   25996206     55%

These numbers are representative of the different iPAQs we tested - in fact,
DYNRUBIN in this iPAQ saved the most bytes of any of the tested iPAQS.

Including DYNRUBIN compression in the iPAQ Linux kernel requires an
additional 5793 bytes (a compressed zImage) 

For the moment, we have added a CONFIG option to turn off DYNRUBIN
compression for iPAQs --- decompression is left turned on for backward
compatibility.

We're curious - what is the intended target of DYNRUBIN compression?  We
haven't seen any advantages from including it on the iPAQ, but it must be
advantageous for some system or data type.  Anyone?


	Brian Avery		<brian.avery at compaq.com>
	Andrew Christian	<andrew.christian at compaq.com>


Compaq Computer Corporation
Cambridge Research Laboratory