>I'd like the opinion of the crowd.....

I think that can be arranged :-).

>What is the frequency that the netusage is adjusted from the default.  ...

Not sure I understand your question, but I think you might misunderstand
how netusage works (which is very common).

When Amanda has nothing better to do, it sees if it can start another
backup.  There are a number of limiting factors, such as "inparallel"
(is there a free "dumper" process), "maxdumps" (how many backups at one
time will the potential client allow), spindle, and so on.

One of those limits is "netusage".  Amanda takes the estimated backup
size and some historical information to compute a rough guess at how
much bandwidth will be used if this backup is started.  That value, plus
all the currently running backups on the same "interface" (see below),
is then compared against the "netusage" value for that interface (or
the global value if no interface is specified).  If netusage would be
overcommitted by starting the backup, it is skipped.  If netusage is
not a problem, Amanda goes on to the next limit test.

However, once a backup starts, netusage has **no** effect whatsoever.
Amanda does not monitor transfer rate and adjust its I/O requests to
try and raise or lower it.  All those decisions are left up to the OS
and hardware.  Amanda literally reads and writes as fast as it can.

Another point of confusion is the "interface".  This is **not** the actual
hardware/software interface that will be used for I/O.  For instance,
if you call an (Amanda) interface "hme0" on a Sun system, that does not
mean the traffic is going to use instance 0 of a 100 Mbit Ethernet card.

Think of an Amanda "interface" as a software bucket.  It has "space"
(netusage) that is allocated and deallocated as backups start and end,
and that space is used as a limiting factor for startup decisions,
but it does not represent anything real.

I recommend "logical" interface names, such as "fddi-back-door" or
"enet-100" rather than real hardware names, to avoid confusion.

>Don

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Reply via email to