HDTenEightyP/NetNews huggingface dataset:
From: dak@messua.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: What's RIGHT with stack machines
Date: 13 Nov 92 02:22:17 GMT
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen


>>I predict that before too long all high performance commodity micros will do
>>scheduling at runtime.

>I don't think the situation is as clear-cut as you describe it.

>There are certain scheduling techniques that tend to work well no
>matter where you use them -- as long as you have enough registers, it
>doesn't hurt to stick a few instructions between a load into a
>register and the subsequent use of that register.  On superscalar
>machines, it is generally a bad idea to do too many of exactly the
>same thing in a big lump (i.e., ld, ld, ld or fadd, fadd, fadd), and
>if you have the option of mixing things up a bit, you should.
>Increasing the size of basic blocks (through code replication,
>typically) is another trick for helping most machines, since branches
>often stall pipelines.

>These are general rules, and they won't yield optimum performance, but
>you must trade them off against the costs of generating
>implementation-specific code.  Those costs include

>  (1) less sharing of text and libraries
>  (2) lots of cache flushing and
>  (3) scheduling and register allocation are not necessarily cheap.

See the MIPS processors (micro without interlocking pipeline stages) for
a clever design idea: they have simply left out all instruction scheduling.
If you start a command using a register which a previous command still has
to fill up, there is no delay, but the OLD value is used.
So the compiler/assembler will have to include nops by hand in order to
prevent register clashes. On the other hand, command interlocking can be
done by compilers. And you can use the die space thus gained for other
purposes (bigger cashes, etc.). And because of the Harvard bus architecture,
there is no difference between waiting for interlock or fetching a nop.
Only problem: code tends to get longer.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 10 Nov 92 19:28:18 GMT
Article-I.D.: cs.BxIM38.L9F.2
Organization: School of Computer Science, Carnegie Mellon


bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
>Here is a summary of SPEC results for Alpha AXP Systems announced today.

>DEC 10000 Model 610 AXP, @200 MHz
>	SPECint92	106.54
>	SPECfp92	200.36
>DEC 4000 Model 610 AXP, @160 MHz
>	SPECint92	 83.51
>	SPECfp92	143.10
>DEC 3000 Model 400 AXP, @133 MHz
>	SPECint92	 65.32
>	SPECfp92	112.2

HP's announcement today mentioned

HP 735 and 755, @99 MHz
	SPECint92	 80
	SPECfp92	150.6

So, we now have non-simulated non-prototype-system numbers for the
DEC 21064 chip and the HP 7100 chip.  The result is that the HP at 99
MHz has about the SPECs of a 21064 at 160 MHz. 

DEC wins the performance-at-any-price race with a 200 MHz offering,
with 1.33 x the SPECs of the hottest HP.

The performance-at-a-price race is closer. The 99 MHz HP 735 is $35k
versus $39k for a 150 MHz Alpha. Practical issues (like ship dates
and configuration details) dominate the technical issues here.  Which
is sort-of the message that DEC and HP want you to hear, since they
plan to migrate the technology into cheaper boxes.

Damn that's fast. 
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Xref: sparky comp.arch:10452 comp.unix.bsd:8515 comp.os.linux:15865
From: spxpmf@thor.cf.ac.uk (Phillip Fayers)
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
Subject: Re: IDE faster than Mips SCSI disk
Date: 6 Nov 92 11:31:23 GMT
Organization: Physics Dept. University of Wales, Cardiff
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway

