HDTenEightyP/NetNews huggingface dataset:
From: aggedor@ccwf.cc.utexas.edu (The Monster of Peladon)
Newsgroups: comp.misc
Subject: Need HELP (!) with an XT Motherboard, etc.
Date: 21 Nov 92 01:25:13 GMT
Organization: The University of Texas at Austin


Hi there:

	Here's the problem.  I get a 1701 error message when I try to boot
up my XT.  It has a Seagate ST-225 hard drive in it, controlled by a new (to
me) Western Digital WD1002S-WX2 hard drive controller card.  This all sits on
a 10MHz Turbo XT motherboard, which has Phoenix 2.27 BIOS.  I've tried many 
jumper combinations on the controller card, and still get the error message.
I suspect that there might be a problem with the DIP switches on the mother-
board, but I have no manual for the motherboard.  Can anyone out there in 
Cyberspace help?
	Any aid will be greatly apreciated.  Thanks in advance.

-- 
-------------------------------------------------------------------------------
David Milner	  |  *********  |  Amateur Radio Callsign  N 5 R U L
(GeNie)  D.MILNER |  *  Moo! *  |  (Internet)  aggedor@ccwf.cc.utexas.edu
Austin, Tx. U.S.A.|  *********  |  I know who I am, and I will NEVER go back!
** Illegitimus Non Carborundom Est!  (Don't let the bastards get you down!) **
-------------------------------------------------------------------------------
Newsgroups: comp.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: leaving it on?
Organization: Xenix Support, FICC
Date: Tue, 17 Nov 1992 18:45:20 GMT

I turn off monitors and terminals when I won't be using them for an hour or
so. I turn off boxes containing moving parts (disk drives) when I won't be
using them for a day or so.

I also try to make efficient use of my resources, which means not using
doggy software and then buying a 386/33 and 16M of RAM to make up for it.
No X-Windows, no Microsoft or IBM operating systems. AmigaOS, UNIX, MGR.
Reddy Kilowatt says: save power, don't do DOS.
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: rtstoney@memstvx1.memst.edu
Newsgroups: comp.misc
Subject: HD HELP
Date: 23 Nov 92 20:36:15 -0600
Organization: Memphis State University

HELP!
I NEED SOME TECHICAL INFORMATION ON A COUPLE OF HARD DRIVES.
I NEED THE TRACKS PER CYLINDER, TRACK CAPACITY IN BYTES, AND THE
DEVICE OVERHEAD FOR THE FOLLOWING DRIVES:
WESTERN DIGITAL AC2200 200MB HD
SEAGATE ST1239A 200MB HD.

THANKS IN ADVANCE.
K. TONEY
From: 00msthompson@leo.bsuvc.bsu.edu
Newsgroups: comp.misc
Subject: Voice Response Systems
Date: 21 Nov 92 19:39:54 GMT
Organization: Ball State University, Muncie, In - Univ. Computing Svc's


     Hello, I am a Ball State student with an interest in voice response
systems.  I was wondering if anyone could offer some information on the cost 
of implementing a voice response system such as the systems that handle class
registrations on a college campus.
     Please reply by e-mail if you can offer any information.  Thank you for
your help.
From: walter@zarquon.Eng.Sun.COM (Walter Bays)
Newsgroups: comp.benchmarks
Subject: Re: SPEC : questions, copyright, summary - a database of spec's ?
Date: 18 Nov 1992 17:52:04 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: walter@zarquon.Eng.Sun.COM
NNTP-Posting-Host: zarquon

>In article <1992Nov16.143948.27382@crc.ac.uk> ifenton@crc.ac.uk (I. Fenton) writes:
>>i would like to complie a list of all (!) SPECmark ratings, both INT & FP,

SPECint92 and SPECfp92 are the best "single number" metrics for processor speed.

SPECrate_int92 and SPECrate_fp92 are the best "single number" metrics
for total CPU system throughput.  They do not indicate performance of a
single job, nor of a mixed CPU & I/O workload.

In article 6290@news.acns.nwu.edu, gof@casbah.acns.nwu.edu (Gerald Fountain) writes:
>This sounds great.  I think this would be a great idea.  I would vote that you
>include the component scores in the SPEC ratings as well.  They sometimes show
>some interesting features (HP 700 series has *very* high MATRIX operations it
>would seem!).

Looking also at individual benchmark SPEC ratios is better than only
looking at geometric mean, and would help you spot unrepresentative
anomalies like 030.matrix300 in the old SPEC89 suite.  But from my own
experience, I suspect anyone will find daunting the effort of keeping
even the summary numbers accurate and up to date.

I would caution anyone maintaining a summary list to be sure to record
the source and date of each entry, e.g. "Dec-92 Newsletter", "May-92
Press Release", else it will prove difficult to verify information and
correct out of date information.

Beginning in January, Release 1 tapes (SPECmark89) will no longer be
supported, and results from that suite will be marked "obsolete".


(Though mostly in accord with my SPEC colleagues, these views nevertheless
contain my own opinions.)
---
Walter Bays                                         walter.bays@eng.sun.com
Sun Microsystems,  2550 Garcia Ave.,  MTV15-404,  Mountain View,  CA  94043
(415) 336-3689     SPEC Steering Committee Chairman      FAX (415) 968-4873

Newsgroups: comp.benchmarks
From: moss@cs.cmu.edu (Eliot Moss)
Subject: Re: DEC ALPHA Performance Claims
Followup-To: comp.benchmarks
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
	<1992Nov16.174912.22905@ryn.mro4.dec.com> <4288@bcstec.ca.boeing.com>
Date: Fri, 20 Nov 1992 15:25:22 GMT

>>>>> On 19 Nov 92 05:51:40 GMT, silverm@bcstec.ca.boeing.com (Jeff Silverman)
>>>>> said:

[ some other stuff omitted ... ]

Jeff> I have also received several message from several people at customer
Jeff> sites.  A lot of them are number crunchers, and they work in FORTRAN.
Jeff> Why FORTRAN?  Because it's fast (FORTRAN tends to be faster than C
Jeff> because you don't have to build argument lists on the stack - whether
Jeff> this is important or not, I'm not sure - I like to program in "C").  So
Jeff> they aren't so concerned with the speed of the chip, they're concerned
Jeff> with the speed of the computer, which is the compiled code, memory,
Jeff> disk, the whole ball of wax.

That may be true, but one should pass most arguments in registers in any case
(unless you have long parameter lists), and if they have to be dumped to
memory, putting them in the stack is no more costly than putting them in
static locations. Perhaps the FORTRANers are objecting to the stack pointer
manipulating instructions? Hardly seems a big cost to me. More likely that
FORTRAN optimizers are ahead on really agressive loop optimizations and such.
But this is not the main point I wanted to address ....

Jeff> I also got one message which was fascinating - it was pointed out to me
Jeff> that the activities associated with having more demand for RAM than RAM
Jeff> are a major performance drag.  Paging is bad news if you are into speed,
Jeff> swapping is even worse.  So how about a computer system where there is
Jeff> enough physical RAM so that everything that must be RAM resident is, and
Jeff> it doesn't swap or page.  This operating system would be something like
Jeff> RT-11, but it would be called RT-64 or similar.  I remember that on the
Jeff> DECsystem-10 (KA-10 CPU) you could get a performance goose by turning
Jeff> off the relocation logic, but that made it tough to run TOPS-10.

If you're sufficiently privileged, you can nail down your pages. Modern
machines' relocation logic has been worked on to make it fast, though I can't
say if the 21064 manages to run as fast as it would without relocation logic.
I suspect paging/swapping can be taken care of. What's going to be harder is
getting good cache performance. One needs a compiler that knows how to
reorganize loops to get more cache hits, etc. Some techniques have been
developed that do help a lot of loops, but I don't know the extent to which
they've made it into commerically available compilers.

--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
From: bt@irfu.se (Bo Thide')
Newsgroups: comp.benchmarks
Subject: Re: DEC ALPHA Performance Claims
Date: 16 Nov 92 16:24:08 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <4248@bcstec.ca.boeing.com> silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
>There is a lot of discussion on this thread about hardware vs. software speed
>up.  I suspect that the question is moot.  One of the features, attributes, 
>whatever of the Alpha is that the compiler is supposed to sort instructions
>so that the hardware pipeline works optimally.  This means that, for all
>intents and purposes, the compiler and the CPU are closely coupled in a
>new and unique way.  It also has some rather interesting side effects:
>
>1) Newer implementations of the alpha may need or take advantage of new ways
>of ordering instructions.  This in turn means that different alpha 
>implementations may need or take advantage of different executables or object
>modules, each compiled for its own processor.  Or maybe the processors will
>take a performance hit in the name of portability.  Who can say?
>
>2) It will be interesting to see if third party vendors come out with language
>processors (I.e. compilers) for the Alpha, if the compiler and the CPUs are
>so intimately familiar with one another.
>
>I don't know enough about the Alpha to answer these questions - and it may
>be the case that the questions won't be answerable until somebody tries.
>One test will be to measure how long it takes for somebody to announce an
>Ada for the Alpha.  We'll see.
>
>Jeff Silverman, Boeing.
>


