On Friday 30 May 2003 05:27, Paul Bijnens wrote:
>Gene Heskett wrote:
>> Now the client is a bit slow, a 500mhz K6-III, so I expected the
>> level 0's this would cause would take a while.  This also brought
>> my disklist entries up to 44.  The string that controls the
>> dumporder in amanda.conf:
>> dumporder "SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS"
>> *should* cause the largest first, then descending order, and there
>> are enough S's to cover all DLE's such that once the first dump is
>> ready, the drive streams till its done.
>
>They all start together, but which dump will be ready first you
>think?  It's probably one of the smaller dumps!
>I guess not all 44 dumpers will be active, because you probably have
>other constraints (maxdumpers per host, per disk, bandwith etc,).
>
Miss-conception I think, 44 DLE's, but its the default 4 dumpers in 
the amanda.conf (on the server).

>Taper starts taping as soon it receives the first file to tape, and
>that's probably a smaller one.

So basicly it had the 1 dumper running on the client, and 3 running on 
itself, and they went thru the biggest 33 files on the server while 
the 1st one on the client completed.   Mmm, the counts are correct, 
but they didn't 100% start with the biggest ones on the server since 
it had taped 650 megabytes of server stuff by then, but the server 
still had at least 2 to do yet that were more than the 650 megs the 
first 33 had totalled, each.

Thats what got my attention.

>Using less dumpers should work better.

Less than 4?
------from amanda.conf-----
inparallel 4            # maximum dumpers that will run in parallel (max 63)
                        # this maximum can be increased at compile-time,
                        # modifying MAX_DUMPERS in server-src/driverio.h
[...]
dumporder "SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS" # specify the 
priority order of each dumper
                        #   s -> smallest size
                        #   S -> biggest size
                        #   t -> smallest time
                        #   T -> biggest time
                        #   b -> smallest bandwitdh
                        #   B -> biggest bandwitdh
                        # try "BTBTBTBTBTBT" if you are not holding
                        # disk constrained
                        # BUT, if you want streaming, start with the big ones 
and work down
-----------
Maybe I should change the first 5 or 6 to T's?  OTOH, if it starts 
taping when the first one is done, Theres not a heck of a lot I can 
do, that machine is overclocked as far as it will without effecting 
the uptimes now.  If it held them in the holding disk to achieve the 
specified order, it would have waited over 2:20 for the first, 
actually the biggest, after "compress client best" compression.  
According to amplot, the tape was running from about :45 to about 
1:15, then was resting for about another 50 minutes before fireing up 
and finishing the job at the 3:55 mark, certainly not as tape 
wastefull as running without a holding disk would be.  And either way 
the total runtime would be pretty much the same for the same set of 
conditions.

Thanks Paul.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% 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.