In article <1992Nov6.033942.21194@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
|These figures are not meant to be a thorough study. More of a provocation
|for more soul searching. The widespread belief that SCSI-2 is "defininely
|faster than IDE" is questionable, in fact under some circumstances, entirely
|false.
|	The results are not surprising for those who study the technical
|specs of these disks. IDE has more potential for high speed because of its
|lack of protocaol overhead. Its closeness to the disk also make it very
|reliable and efficient.
|	There are advanced disks which can do simultaneour multiple-head reads,
|but these techniques can also be used for IDE as well.
|	IDE is just a simple interface definition, just like SCSI-2, but IDE,
|is optimised for HARD DISKS, SCSI is not. SCSI is more general purpose.
|
|The mips machine under test runs on ultrix. Although it has up to 10Gbyte 
|of hard-disk, it is not so heavily loaded. We only use it for email and
|news feed. Fragmentation can be severe because I cannot even have 32 
|megabyte free space in /usr/tmp , only 30 Mbytes.
|
|Writing the 30 Megabyte file, 'iozone.tmp'...91.000000 seconds
|Reading the file...49.000000 seconds
|
|IOZONE performance measurements:
|	345684 bytes/second for writing the file
|	641985 bytes/second for reading the file
|****************************************************************************
|This PC machine runs on 386bsd. Using 1 megabyte test file it is faster than
|a similar 486/50Mhz EISA SCSI-2 hard-disk.
|
|486/33 Maxtor 7120 200Mbyte
|
|Writing the 32 Megabyte file, 'iozone.tmp'...91.283333 seconds
|Reading the file...67.116667 seconds
|
|IOZONE performance measurements:
|	367586 bytes/second for writing the file
|	499942 bytes/second for reading the file

I wouldn't put this difference down to SCSI versus IDE, I would put most
of it down to the poor IO performance of Ultrix. We recently had a DEC
announcement of Ultrix 4.3 where they claim to have improved file IO by
100-300%, a figure I'm inclined to believe. I ran the Byte UNIX
benchmarks on a DECsystem 8300 that we have here, its file IO
performance was comparable to that of a Sun SPARCstation IPC's internal
(slow) 207 MByte drive. File copy on both systems was approx 280 kBytes
per second. In comparison a SUN 4/360 we have here turned in 1440 kBytes
per second on file copy, this was using a 1.4 GByte SCSI disk on a slow
SCSI II interface (5 Mbytes per second max).
-- 

Phillip Fayers                      email: fayers@cardiff.ac.uk
Sun admin/support/programming       phone: 0222 874000 x 5282 (UK)
Newsgroups: comp.arch.storage
From: towen@relay.nswc.navy.mil (Thomas F. Owen)
Subject: Data Cartridges for Masstor M860
Organization: Code E402, Naval Surface Warfare Center
Date: Thu, 5 Nov 1992 12:50:04 GMT

We currently have a MASSTOR M860 system connected to a CDC 875 system.
The cartridges are beginning to wear out and we are not able to locate any 
sources of the older style M860 MASS STORAGE IBM data cartridges.  
These cartridges were manufacutred between 1984 and 1988.  The more 
current M860 MASS STORAGE CSS data cartridges will NOT work in our system.  
Does anyone out there know of a source for these items or have some laying 
around that were leftover from an old system?  Any help would be greatly 
appreciated.

Thanks in advance,
Tom Owen
===================================================================
Thomas F. Owen (towen@relay.nswc.navy.mil)
Work: (703) 663-7614
Paper Mail: NAVSWC, Code E402, Dahlgren VA 22448
From: david@talgras.UUCP (David Hoopes)
Newsgroups: comp.arch.storage
Subject: Re: FileSecure
Keywords: Talgrass, Filesecure
Date: 9 Nov 92 16:10:55 GMT
Reply-To: david@tallgrass.com (David Hoopes)
Organization: Tallgrass Technologies Inc.

In article <Bx48Fy.n4C@newcastle.ac.uk> unregistered@newcastle.ac.uk (Tor-Olav Berntzen) writes:
>
>Have anybody got Filesecure, a programm that i think is sold with talgrass
>tapestreamers. I have got such a tape streamer.... but no software... leaving

e-mail to support@tallgrass.com will go to the Customer Support Dept.  They
will be able to help you.



-- 
---------------------------------------------------------------------
David Hoopes                              Tallgrass Technologies Inc. 
david@tallgrass.COM                       11100 W 82nd St.          
Voice: (913) 492-6002 x323                Lenexa, Ks  66214        
Newsgroups: comp.arch.storage
From: stephens@access.digex.com (John Stephens)
Subject: Metadata-oriented file storage/retrieval
Organization: Severn Companies, Inc., Lanham, MD 20706
Distribution: na
Date: Wed, 11 Nov 1992 20:30:22 GMT

 
 
