You sure the process is cpu bound and that it even matters? One would think
the operation is more I/O bound..

Otherwise from redbook "using the ba client" try adjusting the
resourceutilization paramater:

Resourceutilization
Authorized User
The resourceutilization option regulates the level of resources the
Tivoli Storage Manager server and client can use during processing.
When you request a backup or archive, the client can use more than
one session to the server. The default is to use a maximum of two
sessions; one to query the server and one to send file data. The
client can use only one server session if you specify a
resourceutilization setting of 1. The client is also restricted to a
single session if a user who is not authorized invokes a UNIX client
with passwordaccess=generate specified.
A client can use more than the default number of sessions when
connecting to a server that is Version 3.7 or higher. For example,
resourceutilization=10 permits up to eight sessions with the server.
Multiple sessions may be used for querying the server and sending
file data.
Multiple query sessions are used when multiple file specifications
are used with a backup or archive command. For example, if you
enter:
inc filespaceA filespaceB
and you specified resourceutilization=5, the client may start a
second session to query files on file space B. Whether or not the
second session starts depends on how long it takes to query the
server about files backed up on file space A. The client may also try
to read data from the file system and send it to the server on
multiple sessions.
The following factors can affect the throughput of multiple sessions:
¶ The server's ability to handle multiple client sessions. Is there
sufficient memory, multiple storage volumes, and CPU cycles to
increase backup throughput?
¶ The client's ability to drive multiple sessions (sufficient CPU,
memory, etc.).
¶ The configuration of the client storage subsystem. File systems
that are striped across multiple disks, using either software
striping or RAID-5 can better handle an increase in random read
requests than a single drive file system. Additionally, a single
drive file system may not see performance improvement if it
attempts to handle many random concurrent read requests.
¶ Sufficient bandwidth in the network to support the increased
traffic.
Potentially undesirable aspects of running multiple sessions include:
¶ The client could produce multiple accounting records.
¶ The server may not start enough concurrent sessions. To avoid
this, the server maxsessions parameter must be reviewed and
possibly changed.
¶ A query node command may not summarize client activity.
Note: The server can also define this option.

Also from another section:

Note: On occasion, the aggregate data transfer rate may be
higher than the network data transfer rate. This is because
the backup-archive client has multithreading capabilities.
When multiple threads run during backup, the data
transfer time represents the sum time from all threads
running. In this case, aggregate data transfer time is
mistakenly reported as higher. However, when running a
single thread, the aggregate data transfer rate should
always be reported as lower than the network data
transfer rate.



Regards,

Gerald Wichmann
Senior Systems Development Engineer
Zantaz, Inc.
925.598.3099 (w)