🚀 go-pugleaf

In article <BzL9CC.9E@rex.uokhsc.edu> ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:
>      I havn't heard too much about the Cray-3 -- is it out yet?  I
>heard that they were still having problems, but I don't talk to too many
>people who work in this area.  It sounds like a nice computer...

Rumor has it that Cray Computer (note: different company than Cray
Research, makers of the "letter" Crays) has contracted with NCAR for a
Cray-3.  The first contract, with Lawrence Livermore Labs (NERSC???
Memory fails), fell through due to delivery problems.

Someone at SDSC mentioned to me that Seymour Cray is already on to
designing the Cray-4.  Comments from CCC?

							spl
-- 
Steve Lamont, SciViGuy -- (619) 534-7968 -- spl@szechuan.ucsd.edu
UCSD Microscopy and Imaging Resource/UCSD Med School/La Jolla, CA 92093-0608
Where is the summer, the unimaginable
Zero summer?                 - T.S. Eliot, "Little Gidding"

>       I am curious as to what anybody thinks of the Cray EL.  I am
>looking over some stuff, but I was wondering what other people think of
>it -- especially people who have worked with it.  I have worked with
>the Cray YMP as a user, but I wonder how much translates down to
>the Cray EL.  How does it run vector, scaler, IO, etc?
 
Just started looking at it, but in an initial set of benchmarks,
comparing one processor to one processor of the YMP-8, the EL was
running 5 to 8 times slower.  This is more than the difference in
clock rate would account for (each program was recompiled for each
machine).   We have not looked hard at the code to understand why the
differences; which will need to be done before any thing definitive
can be said.  

In article <1992Dec22.010746.12873@afterlife.ncsc.mil> dpmccul@afterlife.ncsc.mil (Dean McCullough) writes:
>
>>       I am curious as to what anybody thinks of the Cray EL.  I am
>>looking over some stuff, but I was wondering what other people think of
>>it -- especially people who have worked with it.  I have worked with
>>the Cray YMP as a user, but I wonder how much translates down to
>>the Cray EL.  How does it run vector, scaler, IO, etc?
> 
>Just started looking at it, but in an initial set of benchmarks,
>comparing one processor to one processor of the YMP-8, the EL was
>running 5 to 8 times slower.  This is more than the difference in
>clock rate would account for (each program was recompiled for each
>machine).   We have not looked hard at the code to understand why the
>differences; which will need to be done before any thing definitive
>can be said.  

Might be memory.  Seems that the memory on the EL is significantly
slower than the base YMP.  The new big memory YMP can be significantly
slower due to it's memory speed.... and I suspect that the EL uses
this slower memory as it's standard.....  Not having run on either
of the two machines (EL or big Y), I don't qualify as an expert.  


-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !

In article <BzL9CC.9E@rex.uokhsc.edu>, ben@rex.uokhsc.edu (Benjamin Z. Goldsteen) writes:
|> 
|>        I am curious as to what anybody thinks of the Cray EL.  I am
|> looking over some stuff, but I was wondering what other people think of
|> it -- especially people who have worked with it. 

    The slowest NFS server I've ever used!!  And after one full year
of operations, Cray still hasn't managed to fix this.  Also the least stable,
though to be fair Cray seems to have finally succeeded in providing
us with a stable machine.  You wouldn't believe how often it used to
crash in the first few months.

    
-- 

Alain Brossard, Ecole Polytechnique Federale de Lausanne,
	SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
brossard@sic.epfl.ch

>From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
.
.
.

>    The slowest NFS server I've ever used!!  And after one full year
>of operations, Cray still hasn't managed to fix this.  Also the least stable,
>though to be fair Cray seems to have finally succeeded in providing
>us with a stable machine.  You wouldn't believe how often it used to
>crash in the first few months.

Just as stable as their large machines.  

I sure wish cray would really put in the effort that is needed to fix 
their operating system.

Bill Jones
jones@chpc.utexas.edu

The long suffering!