I am looking for a UNIX utility or product (commercial or shareware)
that would allow users to store and retrieve files by attributes
(metadata) rather than the UNIX filename.  For example, the user would
supply the file name, his/her name, social security number, and/or a
project name/number.  The utility would store the file in a (remote)
storage server.

The user would later be able to retrieve files by a query tool that
would accept criteria based upon the metadata and return a list of
files that met the specified criteria. The user could then specify
which file/files were to be retrieved.

This capability could be fairly easily "fudged up" using a
datbase/query facility and ftp or nfs, but I hate reinventing wheels.
Does anyone know of an utility or program that already provides this
capability?
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: Need to use DAT as data drive.
Keywords: DAT
Organization: Leibniz-Rechenzentrum, Muenchen (Germany)
Date: Thu, 12 Nov 1992 09:19:52 GMT

mabbot@stel.csir.co.za (Mike Abbot) writes:

>I would like to use a (WANG)DAT as a data storage device (as opposed to a 
>backup device) in a PC based system.

>I have the device driver for the SCSI controller in the PC (Adaptec), and I 
>know that I can probably do what I need to do with the relevant SCSI 
>calls ...  BUT I'm trying to avoid that !
I would avoid that too. But did your driver software allow you 
open/close/read/write calls for the drive? This is the way you should work.

>1.  Has someone done this type of thing before ?
We use our DAT drives regularly for experiment data acquisition.
But we use them on UNIX workstations.

>2.  Is there any sort of standard for the (high-level) formatting of data on 
>a DAT drive ?
The standard is DDS, and is enforced by your drive, if you mean that.
If you mean, which block size you should use, there is no standard, and
there will never be a standard for that. The block size depends only on your
requirements. Block size should be large, or you will suffer from bad
performance.  Use block size in the range of 10 - 32k or even larger,
if your PC allows that.

>3.  Is there a device driver available that allows a DAT to function as a 
>DOS disk drive ?
Theoretically, this would be possible, but you really don't like that,
a filesystem for a disk drive lives with random access. You could do that
with a DAT drive, but think of the access time of 20s compared to 10-20ms
for a disk drive.

Sincerely,
Klaus
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE
Newsgroups: comp.arch.storage
From: pvb@paulvb.stortek.com (Paul von Behren)
Subject: Exabyte tapes on Sun systems
Summary: I'm looking for help estimating life span of tapes
Keywords: tape exabyte backup
Organization: Storage Technology Corp.
X-Newsreader: TIN [version 1.1 PL6]
Date: Wed, 11 Nov 1992 18:51:33 GMT

I'm trying to tighten up our process of backing up Sun SparcStations and
servers to Exabyte tapes. I have several questions related to the lifespan
of these tape volumes and ways to avoid unreadable data.

1) What is the expected shelf life of these cartidges?
2) How does the number of times a volume is read or written affect the
   integrity?   (i.e. is there a heuristic in terms of shelf life, write
   access, read access, other variables)?  
3) Is there a certification utility available which would help me anticipate
   tape media failures?
4) Is there a way to keep a count of correctable hardware errors (and then
   junk a volume when an error theshhold is exceeded)?

Thanks,		Paul_Von_behren@stortek.com
Newsgroups: comp.arch.storage
From: mabbot@stel.csir.co.za (Mike Abbot)
Newsgroups: comp.arch.storage
Subject: Need to use DAT as data drive.
Keywords: DAT
Date: 11 Nov 92 06:46:45 GMT
Article-I.D.: stel.mabbot.11.721464405
Organization: CSIR
NNTP-Posting-Host: 146.64.23.16

A bit of help required !

I would like to use a (WANG)DAT as a data storage device (as opposed to a 
backup device) in a PC based system.

Ideally I would like to be able to read and write to the DAT drive in a 
manner analogous to a hard drive (albeit in a sequential fashion).  The only 
software I have seen so far is stuff to perform an archiving/backup function.

I have the device driver for the SCSI controller in the PC (Adaptec), and I 
know that I can probably do what I need to do with the relevant SCSI 
calls ...  BUT I'm trying to avoid that !

1.  Has someone done this type of thing before ?

2.  Is there any sort of standard for the (high-level) formatting of data on 
a DAT drive ?

3.  Is there a device driver available that allows a DAT to function as a 
DOS disk drive ?

