We recently had a user with lots of standalone unix experience use ssh to send about 8 
GB of data (the entire contents of a 3390-9 minidisk mount-point) from one linux image 
to another on the same IFL.  

Consider this:  He compressed his data to a tar file.  He encrypted the data.  He sent 
the data.  He received the data.  He decrypted the data.  He decompressed the data.  

He used ssh because it was "more secure" and compressed it to "save bandwidth".  This 
even though all the communications took place internally to CP (VCTCA links) and never 
even hit an ethernet cable.  This would be REAL hard to put a sniffer on!

He called wondering why his bill was so big. He wondered if it was that three-hour 
copy job he did.  I told him he saved bandwidth by exchanging it for CPU cycles for 
the compression and encryption and he was paying for those CPU cycles.  I also told 
him I could have copied the entire disk using snapshot in about 10 seconds at no cost 
to him.

Robert Nix is correct when he says that mainframes are expensive when it comes to 
compute-intensive processes like compression and compiles.  And encryption.

They say there are three signs of stress in your life.  You eat too much junk food, 
you drive too fast and you veg out in front of the TV.  Who are they kidding?  That 
sounds like a perfect day to me!
Gordon Wolfe, Ph.D. (425)865-5940
VM & Linux Servers and Storage, The Boeing Company

> ----------
> From:         Nix, Robert P.
> Reply To:     Linux on 390 Port
> Sent:         Thursday, February 13, 2003 1:01 PM
> To:   [EMAIL PROTECTED]
> Subject:      Re: URGENT! really low performance.
> 
> Mainframes do I/O exceptionally well, but when it comes to compute bound tasks, they 
>do very poorly. If you think about a tar operation, the compression is a fairly 
>compute-intensive operation.
> 
> We're running a 9672-R56 w/ one IFL. During our initial trial, we found the IFL to 
>be about the same as a 300 or 400mHz PC for compute-bound tasks. The strength of the 
>mainframe comes in for burst-type execution and I/O throughput. Things like multiple 
>web servers running in individual Linux images. File serving. Anything where: A) The 
>CPU isn't expected to be taxed a great deal. and B) the CPU isn't going to be 
>utilized for long periods of time. This allows the CPU to be shared among a larger 
>quantity of images, giving all of them the impression of a dedicated box.
> 
> But, if one image starts doing compiles or compression of large quantities of data, 
>or any other CPU bound task, everyone will suffer.
> 
> ----
> Robert P. Nix                            internet: [EMAIL PROTECTED]
> Mayo Clinic                                  phone: 507-284-0844
> RO-CE-8-857                                page: 507-270-1182
> 200 First St. SW
> Rochester, MN 55905
> ----   "Codito, Ergo Sum"
> "In theory, theory and practice are the same,
>  but in practice, theory and practice are different."
> 
> 
> > -----Original Message-----
> > From: Alex Leyva [SMTP:[EMAIL PROTECTED]]
> > Sent: Thursday, February 13, 2003 3:10 PM
> > To:   [EMAIL PROTECTED]
> > Subject:      URGENT! really low performance.
> >
> > Hi all, i have a problem, we have a z800, the configuration is:
> > 1 cp 80 MIPS
> > 1 IFL
> > 8 Gb storage
> > 3 partitions:
> >         -os/390 2.6
> >         -os/390 2.6
> >         -z/vm 4.3
> > 840 gb (shark)
> >
> > the cp is dedicated to both os/390, and the ifl to z/vm, 2gb to
> > both os/390, and 6 gb to z/vm.
> >
> > Redhat 7.2 as a z/vm guest:
> >
> > [root@linux1 root]# uname -a
> > Linux linux1.xxx.xxx.xxx 2.4.9-38lvm #1 SMP mii feb 12 12:25:01 CST
> > 2003 s390 unknown
> > [root@linux1 s390]# cat /proc/cpuinfo
> > vendor_id       : IBM/S390
> > # processors    : 1
> > bogomips per cpu: 630.78
> > processor 0: version = FF,  identification = 02900A,  machine = 2066
> > [root@linux1 s390]# cat /proc/meminfo
> >         total:    used:    free:  shared: buffers:  cached:> 
> > Mem:  1045737472 364187648 681549824        0 15532032 317743104
> > Swap: 409821184        0 409821184
> >
> >
> > Default installation, the z/vm has one week installed:
> >
> > q cplevel
> > z/VM Version 4 Release 3.0, service level 0201 (64-bit)
> > Generated at 05/09/02 17:30:26 EST
> > IPL at 02/07/03 12:13:53 EST
> >
> > when we make a tar -gzipping it- from a directory with 100Mb, we have
> > that:
> > -the hmc indicates that the ifl is at 99% utilization.
> > -real time monitor indicates that the processor is at 99% utilization:
> > | <USERID> %CPU %CP %EM ISEC PAG  WSS  RES   UR PGES SHARE VMSIZE TYP,CHR,STAT |
> > | LINUX1     99 .15  99  4.4 .00 100K 100K   .0    1  50%A     1G VUS,QDS,DISP |
> > | SYSTEM    .08 .08 .00  .00 .00    0 5060   .0  536 .....     2G SYS,         |
> > | VMRTM     .02 .01 .01  .63 .00  462  483   .0    0   3%A    32M VUS,IAB,SIMW |
> > -"top" at the linux shows:
> > 30 processes: 27 sleeping, 3 running, 0 zombie, 0 stopped
> > CPU states: 97.6% user,  2.3% system,  0.0% nice,  0.0% idle
> > Mem:  1021228K av,  279636K used,  741592K free,       0K shrd,   14120K buff
> > Swap:  400216K av,       0K used,  400216K free                  234992K cached
> >
> > we apply some performance related commands like:
> > set quickdsp linux1 on real
> > set share linux1 relative 300 real
> > set share linux1 absolute 50% real
> >
> > and the time went from 1m3.6s to 1m2.039s in the better case, the people
> > from ibm (they are here yet) can give me an answer about the poor
> > performance (i consider that its a poor performance, because a intel piii
> > 128Mb RAM make the tar in about 28s), so i really dont know if this is the
> > real performance of linux under vm, if we are doing something wrong, or>
> > what, when we bought the z800 they said that with this configuration we
> > will be able to run about 200 virtual machinnes, maybe thats a fairly
> > dream?
> >
> > Please, i accept any comments, sugestions, or anything that can help us.
> >
> > Thanks.
> >
> >
> > --
> > Alejandro Leyva Rabinovich.
> > Jefe de la Unidad Departamental de Soporte Ticnico
> > (Administracisn de Mainframe).
> > Direccisn General de Informatica.
> > Secretarma de Finanzas.
> > Gobierno del Distrito Federal.
> 
> 

Reply via email to