John Langford [[EMAIL PROTECTED]] writes:
> >(no compression at all) you'd have to transmit 6-6.6MB of data - how
> >do you arrive at 20MB?
>
> I ran rsync --stats on two identical files of size 100MB with a 64KB
> block size and extrapolated to 20GB. The files themselves are
> incompressible.
I was actually thinking of the compressibility of the meta-data
checksums rather than the file. Unfortunately it appears that the
meta-information is only affected by compression (-z) on the path from
the sender to the receiver, so it doesn't affect the initial
transmission of the checksums from receiver to sender.
At the risk of boring other readers, I'm curious what numbers you were
getting during your test - I just tried a --stats myself on a 51MB
file (block size 64K and no changes) - with and without -z, it
transmitted (receiver to sender) 4742 bytes. It received 3222 without
compression and 82 with compression.
So if I extrapolate that to 20GB, I'd get a bit under 2MB transmitted,
and either ~1.3MB or 34K for reception. Meta-data only, no literal
data included in these numbers.
Of course, then I partially managed to confuse myself since I would
have expected without compression to see 20 bytes x chunks (786 in
this case) or almost 16K of data, not the ~4K I'm getting. But that's
because I didn't take into account the adaptive checksum
implementation as long as the client/server agree on a recent protocol
version. In that case, the initial MD4 checksum is only 2 bytes of
data (growing to the full 16 if the file fails to transfer in full
successfully in the first pass). So there really should be only 6 bytes
per block being transmitted from receiver to sender in the first
meta-data transmission.
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: [EMAIL PROTECTED] /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
