Dantz has being supporting Retrospect since the days when backups were
done to stacks of diskettes (and NOT 2HD either). The issue of compression
efficiency has been agonized over almost as much as Peace in the Middle East.
A number of years ago the tape industry finally arrived at a gentleman's
agreement that a nominal compression ratio of 2:1 was a "fair" marketing
claim for all vendors and that they should stop playing one-upmanship
by benchmarking on files which were decreasingly representative of
real world data but rather were selected to give the highest compression ratios.
As for the matter of V.42bis compression being 4:1 or some other fixed ratio,
it's a case, again, of varying mileage. Text happens to be particularly easy
to compress due to frequency of letter repetition, white space and the fact
the ASCII character set fills only half of the available 0-255 symbols in 8 bit
data bytes...yada yada yada...
...wait a minute. Several people have taken the time to try to convince you that
both Dantz and the tape drive vendors have done diligence in this matter.
It's time for a trip to the library. There is some really profound reading
available on Information Science's fraternal twin offspring, data compression and
cryptography.
Regarding the former I recommend:
The Data Compression Book by Mark Nelson ISBN 1558514341
Regarding the latter (this one is a historical thriller circa WWII)
Between Silk and Cyanide by Leo Marks ISBN 068486780X
The second book will reward you for absorbing any part of the first
and is a very good read even if information science is not your idea
entertainment.
Doug.
>Ok, explain to me...I took a 220MB system file and compressed it down to 28MB.
>
>Obviously this is lossless as I can recover individual files from within it that are
>things like extensions, fonts, etc.
>
>I admit, JPEG, MPEG, etc. are lossful, but modems have been doing v.42bis compression
>which is 4:1 on the fly for a long time now. Granted, the speed is only 53k at best
>(although some faster network equipment also uses a subset of v.42bis), so the time
>frame from receiving to sending would be larger that you would get with receiving to
>sending to local device like a tape drive.
>
>I'm wondering if it would be possible for Retrospect to do some software compression
>that may be slower, but would allow greater inline compression. I would guess that
>the software compression built into Retrospect is the same algorythem that hardware
>compression drives use. By getting with a company like Alladin Systems, it would
>seem like they could improve on that technology.
>
>If Dantz did something like this, obviously having a choice of Hardware compression
>or software compression would still be there, but adding to the software compression
>may be 3 levels. Normal, Better (slower), Best (slowest).
>
>The speed of the compression would depend heavily on the speed of the CPU doing the
>backups. So if I had my Dual 1Ghz Processor Alpha box running NT doing backups, the
>best compression would be barely noticeable performance hit.
>
>I do think that if Dantz should at least talk to someone at Alladin about it.
>
>8?)
>
>
>>One (compound) word: Lossless
>>
>>The compression methods that you are lusting after introduce errors
>>(artifacts) into the resulting decompressed data. This may be acceptable
>>for sound, photos and video but to totally unacceptable for storage of
>>system files, programs and most other data.
>
>
>
>--
>----------------------------------------------------------
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Archives: <http://list.working-dogs.com/lists/retro-talk/>
>
>For urgent issues, please contact Dantz technical support directly at
>[EMAIL PROTECTED] or 925.253.3050.
--
----------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://list.working-dogs.com/lists/retro-talk/>
For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.
