title: What can be the least possible value of data-compression-ratio for any real dataset
body: <p>I am writing <code>ZLIB</code> like API for an embedded hardware compressor which uses deflate algorithm for compression of given input stream.</p>
  
  <p>Before going further i would like to explain data compression ratio. Data compression ratio is defined as the ratio between the uncompressed size and compressed size.</p>
  
  <p><img src="https://i.stack.imgur.com/Pl2Km.png" alt="enter image description here"></p>
  
  <p>Compression ratio is usually greater than one. which mean compressed data is usually smaller than uncompressed data, which is whole point to do compression. but this is not always the case. for example using <code>ZLIB</code> library and pseudo-random data generated on some Linux machine give compression ratio of 0.996 roughly. which mean 9960 bytes compressed into 10000 bytes.</p>
  
  <p>I know <code>ZLIB</code> handle this situation by using type 0 block where it simply return original uncompressed data with roughly 5 byte header so it give only 5 byte overhead up to 64KB data-block. This is intelligent solution of this problem but for some reason i can not use this in my API. I must have to provide extra safe space in advance to handle this situation.</p>
  
  <p>Now if i know the least possible known data compression ratio it would be easy for me to calculate the extra space i have to provide. Otherwise to be safe, i have to provide more than needed extra space which can be crucial in embedded system.</p>
  
  <p>While calculating data compression ratio, i am not concerned with header,footer,extremely small dataset and system specific details as i am separately handling that. What i am particularly interested in, is there exist any real dataset with minimum size of 1K and which can provide compression ratio less than <code>0.99</code> using deflate algorithm.  In that case calculation would be:<br>
  Compression ratio = uncompressed size/(compressed size using deflate excluding header,footer and system specific overhead)</p>
  
  <p>Please provide feedback. Any help would be appreciated. It would be great if reference to such dataset could be provided.</p>
  
  <p><strong>EDIT:</strong><br>
  @MSalters comment indicate that hardware compressor is not following deflate specification properly and this can be a bug in microcode.</p>