The best "overall" compression I've ever seen has been about 1.5:1. That is,
a file that was 3 MB in size now is only 2 MB. Sure, I've seen better (and
worse), but on average, for the contents of a typical hard disk, compression
probably will be somewhere around 1.5:1. At least that's been my experience.
Please don't ask me to actually define "typical"...

Even PKZIP's EXTRA compression ("-ex") doesn't do much (if any) better than
it's standard compression option. But, the EXTRA compression can take
several times longer for only  a few % difference in .ZIP size from standard
compression. You gotta be really desperate to want to use the EXTRA

But that's way beside my point, and not beside my point. The thrust of my
argument is this: networks are slower than CPUs and hard disks. Somewhat
compressing the data (and not sacrificing the streaming of data to the
server) before sending it across a relatively slow link (even 100 Mb is
relatively slow compared to hard disk transfers) will almost assuredly
provide performance improvements. Fantastic compression is not required at
the workstation - just something.

I suppose that because the data stream were already slightly compressed, the
tape drive's hardware could possibly do very little or no compression. I
suppose also that as an alternative to shipping the compressed data stream
to the tape drive, the server could take the compressed data stream,
decompress it, then send it to the tape drive for the more traditional whack
at compression. My servers have gobs of CPU cycles just waiting to be put to
good use.

I'm sure Dantz could work out the details.


-----Original Message-----
From: matt barkdull [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 26, 2001 12:52 PM
To: retro-talk
Subject: RE: Transfer Rates - Dantz Help?

A month or so ago I wrote a rant about how Dantz should work with 
Alladin and come up with a better compression scheme.

I know that the on-fly compression is difficult to maintain speed, 
but it seems like better than 2:1 should be possible.  I'm not much 
of a wiz at all with compression, however I see modems getting 
v.42bis (4:1) on the fly, it seems like a little work and this should 
be possible for client and server as well.

Yes, I know that advertised and what you really get are totally 
different, but all I know is that if something is advertised at 4:1, 
it will be more likely to get at least 2:1 that 2:1 is likely to.

Alladin is cross platform.  Dantz covers the same platforms.

Yes, most people use hardware compression, but this is mostly because 
the hardware and software compression are likely to get the same 

Why would anyone want to write their own compression?  I mean, a 
license deal from Alladin, who's been doing it since the early days 
of Mac, would seem like it would be far more cost effective.

>It'd be really cool if the clients would compress the data before shipping
>it off to the (slow) network. I think we'd see better backup rates,
>especially since compression is so fast on today's computers.
>It wouldn't have to be much compression - kinda like PKZIP's "-ef" or "-es"
>switch (for FAST or SUPERFAST compression). Even a meager 10% compression
>would be a significant improvement.
>Decompressing at the server would be optional (Perhaps necessary to provide
>backward compatibility with restores to older clients that don't know what
>compression is. Then again the server would know the version of the client
>and whether the client supports compression.). I'd prefer optional, and let
>the tape drive hardware compression further compress the data if possible.
>Of course I'll leave the implementation details to Dantz. ;-)

To subscribe:    [EMAIL PROTECTED]
To unsubscribe:  [EMAIL PROTECTED]
Archives:        <>
Search:  <>

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:        <>
Search:  <>

For urgent issues, please contact Dantz technical support directly at
[EMAIL PROTECTED] or 925.253.3050.

Reply via email to