These are some rough-and-ready benchmarks using rdist to
mirror a couple of directories to a vnd configured as an svnd
with and without encryption.
obj is /usr/obj, 3281 directories, 52997 total files (incl. dir) 448MB
vim is "data", 100 directories, 100 files/dir 2025MB
With -k encryption:
[EMAIL PROTECTED] vc]# time rdist obj >/dev/null
8m3.22s real 0m11.07s user 0m31.91s system
[EMAIL PROTECTED] vc]# time rdist vim >/dev/null
6m53.07s real 0m4.48s user 2m14.76s system
Without encryption:
[EMAIL PROTECTED] vc]# time rdist obj >/dev/null
7m19.11s real 0m10.80s user 0m23.66s system
[EMAIL PROTECTED] vc]# time rdist vim >/dev/null
5m5.86s real 0m7.13s user 1m15.91s system
Without encryption, async
[EMAIL PROTECTED] vc]# time rdist obj >/dev/null
7m11.12s real 0m11.32s user 0m23.67s system
[EMAIL PROTECTED] vc]# time rdist vim >/dev/null
4m54.87s real 0m6.73s user 1m16.78s system
These were performed on a DELL Poweredge 1550 twin P-III 1GHz
machine with Wide UltraSCSI drives, running GENERIC.MP 4.0
(relocating the various files to different spindles didn't make
much difference, those data are not reproduced here.)
Conclusions.
(0) async/softdeps aren't much of an issue. I didn't try
sync, because I didn't. It would be lots slower for the "obj"
case, see (1).
(1) rdisting /usr/obj [fully populated after building a release,
also with XF4 shadow directories] took a LOT longer than copying
the fakedata. The fakedata was made with the makedata script (other
post). It has 10 100MB files of random data, and 100 directories,
each with 100 files, 100KB each, total about 2GB. This is due to
the notorious poor performance of ffs when "metadata" is being
altered (i.e. directories created/destroyed).
(2) Encryption is not much of a speed issue with an svnd/blowfish.
Another test:
[EMAIL PROTECTED] vc]# time ./xrdist
[EMAIL PROTECTED]: updating host localhost
[EMAIL PROTECTED]: /home/vim/data/data.big.0: installing
[EMAIL PROTECTED]: updating of [EMAIL PROTECTED] finished
0m19.67s real 0m0.64s user 0m8.56s system
[EMAIL PROTECTED] vc]# time dd if=/home/vim/data/data.big.0 of=/home/trash
204800+0 records in
204800+0 records out
104857600 bytes transferred in 2.975 secs (35240993 bytes/sec)
0m3.11s real 0m0.08s user 0m2.82s system
[EMAIL PROTECTED] vc]#
(3) rdist takes about 19 seconds to move a 100MB file from disk
to encrypted svnd. Just dd'ing it takes 3 seconds. (cp is same).
So there's about a factor of 6 there. I suppose this represents
the overhead of the svnd and blowfish code.
Bottom line: this was much faster than Vim reported. (hours and
hours).
All of this leads me to conclude that Vim's slow times are not due
to encryption or compression, but just to the slowness of the USB
drive, in particular the USB channel itself. The best we can do
for that is to use rdist (or something else) that will only copy
over files that have changed.
No compression was used. I don't think it's necessary. If there
are compressed files on the working disk, fine, they'll be rdisted
to compressed files on the USB disk. That should speed things, but
I didn't evaluate that. But I'm assuming that the working data
changes slowly.
Dave
--
"Confound these wretched rodents! For every one I fling away,
a dozen more vex me!" -- Doctor Doom
_______________________________________________
Openbsd-newbies mailing list
[email protected]
http://mailman.theapt.org/listinfo/openbsd-newbies
