home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / apps / 4657 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.2 KB
  1. Xref: sparky comp.os.msdos.apps:4657 comp.bbs.waffle:2238
  2. Path: sparky!uunet!mcsun!sun4nl!alchemy!accucx!nevries
  3. From: nevries@accucx.cc.ruu.nl (Nico E de Vries)
  4. Newsgroups: comp.os.msdos.apps,comp.bbs.waffle
  5. Subject: Re: Stacker's TRUE compression ratio
  6. Message-ID: <3046@accucx.cc.ruu.nl>
  7. Date: 7 Sep 92 21:16:32 GMT
  8. References: <2TXmqB3w165w@infopls.chi.il.us>
  9. Followup-To: comp.os.msdos.apps
  10. Organization: Academic Computer Centre Utrecht
  11. Lines: 56
  12.  
  13. In <2TXmqB3w165w@infopls.chi.il.us> andyross@infopls.chi.il.us (Andrew Rossmann) writes:
  14.  
  15. >   I've been using Stacker for my Waffle news spool for around a month or
  16. >so now.  I had posted that at that time, SCHECK was showing a 1.4:1 ratio.
  17. >That has now increased to 2.4:1.
  18.  
  19. >   At first, this sounds nice, but I've been wondering just how good it's
  20. >really working.  Due to the small size of the posts, I've been using 4K
  21. >clusters.  My STACVOL is 60M.  SCHECK shows 81,457,152 bytes allocated, but
  22. >stored in 34,096,128 bytes.  Using 4DOS 4.01, I did 'DIR E:\ /S/U', which
  23. >gave me the total TRUE file size, and the total allocation size.  This gave
  24. >me 39,677,349 bytes in files, allocated to 79,622,144 bytes.  CHKDSK showed
  25. >1,830,912 bytes in 340 directories (which I presume are not compressed.)
  26.  
  27. >   If I take the total true size + what's allocated for directory entries,
  28. >I get 41,508,261 bytes.  If I divide that by the 34,096,128 bytes that are
  29. >used in my STACVOL, I get a meager 1.22:1 ratio.
  30.  
  31. This is tough to understand but I'll give it a shot.
  32.  
  33. Stacker uses basically 2 techniques to save disk space. The first one is data
  34. compression (see comp.compression FAQ for more info on that subject), the
  35. second one is using smaller "microclusters" for storing the compressed file.
  36.  
  37. The compression saves space by making the data need less disk space. The
  38. microclusters by reducing the slack (unused parts of clusters).
  39.  
  40. The larger a file is the better it is to compress it. This has to
  41. do with the chance of repeated strings in the data which is one of
  42. the properties of data used by most data compressors. For large files
  43. therefore a better ratio is possible. 
  44.  
  45. For small files the microclusters will do a lot of usefull work. E.g. a
  46. 1 byte file can take up to 1:16th of its origional space.
  47.  
  48. This also means your measurements are relative. If a lot of small files
  49. is checked for their compression ratio it will of cource be bad, nevertheless
  50. the saved space will be significant due to the microclusters.
  51.  
  52. Now for the expected figures. Unlike most computer companies the
  53. gues at Stac, IIT, SuperStor etc are not excadurating. For an basic
  54. harddisk 1:2 compression is quite normal. For lots of small files,
  55. and/or large databases etc 1:4 compression is not uncommon. Does the
  56. harddisk contain lots of .ARC .ARJ .ZOO etc files (compressed ones)
  57. than the ratio will get lower because compressed files can not
  58. be recompressed.
  59.  
  60. >Andrew Rossmann            | Sysop of Infoplus BBS, +1 708 537 0247
  61.  
  62.  
  63. Nico E. de Vries
  64. _ _
  65. O O  USENET nevries@cc.ruu.nl  FIDO 2:281/708.1  COMPUSERVE ^%#$*%^ 
  66.  o   This text reflects MY opinions, not that of my employer BITECH.      
  67. \_/  This text is supplied 'AS IS', no waranties of any kind apply.      
  68.      Don't waste your time on complaining about my hopeless typostyle.
  69.