Ratio tab change

Archived discussion about features (predating the use of Bugzilla as a bug and feature tracker)

Moderator: Moderators

Locked
Cyborg
Posts: 41
Joined: 2004-01-23 18:15

Ratio tab change

Post by Cyborg » 2004-05-13 23:51

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?

Wisp
Posts: 218
Joined: 2003-04-01 10:58

Re: Ratio tab change

Post by Wisp » 2004-05-14 04:05

0.98 should be 2% compression

I think that would be better indeed

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Re: Ratio tab change

Post by GargoyleMT » 2004-05-16 15:51

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?
I've not seen this in practice.

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.

Cyborg
Posts: 41
Joined: 2004-01-23 18:15

Post by Cyborg » 2004-05-16 23:43

The ratio has been up to 1.70 at my client once (that i noticed). I've seen it at about 1.01 several times.

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-05-17 00:07

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%.

PseudonympH
Forum Moderator
Posts: 366
Joined: 2004-03-06 02:46

Post by PseudonympH » 2004-05-17 21:02

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.

Locked