ADSM-L

Re[2]: Through Put for MVS Server

1996-12-12 13:44:00
Subject: Re[2]: Through Put for MVS Server
From: Bruce Heckler <Bruce_Heckler AT ADCOM-OPERATIONS.UCSD DOT EDU>
Date: Thu, 12 Dec 1996 10:44:00 -0800
Yo! Jaffray & Lawson...dudes

Yeah, I agree the numbers are strange.  I suspect, it's the number of
uncompressed bytes moved, before it hits the compression algorithm.  I
allow the client to determine compression, and I see the real time rates
vary all over the place. Even on a quiet LAN & mainframe.  I haven't tried
it (yet), but if compression is turned off, the rate "should" be pretty
steady. Because a byte is a byte is a byte.

I don't put much faith in the numbers ADSM spits out. The real number I
work with is Timex time. I'm able to move a half gig per PC in about 20-30
minutes wall clock, with my present configuration.  We had the same
problems as you with a 60 gig SPARC 1000. But we split the load between
regular UNIX file systems and Sybase databases. The UFS files are handled
by the server itself.  But we have SQL ADSM Backtrack on another server
handling just the databases. So we have two ADSM backups running on the
same machine concurrently. With NFS you can probably pull the same scam on
just about any machine or file system.


I also agree with brier Lawson.  Aside from the extra work, you don't want
to back up everything every night.  I'm an old DFHSM bigot, from which
loins ADSM sprang (so to speak). You actually cut your throat backing up
files you already have valid copies of.

I had a user who would force daily backups of a critical file. But he only
updated it at the end of the month.  Normal scenario: He finds out the
program that updates the file is bad, and has been that way for who knows
how long; He tries to restore  the oldest version, which is the seventh
out; His oldest backup turns out to be seven days old; Since he's a major
fasttrack manager type; Everyone gets all upset, meetings, gnashing of
teeth.... Had he left things (the hell) alone, he would've been able to
grab a backup seven months old.

Yup, we be at University of California, San Diego.  World renowned for
being the only ice plant (we don't have ivy) league Univ.. without a
football team.  Or! as IBM once sent us a letter addressed to: The
University of Sand. I guess 'cause we're on the beach.

Vaya con burrito, gang!





______________________________ Reply Separator _________________________________
Subject: Re: Through Put for MVS Server
Author:  jlawson AT ITTHARTFORD DOT COM at @UCSD
Date:    12/11/96 11:55 PM


Paul -

If UCSD is in California (U Cal at San Diego???) maybe it's a new left coast
math.  Don't feel bad - I grew up in Ohio, and I don't get his numbers either.

Actually, I think your numbers are probably pretty close.  I always warn users
about the KB/SEC number - it's a lot like CPU utilization - a somewhat funny
number.  Actually, if you take the Bytes transferred, and divide by the number
of seconds of network time used - you will get this number.  But as I said
earlier - it's like comparing CPU and Wall clock time. ALso, I am not sure how
well it is measured - as I suspect things like getting interrupted on the MVS
server can screw it up.  They must do something like measure the time when the
transaction is sent, and then the time the positive response that the block has
been received, subtract the two, and you have network time.  Sounds simple, but
it is loaded with possible errors.

But that's being pessimistic.  Remember a couple of things.  First, of your
50GB, you won't back it all up every night - only the first time.  If you
install ADSM before the server is completely built, you can further mitigate the
initial backup.  But afterwards, you only back up what's changed.  So take a
look at that, and figure your nightly window accordingly.  Secondly, remember
that the data will be (if you specify) compressed before it goes down the
network.  The amount of compression will vary, but if you get 30%, that takes
your 50GB down to 35GB (and of course, your disk probably isn't full either).

Bruce's tuning tips are good - take a look at them too.

With us, the critical question isn't so much how long the backup takes, but
rather How long can I aford to be out of the water if it crashes.  This
determines what you need for a restore window.  If your customer can only afford
2 hours (as a guess) then you better have mirroring, or something other than a
network based solution.  We ask this question of all of our clients so that
there is no misunderstanding when a full backup is required.  I love ADSM, but
it is not the solution for all of your backup requirements.  Oh yes - when
figuring down time in worst case - don't forget to figure in the amount of time
your repair guy will need to get the machine back up and running first!

Jerry Lawson
jlawson AT itthartford DOT com

______________________________ Forward Header __________________________________
Subject: Re: Through Put for MVS Server
Author:  INTERNET.OWNERAD at SNADGATE
Date:    12/11/96 3:59 PM


At 10:16 AM -0800 12/11/96, Bruce_Heckler AT ADCOM-OPERATIONS.ucsd DOT edu 
wrote:
>Holy Toledo Jaffray!
>
>Your configuration is almost the same as ours, with the exception we're
>running Interlink TCP/IP through FDDI.  However most of our workstations
>are hooked off Novell 10-T lans, which makes the "pipe" same size as yours.
>
>Worst case, we're seeing a half meg a second.  Best case is around 2 megs a
>second.  And so far, it's about double for our Sun's hooked directly to FDDI.
>Network traffic is much lower than expected.  About what you'd expect
>doing an
>FTP on the Internet.
>

Thanks for the info, although I do have a question.  How are you
 determining the through put?  When I do a backup from Win95 and watch the
numbers on the screen I can't make the math work out (maybe it is some kind
of bizzare University math).  As an example, Bytes Transfered = 31,919 KB,
Time = 00:20:50, Transfer rate = approx 1000KB/sec (I didn't write that
number down).  Now if I do the math and divide the bytes transfered by the
number of seconds (31913 / 1250) I get 25.5 KB/sec! Somewhat short of the
reported 1000KB/sec.  So what stupid thing did I do?  What am I missing?

Also, assuming I still remember how to do math (questionable at the best of
times), a 10Mb(it)/sec Ethernet connection should only be able to transfer
1280KB(ytes)/sec. ie. 10(Mbits) * 1024 * 1024 = 10485760 bits/sec, then
divide by 8 for Bytes/sec = 1310720, then divide by 1024 for KB/sec =
1280KB/sec. If I did it right, how then do you achieve through put of
2048KB/sec?

On the plus side, if I can get at least 2MB/sec I figure it should only
take me approx 7 hrs to backup the 50GB.  If I can get 4MB/sec, it should
only take 3.5 hrs.

Again thanks for your response, hope I haven't taken up too much of your time.

pdj

Paul D. Jaffray
pjaffray AT earthlink DOT net
"This Farm Uses John Deere Tractors"


>-- Saved internet headers (useful for debugging)
>Received: from VM.MARIST.EDU by mail.ucsd.edu; id UAA26601 sendmail 8.8.3/UCSD8
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R3)   with BSMTP i
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU (LMa
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8b) with NJE
>Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
>Received: from interlock.itthartford.com by VM.MARIST.EDU (IBM VM SMTP V2R3)
>Received: by interlock.itthartford.com id AA08367 (InterLock SMTP Gateway 3.0
>X400-Originator: jlawson AT higmx.itthartford DOT com
>X400-Recipients: ADSM-L AT VM.MARIST DOT EDU
>X400-Mts-Identifier: [/
>X400-Content-Type: P2-1988 (22)
>Priorit
>Message-ID:  <0012900001245097000004*@MHS>
>Date:         Wed, 11 Dec 1996 23:55:57
>Reply-To: "ADSM
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU
>From: Jerry Lawson <jlawson AT ITTHARTFORD DOT COM>
>Subject:      Re: Through Put for MVS Server
>To: Multiple re
<Prev in Thread] Current Thread [Next in Thread>