This raises a question:  Were these numbers obtained with the standard
compiler(s) that are shipping with every system?  HP claim this to be the
case for their published specmark ratings for the 7x5 family.


Bo
-- 
   ^   Bo Thide'--------------------------------------------------------------
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|      Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
Newsgroups: comp.benchmarks
From: shair@barolo.cso.uiuc.edu (Bob Shair)
Subject: Re: Performance Analyzers for RS6000??
Reply-To: shair@vnet.ibm.com
Organization: IBM Champaign
Date: Mon, 23 Nov 1992 15:34:17 GMT

dennisk@aplcenmp.apl.jhu.edu (Dennis M. Kavanagh) writes:


>Does anyone have suggestions for Performance Analyzers running under RS6000??

Well, begin with the tools we ship with AIX... look in /usr/lpp/bosperf
(beginning with AIX 3.2.2) at the following files:
README     fileplace  lvedit     rmap       samples    tprof
filemon    lib        netpmon    rmss       svmon

and don't forget vmstat and iostat.

We'd be delighted to sell you the AIX Performance Analyzer/6000 Service Offering
which uses the above tools.

--

Bob Shair                          shair@vnet.ibm.com
Scientific Computing Specialist    SHAIR@UIUCVMD (bitnet)
IBM Champaign
Newsgroups: comp.benchmarks,comp.arch
From: pack@acd.ucar.edu (Daniel Packman)
Subject: Who wants faster machines  was  DEC ALPHA Performance Claims
Summary:  We want faster machines
Organization: Ntl Center for Atmospheric Research - Atmospheric Chemistry Div
Date: Wed, 18 Nov 1992 16:29:56 GMT

