Hey..
I think the Ratio tab should be renamed to "Compression" and when compression is off, it should display "Off" else it should display (for example) 98% instead of 0.98 etc...
Also...Is it possible to prevent the compression ratio of getting above 1?
Lets say dc++ compresses a part of the file before sending...Could you make it check so that it'll take the original part if the compressed one is larger?
Ratio tab change
Moderator: Moderators
Re: Ratio tab change
0.98 should be 2% compression
I think that would be better indeed
I think that would be better indeed
-
- DC++ Contributor
- Posts: 3212
- Joined: 2003-01-07 21:46
- Location: .pa.us
Re: Ratio tab change
I've not seen this in practice.Cyborg wrote:Also...Is it possible to prevent the compression ratio of getting above 1?
Lets say dc++ compresses a part of the file before sending...Could you make it check so that it'll take the original part if the compressed one is larger?
There's some overhead, but even on my client, which is limiting uploads and is using a very small block size, I've not seen anything above 1.00. Furthermore, DC++ will check if the file is compressable, so if the beginning of the requested range of the file doesn't compress well, DC++ will set the compressor to its lowest level. On this level, you still get the Addler32 checksum, to detect corruption in the transfer.
http://www.gzip.org/zlib/zlib_tech.html wrote:In the worst possible case, where all other block types would expand the data, deflation falls back to stored (uncompressed) blocks. Thus the only expansion is an overhead of 5 bytes per 32 KB block (.02%), plus a one-time overhead of six bytes for the entire stream. In the absolute worst case of a single-byte input stream, the overhead therefore amounts to 1100% (11 bytes of overhead, 1 byte of actual data). For larger stream sizes, the overhead approaches the limiting value of .02%.
-
- Forum Moderator
- Posts: 366
- Joined: 2004-03-06 02:46
I believe the 1.70 ratio is caused by the same thing that causes the ratio for uploads to start at around .25 for uploads that are starting at the beginning of the file. The ratio seems to be counting received bytes and bytes read into the buffer. For uploads, it loads around 64k into the buffer at the start, but will only have uploaded around 16k of actual data. For downloads, it will have gotten, say 100k of compressed data, but since the zlib buffer is 64k, only 64k of that will have been counted as actually downloaded. I personally think that it should show the ratio for the current block only (total compressed size for block / total uncompressed size (64k in almost all circumstances)), but other people might not agree with me.