Any help or comments will be greatly appreciated.

Mike


Mike Abbott     mabbot@fred.csir.co.za (EMAIL not very reliable at present)
Cape Town       PH :  +27 2231 75101
RSA             FAX : +27 2231 75142
Newsgroups: comp.arch.storage,comp.os.vms
From: BUC@FINABO.ABO.FI (Johan Boholm, DC)
Subject: Problems with CA-ARCHIVER 4.0 and Exabytes
Organization: Abo Akademi University, Finland
Date: Wed, 11 Nov 1992 19:17:33 GMT
X-News-Reader: VMS NEWS 1.24


Does anyone have some experiences of the CA-ARCHIVER software?

We have run into problems with it concerning file transferring
from reel tapes to 8mm Exabyte tapes. We have a VAX 6000-510
running VMS 5.5-1, a HSC50 (microcode 4.1) and an Exabyte station
SI8500G (2 * 5GB) from Systems Industries. We use the Exabytes
for daily backup, so the problem shouldn't be there. The version 
of CA-ARCHIVER is 4.0. 

I first tried an "ARCTAPECOMPRESS", it would have done (according
to the manual) exactly what I needed but the run failed. I called
CA-Finland and they told me that ARCTAPECOMPRESS will disappear
from this piece of software because it hasn't been as reliable as
it should have. Well, they told me to do a 
"ARCHIVE/REWRITE/PRIM=PATnnn/SEC=SATnnn/GENERATE=ALL" and then
"ARCSERVICE/REWRITE/SETUP=PRESORT". When I started the service
run for "ARCSERVICE/REWRITE" I managed to transfer some data to
the 8mm tape but I soon noticed that the HSC console started to
complain about "timeout errors" etc. After a while this run requested
another 8mm tape (and it was still the first reel tape I transferred 
from!).

I interrupted the job and found out that I couldn't mount an ordinary
volume after that! I had to reset the Exabyte station to be able to
mount a tape again.

Unfortunately CA-Finland has very little knowledge of Exabytes, so
I hope someone out there could give me a hint or two... Thanks!


   -------------------------------------------------------------------
   Johan "BUC" Boholm                  e-mail: buc@abo.fi
   Computing Centre                    Phone:  358 + 21-654 379 (work)
   Abo Akademi University,             FINLAND
Newsgroups: comp.arch.storage
From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster)
Subject: Re: Query: Solid State SCSI Systems 
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Tue, 10 Nov 1992 02:10:22 GMT

In article <1992Nov9.203919.9793@nntpd.lkg.dec.com>, cassidy@esd55.enet.dec.com (Charlie Cassidy) writes:
|> 
|> We are showing the following products at COMDEX next week.  We also
|> announced today the EF5x family of DSSI SSDs for Digital's VAX and ALPHA AXP 
|> systems.  Please contact me or visit us at the Digital's OEM booth on the Comdex


I guess this seems like an excessively "Commercial" posting for
this newsgroup.  I think it belongs on biz.dec.announce, or
comp.newprod, etc.  Since it is here, however, I have a few
questions:


|> The ESP500 Models 510 and 530 provide up to 100 times faster
|> access to data and up to 10 times greater transaction throughput
|> than magnetic disks.  The near-instantaneous access time of
|> 0.25ms is achieved by eliminating the latency associated with
|> magnetic disk rotation and head seek.  Not only do ESP500 SSD
|> perform at semiconductor speed, they are predictable as well,
|> because the constraint of data locality associated with magnetic
|> media does not affect SSDs.


What is the transfer rate?  May I assume that it is 10MB/sec?

What is the measured latency through a real SCSI-2 controller?

For example, what is the latency I can expect on a DECsystem 5500?

Measured the way DEC usually measures these things, how many QIO's/sec
can the device handle at the usual delay points?  Can the existing
controllers, such as the one on the DECsystem 5500, saturate it?


-- 
  Hugh LaMaster, M/S 233-9,     UUCP:      ames!lamaster
  NASA Ames Research Center     Internet:  lamaster@ames.arc.nasa.gov
  Moffett Field, CA 94035-1000  Or:        lamaster@george.arc.nasa.gov 
  Phone:  415/604-1056                     #include <usenet/std_disclaimer.h> 