In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au (Peter Gray) writes:
>
>Which nicely ties in with my opinion of the "Specmark race"
>which is "who cares?". At our site we have ~100 SUN's.
>No HP, no DEC, no RS6000. How many of our SUN users want
>a faster machine? About 2. For the rest 10 Mips (SS1 type speed)
>is plenty....  How many banks need 100 Mips on peoples desktops?
>

As has been said, who cares if the payroll program that runs overnight
takes 8 hours or 8 minutes?  Indeed, in certain situations speed is
not that important.  For us, however, we find present algorithms still
limited by the speed of processors available.  With faster machines,
still more complex calculations become possible.  I cannot forsee a
faster machine that will be perceived by scientific institutions as
irrelevant.



-- 
Dan Packman     NCAR                             INTERNET: pack@ncar.UCAR.EDU
(303) 497-1427  P.O. Box 3000
                Boulder, CO  80307-3000        NSI/DECNET: 9583::PACK
Newsgroups: comp.benchmarks
From: willmore@iastate.edu (David Willmore)
Subject: Re: DEC ALPHA Performance Claims
Organization: Iowa State University, Ames IA
Date: Wed, 18 Nov 1992 20:29:22 GMT

stripes@pix.com (Josh Osborne) writes:
>silverm@bcstec.ca.boeing.com (Jeff Silverman) writes:
>[...]
>>1) Newer implementations of the alpha may need or take advantage of new ways
>>of ordering instructions.  This in turn means that different alpha 
>>implementations may need or take advantage of different executables or object
>>modules, each compiled for its own processor.  Or maybe the processors will
>>take a performance hit in the name of portability.  Who can say?

