On Wed April 2 2003 22:12, Joshua Baker-LePain wrote:
>On Wed, 2 Apr 2003 at 9:29pm, Gene Heskett wrote
>
>> On Tue May 28 2002 05:09, Bartho Saaiman wrote:
>> >I have a problem where my dumper is slow and the taper seems to
>> > be faster:
>> >
>> >
>> >STATISTICS:
>> > Total Full Daily
>> > -------- -------- --------
>> >Estimate Time (hrs:min) 0:02
>> >Run Time (hrs:min) 11:21
>> >Dump Time (hrs:min) 9:42 9:42 0:00
>> >Output Size (meg) 14818.3 14818.3 0.0
>> >Original Size (meg) 20804.7 20804.7 0.0
>> >Avg Compressed Size (%) 71.2 71.2 --
>> >Filesystems Dumped 1 1 0
>> >Avg Dump Rate (k/s) 434.8 434.8 --
>> >
>> >Tape Time (hrs:min) 1:37 1:37 0:00
>> >Tape Size (meg) 14818.4 14818.4 0.0
>> >Tape Used (%) 74.1 74.1 0.0
>> >Filesystems Taped 1 1 0
>> >Avg Tp Write Rate (k/s) 2606.1 2606.1 --
>> >
>> >Is there a way of changing this to speedup backups.
>>
>> However, in most cases, the speed of the drive itself will be
>> the overriding consideration of how long it takes to backup 14
>> gigabytes. To use my own DDS2 drive and its about 390k/second
>> speed, 14 gigabytes would take nominally 10 hours, plus whatever
>> time the compression utility itself took. Your drive seems to
>> indicate its doing 434k/second, slightly faster than mine. so
>> you're doing it marginally faster.
>
>Actually, Gene, I think you missed it. His tape is doing just
> fine (Avg Tp Write of ~2.5MB/s). It's his dump rate that's the
> limiting factor here. How is your system set up? Are you
> dumping to a holding disk on the same physical drive? What
> hardware and OS are we talking here? What are you using for a
> backup program?
You are 100% correct Joshua, I was looking at dump time in the above
report, not tape time. I guess I'm too used to my old, slow DDS2
drive, my apologies to the group. In my case, it is the drive, as
demonstrated by this:
-------------
STATISTICS:
Total Full Daily
-------- -------- --------
Estimate Time (hrs:min) 0:20
Run Time (hrs:min) 2:50
Dump Time (hrs:min) 1:03 0:46 0:17
Output Size (meg) 2931.1 2633.2 297.9
Original Size (meg) 6408.8 5680.9 727.9
Avg Compressed Size (%) 32.9 32.8 33.8
(level:#disks ...)
Filesystems Dumped 35 7 28 (1:26 3:2)
Avg Dump Rate (k/s) 789.6 977.7 292.4
Tape Time (hrs:min) 2:08 1:55 0:13
Tape Size (meg) 2931.8 2633.3 298.4
Tape Used (%) 80.3 72.1 8.2
(level:#disks ...)
Filesystems Taped 35 7 28 (1:26 3:2)
Avg Tp Write Rate (k/s) 390.5 390.5 390.4
USAGE BY TAPE:
Label Time Size % Nb
DailySet1-24 2:08 2931.8 80.3 35
---------------------
where dump time is 1.03, but tape time is 2:08. And this on a night
when gzip is getting thumped pretty good (the real cpu killer
here). And FYI, my holding disk is a directory on the same drive
/usr is on, hence the use of spindle numbers in my disklist.
===========
Now, back to his problem, which it turns out looks to be dumper and
or filesystem bound. For that though, lets be sure, and get this
puppies name, rank and seriel number from the original poster.
Things like how fast is what cpu being run, and how old are the
drives, is dma running, does he have spindle numbers to ident the
drive in his disklist... gosh, the list seems to go on forever, but
that above data would be at least a starting point.
Refresh me too, by answering this: does the compressor run time get
charged against the dump time in these reports?
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.25% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
