"Thone, Bradley A (Sbcsi)" wrote:
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 aroun
but have always abandoned the
idea because of performance issues.
-Original Message-
From: matt barkdull
To: retro-talk
Sent: 2/26/01 2:36 PM
Subject: RE: Transfer Rates - Dantz Help?
>Matt, if you think you're actually getting 4:1 real world compression
out of
>a modem, I sug
>Matt, if you think you're actually getting 4:1 real world compression out of
>a modem, I suggest you read some of the research on the subject.
I never said that... What I did say:
>Yes, I know that advertised and what you really get are totally
>different, but all I know is that if something is
At 09:52 -0900 2/26/01, matt barkdull wrote:
[snip]
>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
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
in practice - and restores are very slow.
-Original Message-
From: matt barkdull
To: retro-talk
Sent: 2/26/01 10:52 AM
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 tha
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, howev
rad.
-Original Message-
From: Irena Solomon [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 23, 2001 4:47 PM
To: retro-talk
Subject: Re: Transfer Rates - Dantz Help?
Yes, these are numbers before compression. The client does not compress data
before sending it across the network. Furt
d from the
source.
Regards,
Irena Solomon
Dantz Technical Support
925.253.3050
Try our new Searchable Knowledgebase at:
http://partners.dantz.com:591/faq/
> From: David Ross <[EMAIL PROTECTED]>
> Subject: Re: Transfer Rates - Dantz Help?
>
>> The performance i
> The performance is based on the raw number of MB transferred to the backup
> device from the source volume.
BEFORE software compression?
I ask since as I understand it remote clients compress before shipping
to the Retrospect module that doing the writing to the device.
Thanks
--
--
*
Try our new Searchable Knowledgebase at:
http://partners.dantz.com:591/faq/
> From: David Ross <[EMAIL PROTECTED]>
> Reply-To: "retro-talk" <[EMAIL PROTECTED]>
> Date: Fri, 23 Feb 2001 16:20:22 -0500
> To: retro-talk <[EMAIL PROT
Don't quote me on this, but I think it is the source. That is, the
amount of data read from the source drive, before compression.
Which would make the most sense because that is the real number that
people need to look at.
Matt
>Can someone at Dantz answer this please?
>
>Thanks
>
>David R
Can someone at Dantz answer this please?
Thanks
David Ross wrote:
>
> I know this has been answered here before but I can't find it in any of
> the messages I've saved.
>
> Is the data rate shown in the real time backup progress window the rate
> at which data, compressed or not, is going to t
13 matches
Mail list logo