>That's not true of only the Alpha ('tho thay may make no atttempt to lessen
>the blow).  One way to solve this problem is to use something like OSF's
>ANDF.  I don't know if it is a good way (it has lots of other advantages and
>disadvantages), but it should work.
>[...]

I don't expect that will be much of a problem with the Alpha.  From the way the 
archetecture is designed, it looks like the most optimization and ordering takes
place on-chip.  The compiler orders things in a fairly general way which the CPU
schedules.  I wouldn't say that Alpha eliminates all code ordering problems, but
it should be less effected than other archetectures.  At least I hope so.

---------------------------------------------------------------------------
willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | 
David Willmore  | "Ever noticed how much they look like orchids? Lovely!" | 
---------------------------------------------------------------------------
Newsgroups: comp.benchmarks
From: rpao@mts.mivj.ca.us (Roger C. Pao)
Subject: WANTED: Unix disk I/O benchmark programs
Organization: MicroTech Software
Date: Sat, 21 Nov 1992 16:24:58 GMT


I am looking for the programs mentioned above for SCO Unix SVR3 Version 4
and Dell Unix SVR4 Rel 4.  I need to compare a few adapters.

In particular, I would like iobench, and I have heard of AIN III (whatever
that is--anyone know?).

Any leads are appreciated.
rp92
-- 
Roger C. Pao  {gordius,bagdad,pride386}!mts!rpao, rpao@mts.mivj.ca.us
Xref: sparky comp.benchmarks:1735 comp.arch:10916
From: phd85@seq1.keele.ac.uk (D.H. Holden)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: Who wants faster machines  was  DEC ALPHA Performance Claims
Date: 19 Nov 92 12:54:56 GMT
Organization: Keele University, England

From article <1992Nov18.175349.1664@cis.uab.edu>, by hyatt@cis.uab.edu (Robert Hyatt):
> In article <1992Nov18.162956.2990@ncar.ucar.edu> pack@acd.ucar.edu (Daniel Packman) writes:
>>In article <1992Nov18.012919.2493@cs.uow.edu.au> pdg@cs.uow.edu.au (Peter Gray) writes:
>>>
>>>Which nicely ties in with my opinion of the "Specmark race"
>>>which is "who cares?". At our site we have ~100 SUN's.
>>>No HP, no DEC, no RS6000. How many of our SUN users want
>>>a faster machine? About 2. For the rest 10 Mips (SS1 type speed)
>>>is plenty....  How many banks need 100 Mips on peoples desktops?
>>
> 
> I agree.  Even if I were to stop doing "number crunching" on my workstation,
> SS1 speeds are fair, but not great.  I have an SS2 (40mhz) with a local 400
> meg disk and it is better.  However, as X grows and increases it's function-
> ality more, it will become too slow.  My old Sun 3/50 seemed quite fast
> five years ago.  Now, you can't give 'em away.  


   any one want to give me one? :)
--
                                                                     

phd85@uk.ac.keele.seq1
keele university. 
Newsgroups: comp.benchmarks
From: dcp79807@csie.nctu.edu.tw ()
Subject: Re: Trace generator wanted (Uniprocessor or MP)!!
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: TIN [version 1.1 PL6]
Date: Mon, 16 Nov 1992 09:22:20 GMT

Dear Netter:

	Because the summary is long.  I post it to comp.arch only.
	If you are interested in it please get it in comp.arch.
	Thanks

Miller Lin

--
------------------------------------------------------------------------------
Chih(4)-Zong(2) Lin(2)				| e-mail address:            
Dept. Computer Science & Information Engineering|   dcp79807@csie.nctu.edu.tw 
National Chiao-Tung University			| 
Hsinchu, Taiwan, Republic of China		|
------------------------------------------------------------------------------
Newsgroups: comp.benchmarks
From: hkim@dps91a.cis.upenn.edu (Hyogon Kim)
Newsgroups: comp.benchmarks
Subject: Tektronix Hypermodel Benchmark: where?
Summary: I need it
Keywords: ftp site for Tektroniks Hypermodel Benchmark
Date: 19 Nov 92 20:32:04 GMT
Organization: University of Pennsylvania

Is there a ftp site where I can get Tektronix Hypermodel Benchmark?
If not, where and how can I get it? 

