more than likely a resource issue.  network is good place to start, but
could be cpu power(cycles), io subsystem, could be client doesn't have juice
to get the data to the server.  It can also be
data (compressed, tarred, zipped, or text).  these do matter greatly.  Also
the invocation of the backup matters.  I recieve backup requests with wild
cards across multiple filesystems.  I have found out that by breaking a
large request into multiple smaller requests, that I get better speed.  Also
get better through put with multiple systems feeding the server, and even
better with multiple filesystems from multiple servers.  On sdlt, I have had
speeds of 20-24 mb/s with a good mix, or down to the kb/s with a bad mix no
other changes.

> -----Original Message-----
> From: Jeffrey S. Jewett [mailto:spider AT UMD5.UMD DOT EDU]
> Sent: Wednesday, August 28, 2002 5:49 PM
> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
> Subject: [Networker] Oscillating Thruput
>
>
> Greetings,
>
> NW: 5.5.1
> OS: Solaris 6 ,  Sun E250
> Max parallelism: 12,   380 clients,  all types
> Network connection:  100BaseT
>
>
> Problem:
>
> After backing up to our two DLT8000 drive at a reasonable rate of
> 7-10 MB/sec (total for both drives),  the throughput drops off to
> a total of .5MB/sec for 10-15 minutes,  then climbs back up
> to 7-10MB/sec
> for a few minutes,  then drops back down and repeats.
>
> Using the graphical display of perfmeter,  the results are quite
> striking (peaks separated by long valleys).   While this is going on,
> I can ftp to a nearby (physically and same subnet) client and achieve
> 2MB/sec from server to client,   but when I initiate a
> NetWorker backup
> of that client,  I see the same abysmal response.
>
> netstat shows no errors or collisions.
>
> I first noticed this a few months ago,  and it comes and goes but
> is generally killing our throughput.
>
> I'm wondering if some sort of software throttling is at work,  as we
> have a mixture of fast/slow clients,  but basically I'm out of ideas,
> and the oscillating nature of the problem is baffling.
>
> Anyone have any ideas about what's going on,  or where to
> look for clues?
>
> TIA.
>
> - jeff
>
> --------------------------------------------------------------
> -------------
> Jeffrey S. Jewett                               Phone:  301.405.3054
> UNIX Support Group,  DCS/OIT                    Fax  :  301.314.9220
> Rm 1311, Computer and Space Sciences Bldg       Email:  spider AT umd DOT edu
> University of Maryland
> College Park, MD  20742-2411
>
> --
> Note: To sign off this list, send a "signoff" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>

--
Note: To sign off this list, send a "signoff" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=