In article <1993Jan6.181111.14914@chpc.utexas.edu>, jones@chpc.utexas.edu (Willaim L. Jones) writes:
|> 
|> >From: brossard@siisun.epfl.ch (Alain Brossard EPFL-SIC/SII)
|> .
|> >Also the least stable, though to be fair Cray seems to have 
|> >finally succeeded in providing us with a stable machine.  You 
|> >wouldn't believe how often it used to crash in the first few 
|> >months.
|> 
|> Just as stable as their large machines.  
|> 
|> I sure wish cray would really put in the effort that is needed to fix 
|> their operating system.
|> 

These messages got me to thinking, we have 3 Cray systems here on
site (YMP8/8128, YMP2E/116, XMPEA-116) and over the past 3 years we
have experienced what I consider to be pretty good stability.  We
have significantly more failures caused by shooting ourselves in the
foot other then Cray caused failures, I dont have the numbers here
in front of me, but our MTBF (Mean Time Between Failure) is 
on the order of 800 hours on the Y's and about 500 hours on the 
X.  We run 24 hours a day/7 days a week and have experienced a 
99.86% up time over the past 3 months.

CUG statistics show, what to me as a Computer Center manager, would
be good numbers for stability (though not as high as we are ;~) ).  

With our experience, and what appears to be the "average" from the
CUG reports, I think the system/OS stability is pretty good, but
more work needs to be done on System Operations/Administration tools
to help us in the data center.  Users dont care if its a CPU
failure, Disk head crash, memory failure, or the operator "pulling
the plug", down is down.

-- 
Douglas T Anderson
Technical Services Manager/Chief Engineer
POPS Program

All opinions expressed are mine and mine alone.  They do not
reflect the opinions of Grumman Data Systems, the US Navy or any
one else, unless they want them to.

In article <1993Jan6.180326@siisun.epfl.ch> brossard@siisun.epfl.ch (Alain
Brossard EPFL-SIC/SII) writes:
>In article <BzL9CC.9E@rex.uokhsc.edu>, ben@rex.uokhsc.edu (Benjamin Z.
Goldsteen) writes:
>|> 
>|>        I am curious as to what anybody thinks of the Cray EL.  I am
>|> looking over some stuff, but I was wondering what other people think of
>|> it -- especially people who have worked with it. 
>
>    The slowest NFS server I've ever used!!  And after one full year
>of operations, Cray still hasn't managed to fix this.  Also the least stable,
>though to be fair Cray seems to have finally succeeded in providing
>us with a stable machine.  You wouldn't believe how often it used to
>crash in the first few months.
>
>    
>-- 
>
>Alain Brossard, Ecole Polytechnique Federale de Lausanne,
>	SIC/SII, EL-Ecublens, CH-1015 Lausanne, Suisse, +41 21 693-2211
>brossard@sic.epfl.ch
>
factoids on cray-el at lausanne polytech (epfl):
- feb92: inst. of worldwide first system at epfl s/n 5110. worlds most
  complex EL file-server only configuration, 62 GB disk including alpha
  testing RAID technology and STK 4400 1.2 TB cartridge robot system.
  ethernet, fddi, hippi.
  2 months collaboration with cray to debug this alpha system.
- may 92 - nov 92: production with alpha prototype: uptime 99.14%
  nfs performance bugs and raid disk bugs fixed.some crashes due to
  hardware not yet uprev'd but known; tape-deamon bugs.
- nov92: replacement of alpha prototype by fully up-rev'd system: no
  unplanned interruption since then. hippi still delayed by third party.
- nfs performance: compare apples with apples - el is average in stand-
  alone, but much better than others with heavy load (average keeps up!).
  this using nfs standard waiting write ack. testing witout write ack
  will be performed soon.
- general cray uptime: cray-2 99.82 % (9 out of 12 months no interrupt)
  y-mp/4e 99.57 % including installation in may 92. this blows the socks
  off other supercomputers installed in switzerland by other vendors.
- information: michel jaunin, head computing center epfl: e-mail
  jaunin@sic.epfl.ch
michel h. reymond, director scientific computing center epfl
e-mail: reymond@sic.epfl.ch