Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!csd4.milw.wisc.edu!lll-winken!vette!brooks
From: brooks@vette.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch
Subject: Re: What is a Mainframe?
Message-ID: <27852@lll-winken.LLNL.GOV>
Date: 2 Jul 89 16:29:29 GMT
References: <125@ssp1.idca.tds.philips.nl> <20752@winchester.mips.COM> <4400@ficc.uu.net> <187@uvacs.cs.Virginia.EDU> <355@torsqnt.UUCP> <33942@bu-cs.BU.EDU> <27637@lll-winken.LLNL.GOV> <2964@scolex.sco.COM>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: brooks@maddog.llnl.gov (Eugene Brooks)
Distribution: comp.arch
Organization: Lawrence Livermore National Laboratory
Lines: 18

In article <2964@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes:
>Real-time seconds, or system-time seconds?  How loaded were each of the
>machines?  What kind of archive?  What program was unarchiving them?  Any
>chance that the YMP had the archive on a disk over ethernet (I *hope* not!)?
The problem for the YMP is that it had to go through all of the software
layering as if the file had been out on a disk over an ethernet.  Some refer
to this as a BUG of NLTSS, others refer to this as a FEATURE.  The two sun
diskless nodes really did suck the files in over an ethernet.  Lock-out
priority was used on the Crays, and the timings was done at many times during
the day (including lightly loaded times) and consistent results were obtained.

The archive program and the sample archive can be supplied to anyone
who requests it.  Remember, however, that the best benchmark is YOUR
benchmark.  This archive program is something I use frequently to
transfer source files to a Cray and this is the reason for its importance
to me.

brooks@maddog.llnl.gov, brooks@maddog.uucp