Thanks a lot in advance,
Hyogon Kim
==============================================================================
Hyogon Kim                  		University of Pennsylvania
hkim@dsl.cis.upenn.edu    		Distributed System Laboratory
(215) 898-5423			Dept. of Computer and Information Science
Moore 058 			200 South 33rd St. Philadelphia, PA 19104-6389
Newsgroups: comp.benchmarks,comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: DEC ALPHA Performance Claims
Organization: Xenix Support, FICC
Date: Mon, 16 Nov 1992 21:33:28 GMT

In article <BxM6L0.Jy1@apollo.hp.com> goykhman_a@apollo.hp.com (Alex Goykhman) writes:
>     Are they going to ship a copy of the G.B.W.R. with every ALPHA system?

The DEC of a couple of decades back would have...
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Xref: sparky comp.benchmarks:1723 comp.arch:10862
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 18 Nov 92 16:34:10 GMT
Article-I.D.: csrd.1992Nov18.163410.18990
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development

bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:


>In article <4248@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes...
>> 

>Optimal instruction scheduling for newer processors may indeed be different.
>Old binaries will run correctly, but probably somewhat slower. New binaries
>should in most cases run well on old machines, unless the scheduling rules
>are at odds.

There is more than one way for the scheduling rules to be at odds... one less
obvious one which comes to mind is different tradeoff points between code size
and structure and execution speed for different issue rates: for example,
binaries intended for a six-instruction issue per cycle machine (which would
try to create longer runs between branches by doing more speculative execution
and duplicating more code) could be significantly larger than binaries
intended for a two-instruction issue per cycle machine.

Running either's program on the other will work (if they are sufficiently
upward and downard compatible with regard to things like hints... which Alpha
should be) but is _not_ likely to give good performance.  For example, the
six-cycle machine would encounter shorter runs and higher interference within
groups of six instructions it tried to issue together; the two-cycle machine
would encounter a larger program, causing more instruction cache misses and
more page faults, and more unnecessary speculatively-executed code.

This raises the possibility of translating binaries _between_ implementation
levels of the same architecture (especially toward higher issue rates)...
something which I would hope DEC is thinking about.
--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Xref: sparky comp.benchmarks:1738 comp.arch:10923
From: silverm@bcstec.ca.boeing.com (Jeff Silverman)
Newsgroups: comp.benchmarks,comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 19 Nov 92 05:51:40 GMT
Followup-To: comp.benchmarks
Organization: Boeing Computer Services, Seattle

>In article <4248@bcstec.ca.boeing.com>, silverm@bcstec.ca.boeing.com (Jeff Silverman) writes...
>> 
>>1) Newer implementations of the alpha may need or take advantage of new ways
>>of ordering instructions.  This in turn means that different alpha 
>> 
>Optimal instruction scheduling for newer processors may indeed be different.
>Old binaries will run correctly, but probably somewhat slower. New binaries

I have received several mail messages from several people at DEC who have
told me that I am right and wrong.  They tell me that DEC is making the
code generators available to everybody (obviously, a solution that the
silicon people dreamed up), so that this won't be a major issue.  DEC is
expecting that as more experience is gained with the chip, newer and better
code generators will come out.

I have also received several message from several people at customer sites.
A lot of them are number crunchers, and they work in FORTRAN.  Why FORTRAN?
Because it's fast (FORTRAN tends to be faster than C because you don't have
to build argument lists on the stack - whether this is important or not,
I'm not sure - I like to program in "C").  So they aren't so concerned with
the speed of the chip, they're concerned with the speed of the computer,
which is the compiled code, memory, disk, the whole ball of wax.

I also got one message which was fascinating - it was pointed out to me that
the activities associated with having more demand for RAM than RAM are a
major performance drag.  Paging is bad news if you are into speed, swapping
is even worse.  So how about a computer system where there is enough physical
RAM so that everything that must be RAM resident is, and it doesn't swap or
page.  This operating system would be something like RT-11, but it would be
called RT-64 or similar.  I remember that on the DECsystem-10 (KA-10 CPU)
you could get a performance goose by turning off the relocation logic, but
that made it tough to run TOPS-10.

I am really excited about the Alpha, but we're not going to get one anytime
soon.

Jeff Silverman, Boeing

Newsgroups: comp.benchmarks