Newsgroups: comp.arch,comp.lang.misc
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Dept. of Computer Science, University of Waterloo
	<GLEW.92Nov4072629@pdx007.intel.com>
	<MHCOFFIN.92Nov5075939@tolstoy.uwaterloo.ca> <Bx96Bz.E2@rice.edu>
Date: Fri, 6 Nov 1992 19:24:12 GMT

In article <Bx96Bz.E2@rice.edu> preston@miranda.cs.rice.edu (Preston Briggs) writes:
> 
> mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:
> 
> >I don't disagree that occasionally gotos are cleaner than the
> >available alternatives, but I wouldn't call Knuth an arbiter of good
> >taste in programming style.  On the one hand, TeX the program is
> >clearly written and contains some beautiful algorithms.  On the
> >other hand, TeX the language is a wretched mess---it's almost
> >impossible to write clear code in TeX.  So I'd say Knuth's record on
> >programming style is very mixed.
> 
> I disagree.  It's easier to read and write programs in TeX than
> in any other typesetting language around!

It's a matter of taste I suppose, but I disagree.  Except that the
names are a little nicer, I prefer even troff macros, to say nothing
of, say, Postscript.  

> Isn't your complaint similar to saying
>
> 	Makita builds terrible tools because this power planer
> 	makes a terrible lathe.

I don't think so.  I just think that simple things ought to be simple
to express.  I don't find that to be true of TeX.  Often simple things
require bizarre contortions to accomplish.

I think Knuth thought hard about specifying the output of a typesetter
and did a good job on that aspect of the language.  Macros work pretty
well for output; it's sort of natural to think of macros `expanding'
to the desired output by repeated rewriting.  (Even here there are
complications, especially the two-phase expansion: the `mouth' and the
`stomach', as he puts it.)  But he didn't design good features to
parse the input, which is the flip side of a language for typesetting.
The code required to parse even moderately complicated input---a
context-free grammar, for example---is absurd.  Contrast that with
troff's eqn, where the input format is specified very naturally using
appropriate tools like lex and yacc.

-mike





From: cag@hpfcso.FC.HP.COM (Craig Gleason)
Date: Thu, 12 Nov 1992 17:15:27 GMT
Subject: Re: Re: DEC Alpha AXP System Performance
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch

> In article <15445@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
> >Hmm.  As I remember, somebody from DEC at a session on topics such as
> >OSF/1-on-MIPS on Tuesday night at the San Antonio USENIX claimed that
> >HP-PA was "out of gas"; anybody know what his response to the above
> >figures are?
> 
> He would have known about the 7100, although not its exact SPECs.
> So, he's not *too* surprised.
> 
He was probably the same DEC marketing dwid who said last year that
HP was "up against the ceiling" in performance.  We "just took old
technology and pushed it to the limit."  Well, it worked last year and
it worked this year.  Anybody want to bet against us next year?

When are marketeers going to stop projecting the limits of what engineers
can do, and just let us get on with doing it?  Get over it, people.  Stop 
predicting who's out of gas and look forward.

> What he may have meant, is that HP won't be able to use offchip
> primary cache much longer. That was difficult at 66 MHz, and is
> really impressive at 100 MHz. Even HP can't do it at 200 MHz, surely.
> 
Surely.  Or not.  If it's the right thing to do, you can bet we'll do
it.  

> DEC's architects also have a low opinion of HP's high semantic
> loading. That is, HP has instructions that also do some second thing -
> such as skip-on-condition. The Alpha team avoided that, and have
> handwaving arguments about how this will help in future "aggressive"
> implementations.

You did an excellent job of explaining why the junior architects' club
doesn't design VLSI chips.  They can sit back and handwave all they 
want, but the proof is in the product.  

Can't anyone understand that the 21064 and the 7100 aren't blazing fast
because the architectures are great, but because the engineering was
great?  I'm sure the Alpha design team could have built a MIPS 
architecture chip that performed just about as well as Alpha if it
suited their purposes.  

Craig Gleason
* my opinions, not HP's
Xref: sparky comp.arch:10467 comp.lang.misc:3527