HDTenEightyP/NetNews huggingface dataset:
From: jim@cs.strath.ac.uk (Jim Reid)
Newsgroups: comp.arch
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 24 Jul 92 14:54:32 GMT
	<1992Jul23.145502.20975@ncrcae.ColumbiaSC.NCR.COM>
	<l6tucvINNbqt@appserv.Eng.Sun.COM>
Organization: Computer Science Dept., Strathclyde Univ., Glasgow, Scotland.
In-reply-to: limes@ouroborous.Eng.Sun.COM's message of 23 Jul 92 18:25:35 GMT

In article <l6tucvINNbqt@appserv.Eng.Sun.COM> limes@ouroborous.Eng.Sun.COM (Greg Limes) writes:

   In article <1992Jul23.145502.20975@ncrcae.ColumbiaSC.NCR.COM> Jeff.McElroy@ColumbiaSC.NCR.COM writes:
   | So, how many processors can take and service interrupts?  

   Two answers, as usual ;-)

   First answer: All CPUs can accept and service interrupts,
   without regard to which CPU initiated the action that
   eventually triggered the interrupt. The same chip that handles
   MBus arbitration handles distribution of the interrupts; an
   internal register tells it which CPU gets them.

   Second answer: Only one CPU at a time can receive interrupt
   requests from devices in the system, and the software design of
   the 4.1.2mp kernel requires that device interrupt service
   routines execute within the single lock, so only one CPU at a
   time will be inside interrupt service routines.

So does this mean that this "symmetrical multi-processor SunOS" isn't
really what it claims to be? If only one CPU at a time can be executing 
interrupt service code, what we've got is an OS with one dedicated
(but not fixed) I/O processor.

It shouldn't be that difficult to arrange for multiple processors to
execute multiple interrupt service routines simultaneously. Encore
- whatever happened to them? - and Sequent have had UNIX kernels which
have done this for years (albeit with hardware assistance to handle
bus/interrupt/CPU arbitration). Perhaps there's some problem with
cache consistency and RISC chipsets at the bottom of all this?

		Jim
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Summary: Cost of 64-bits
Keywords: Cost, yield, integer datapath size
Date: 25 Jul 92 01:56:56 GMT
Organization: Digital Equipment Corporation


In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
> 
>    Maybe true. But for a user, should he buy one $2000 21064 chip or another
>    two $1000 CY7C601!?
> 
>This is a rather bogus discussion.
> 
>The assumption seems to be implicit that, given the same technology,
>etc., a 64 bit architecture implies twice the performance of a 32 bit
>architecture.

This is indeed bogus, but the assumption being made is that a 64-bit chip
>>costs<< twice what a 32-bit chip of comparable capability would cost.

As I pointed out originally, from measuring both the R4000 and the Alpha chip
die, the 64-bit (vs 32-bit) integer/addressing data paths adds 10% (or less)
to die area.  This will NOT drive a 2X difference in costs; more like 1.2X.

Clearly, by comparing chips of radically different capabilities (for example,
an R4000 versus an R3000, or an Alpha versus a CVAX), it is possible to
create totally arbitrary cost ratios.  As in the quoted example.  Within
a given process, and for like capabilities, die area drives yield drives cost.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
Newsgroups: comp.arch.storage
From: dale@convex.com (Dale Lancaster)
Subject: Re: DAT as data drive
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Mon, 27 Jul 1992 16:57:06 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <1992Jul27.105750.1830@donau.et.tudelft.nl> wolff@duteca8.et.tudelft.nl (Rogier Wolff) writes:

>dale@convex.com (Dale Lancaster) writes:

>>In <92201.120931ADB103@psuvm.psu.edu> <ADB103@psuvm.psu.edu> writes:
>>It is likely that you can work up a computer connection to these
>>drives (ID1, ID2, ID3), but my survey of the ID type drives is
>>that the Bit Error Rate is too high to store digital data (typically
>>in the 1x10-10 range.  A coulpe of vendors have adapted the ID
>>drive to a DD (Digital Data)  drive, but it took some work to get
>>the BER down to 1x10-13 which also added to the cost of the drive.

>A software (dual) parity check or reed-solomon ecc, would in no time
>improve the BER to better than 1x10-13. One would have to do good blocking
>and so forth to prevent dataloss due to a burst of errors.

10-13 is the best I have seen on any DD drive, but it appears that this
is not a bad error rate.  That most people seem to think it is acceptable.
You could create parity blocks and of course the BER jumps to what? maybe
10-20 or so?

dml
--
===========================================================================
Dale M. Lancaster, Mass Storage Marketing Manager, Convex Computer Corp.
(Work) 214-497-4581     (Fax) 214-497-4848     (Internet) dale@convex.com
===========================================================================
From: rod@isi.edu (Rodney Doyle Van Meter III)
Newsgroups: comp.arch.storage
Subject: SCSI (was Re: IPI-2 questions)
Date: 24 Jul 92 01:30:39 GMT
Reply-To: rod@venera.isi.edu (Rodney Doyle Van Meter III)
Organization: Information Sciences Institute, Univ. of So. California


Just to pick a nit or two, and ask a question:

Yes, SCSI-2 is 10 Mtransfers/sec, meaning 10 MB/s @ 8 bits, 20 MB/s @
16 bits.  NCR claims their 53C710 is good to 12.5 Mt, but points
out that it violates the standard that way.

The first sentenc of the foreword of standard says, "...bus
with up to 8 devices". Because of the way every device determines
whether or not it has won arbitration, IDs above 7 are
impossible on SCSI.  Theoretically it would work if all devcies
on the bus were 16 bits, but nobody's building the logic
to handle that since the spec forbids it, and they share the
bus with 8-0bit devices anyway.

Does anybody have a feel for how fast you can really make
Asynchronous transfer run?

I think VMS has an extent-based file system.

			--Rod
Newsgroups: comp.arch.storage
From: nagle@netcom.com (John Nagle)
Subject: Re: SUMMARY: O( terabyte ) tape system survey
Date: Fri, 24 Jul 92 06:58:12 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

       It's good to see Ampex still in the game.  Ampex offered the
first terabit tape system in the early 1970s, with 4" wide, 15" diameter
open reel helical scan tapes.  Massive machinery, even by mainframe
standards.   1000IPS tape search.  Sounded like an airplane takeoff.

					John Nagle
Xref: sparky comp.arch.storage:540 comp.sys.next.hardware:1121 comp.sys.next.misc:18122
From: wierda@ltb.ltb.bso.nl (Gerben Wierda)
Newsgroups: comp.arch.storage,comp.sys.next.hardware,comp.sys.next.misc
Subject: The DEC DSP3105 3.5" 1G disk keeps crashing.
Date: 24 Jul 92 13:35:25 GMT
Reply-To: claudius@icgned.nl
Followup-To: comp.arch.storage
Organization: BSO/LT, Baarn, The Netherlands

So far, we have blown 3 DSP 3105 disks to kingdome come. All of them were
built-in in a NeXT (station or cube). All of them stopped working after days
or weeks.

Another dsp3105 has been working for weeks now in an external enclosue
flawlessly.

Are there experiences with the reliability of this disk?

Do people recognize this?
-- 
wierda@ltb.bso.nl (Gerben Wierda) || I speak for myself and not for my employer.
(+31) 2154 84415/(+31) 35 833539  || Support the League for Programming Freedom!
	"If you don't know where you are going, any road will take you there."
	Lewis Carroll, "Alice in Wonderland".
From: rod@isi.edu (Rodney Doyle Van Meter III)
Newsgroups: comp.arch.storage
Subject: Re: SCSI (was Re: IPI-2 questions)
Date: 27 Jul 92 07:16:59 GMT
Reply-To: rod@venera.isi.edu (Rodney Doyle Van Meter III)
Organization: Information Sciences Institute, Univ. of So. California

I said earlier that SCSI ids above 7 are disallowed.  The standard
implies this repeatedly, but I couldn't find anything that says
so explicitly -- the closest was the sentence from the foreword
I quoted before.

Besides which, I now have to retract part of my statement (about there
being no implementations of arbitration logic above id 7). The
data book for for the NCR 53C720 (their 16-bit SCSI-2 processor)
says it will allow you to specify an ID of up to 15. 8-15 are lower
priority than 7-0.  So, at least one vendor is building toward
the future. The priorities, from highest to lowest, are
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8.

I hadn't thought of putting 15-8 below 7-0; this would allow mixed
busses to work correctly (those which arbitrate with only 8 bits
will always get priority over anything higher, so they don't even have 
to know the higher ones exist). of course, in a mixed bus, not
all devices can talk to each other, so having them share the bus
makes little sense anyway. 

A device which arbitrates with only 8 bits can never select a
device with an id of 11, for example.  The id 11 device can select
an id 5 device, but cannot allow it to disconnect for fear that
it will be unable to reconnect. Also, if the target (id 5) depends
on knowing the id of the initiator, (11), it will believe that
id is 0.

I have heard that the NCR 53C720 is available in the U.S., but
it's not yet here (I'm in Japan, dewspite the email address).
Anybody know which computer manufacturers will be first to market
with 16-bit SCSI? We're building a device with a need for
speed (to quote Tom Cruise).

Speaking of making sense, am I making any?

		--Rod
Newsgroups: comp.arch.storage
From: mef@ehsl.mitre.org (Marc E. Fiucznski)
Subject: tiny/fast filesystem!
Organization: Electronic Hardware Standards Laboratory, MITRE Corporation,
	Reston, VA.
Distribution: comp
Date: Fri, 24 Jul 1992 15:01:28 GMT

Hi,

We have systems that will need access to a small number of files on
standard floppies.  There will be about 1.4MB of disk space and the
system does not support any filesystems (that I want to use).

It currently only supports a dos compatible filesystem, which is not
working very well.  Just wondering if anyone could give me a hint what
type of tiny/fast low-overhead filesystem I get.  

The OS I'm using is VxWorks (which is a real-time OS with 4.3BSD
flavor.)... any hints, source code, or whatever would be appreciated.

Would it be reasonable to implement the fast BSD filesystem or is
there something else, simpler, faster, better?

Thanks,

Marc

Newsgroups: comp.arch.storage
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: DAT as data drive
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Tue, 21 Jul 92 07:51:05 GMT

In <92201.120931ADB103@psuvm.psu.edu> <ADB103@psuvm.psu.edu> writes:

| My friend has a sony D3 DAT.  I've noticed that it has a 7 pin jack labeled
| remote digital I/O.  I was wondering if/how it would be possible to use this
| or any DAT audio deck as a computer data drive.  It seems feasible since the
| 7 pin jack is used for a pure data transfer sans A/D D/A conversion.
| Anybody have info on this?

Given that you can buy DAT drives complete with SCSI interface,
512Kbyte buffers, the extra level of ECC necessary to comply with the
specs (interchange!) for $1500US, and the minor amount of software
necessary to control the drive ;) and the relatively high expense of
consumer DAT drives, I wouldn't even think about it, unless you are
really into longterm projects for their own sake.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.arch.storage
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: SCSI (was Re: IPI-2 questions)
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 27 Jul 92 04:59:13 GMT

In <Brzs2r.23I@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:

| In article <nodq9mk@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
| >In <AJC.92Jul24120000@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
| >|   My understanding of the SCSI-2 standard is that it calls out a standard
| >| minimum delay of 200MHz (5 Mtransfers/sec). It also allows for the implementa-
| >| tion of Fast Differential (I believe that Fast Single-ended is not supported
| >| and would only allow a cable length of 0.5M) which calls out a minimum delay
| >| of 100MHz (10 Mtransfers/sec).
| >
| >There is an implementors note that fast SCSI might require differential
| >to be reliable.  This hasn't turned out to be the case (actual experience).
| >Several drive vendors are saying that they support single ended fast SCSI,
| >but are also saying that they want the bus to be 4 meters or less, in
| >this case, rather than 6 m.
| 
| Hmm.  I've regularly had problems with single-ended SCSI-1 over 2m on one (Sun)
| system, and other people who've had problems (eg crashes during heavy paging
| activity, which is when we had most problems too) have had the problems go away
| when they've changed to shorter cables.  I'd be cautious about using the full
| 6m, and spent a bit of time getting data on it from the SCSI committee people.
| (I'm working on a project where physical constraints use of the whole 6m.)

I was making the unspoken assumption that you have a clean implementation,
as do the devices.  SGI hasn't been completely squeaky clean on this
issue in the past, but we keep trying, and in general, do fairly well.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.arch.storage
From: pauck@mcshh.Hanse.DE (Marco Pauck)
Newsgroups: comp.arch.storage
Subject: IEEE Mass Storage System Reference Model
Date: 22 Jul 92 21:09:52 GMT
Organization: Point of Presence Hamburg

I know, this topic was already discussed in this group but can
someone please summarise the goal, the covered range (from physical
media up to application level?) and the current status of the
IEEE MSSRM?

The last thing I read about the MSSRM in this group was a request
for "end user" and "developer" feedback regarding their operational
requirements from someone at NASA.

Anyone volunteers for a FAQ?!

	Marco
-- 
Marco Pauck
WMD GmbH, Hamburg, Germany
email: pauck@mcshh.hanse.de
phone: +49-40-580111
Newsgroups: comp.arch.storage
From: wolff@duteca8.et.tudelft.nl (Rogier Wolff)
Subject: Re: DAT as data drive
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Mon, 27 Jul 1992 10:57:50 GMT

dale@convex.com (Dale Lancaster) writes:

>In <92201.120931ADB103@psuvm.psu.edu> <ADB103@psuvm.psu.edu> writes:
>It is likely that you can work up a computer connection to these
>drives (ID1, ID2, ID3), but my survey of the ID type drives is
>that the Bit Error Rate is too high to store digital data (typically
>in the 1x10-10 range.  A coulpe of vendors have adapted the ID
>drive to a DD (Digital Data)  drive, but it took some work to get
>the BER down to 1x10-13 which also added to the cost of the drive.

A software (dual) parity check or reed-solomon ecc, would in no time
improve the BER to better than 1x10-13. One would have to do good blocking
and so forth to prevent dataloss due to a burst of errors.

						Roger
-- 
If the opposite of "pro" is "con", what is the opposite of "progress"? 
(stolen from  kadokev@iitvax.iit.edu, who got it from brydon@asl.sinet.slb.com)
EMail:  wolff@duteca.et.tudelft.nl   ** Tel  +31-15-783644 or +31-15-142371
Newsgroups: comp.arch.storage
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: SCSI (was Re: IPI-2 questions)
Organization: MetaPro Systems, Perth, Western Australia
Date: Sun, 26 Jul 92 05:24:49 GMT

In <AJC.92Jul24120000@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:

>  The size of the transfer is started at 8bit, but can go to either 16bit or
>to 32bit. This would mean that the architectural limit in the current spec
>for Fast Very-Wide (ie. 32bit) Differential SCSI-2 would be 40MB/s. As I read
>the current spec the use of 16bit requires two SCSI cables to be used. So, it
>would seem possible (and the spec states it is) to mix 8bit and 16bit devices
>on the same bus using a Host Adapter that was capable of handling 16bit.

How do you prevent two devices responding to the same
low 8-bits of address?

i.e. devices 4 and 12.

The high bit is only visible on the 16bit bus. Is there some
magic which differentiates between 8 and 16bit addresses,
which is visible in the 8bit space?
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.arch.storage,comp.sys.sun.misc,comp.sys.sun.admin,comp.sys.sun.hardware
From: mike@socrates.umd.edu (Mike Santangelo (UNIX/VMS Sysmgr))
Subject: R/W Optical Drive for Suns
Summary: (see subject)
Keywords: R/W Optical,Sun,SPARC,SCSI
Organization: University of Maryland University College
Date: Thu, 30 Jul 1992 15:38:26 GMT

Looking for any recomendations on 5 1/4" Read-Write Optical Disk
Drives that are known compatible with Sun SPARC workstations.  At very
least need name/phone# of vendor and model number.  Additionally
subsystem price, cost of the removable media, storage capacity,
compliance with standards, and any experiences (good/bad) you have had
with it would be MUCH appreciated.

Thanks!

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@socrates.umd.edu
Computer & Network Systems Admin      +           mike@cbl.umd.edu
CBL / CEES (Solomons Island)          +           mike@kavishar.umd.edu
From: ted@telematics.com (Ted Goldblatt)
Newsgroups: comp.arch.storage
Subject: Re: IPI-2 questions
Date: 27 Jul 92 23:27:40 GMT
Organization: Telematics Intl., Inc.; Ft. Lauderdale, FL

In article <ADAMS.92Jul16125743@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de> adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
>
>Perhaps we should compare future developments of the SCSI bus with
>expected replacement of IPI-Bus, SCI by CERN, Switzerland. This is
>targeted to 2 GBytes/s [in words: 2048 MBytes/s]. ;-> 
>

2 comments, 1 nit and 1 not :-)

nit: SCI is an IEEE standard (IEEE 1596) that a group at CERN is
     working on.  It is not _by_ CERN.

not: SCI is in no way a replacement for IPI or any other I/O
     bus.  SCI is a processor/memory interconnect (i.e., if it
     replaces anything, it replaces the system's _memory_ bus)
     intended for large to very large coherent shared memory
     multiprocessors.  While I'm sure it can (and will) be used
     for other things, I don't think that an I/O bus replacement
     is one of them.

ted

     
-- 
Ted Goldblatt    ted@telematics.com     (305) 351-4367
    Telematics Intl., Inc.   Ft. Lauderdale, FL
Newsgroups: comp.arch.storage
From: dhd@exnet.co.uk (Damon)
Subject: Re: SCSI (was Re: IPI-2 questions)
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 26 Jul 1992 10:35:14 GMT

In article <nodq9mk@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
>In <AJC.92Jul24120000@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
>|   My understanding of the SCSI-2 standard is that it calls out a standard
>| minimum delay of 200MHz (5 Mtransfers/sec). It also allows for the implementa-
>| tion of Fast Differential (I believe that Fast Single-ended is not supported
>| and would only allow a cable length of 0.5M) which calls out a minimum delay
>| of 100MHz (10 Mtransfers/sec).
>
>There is an implementors note that fast SCSI might require differential
>to be reliable.  This hasn't turned out to be the case (actual experience).
>Several drive vendors are saying that they support single ended fast SCSI,
>but are also saying that they want the bus to be 4 meters or less, in
>this case, rather than 6 m.

Hmm.  I've regularly had problems with single-ended SCSI-1 over 2m on one (Sun)
system, and other people who've had problems (eg crashes during heavy paging
activity, which is when we had most problems too) have had the problems go away
when they've changed to shorter cables.  I'd be cautious about using the full
6m, and spent a bit of time getting data on it from the SCSI committee people.
(I'm working on a project where physical constraints use of the whole 6m.)

The info isn't on line OR simple, so don't plague me with requests unless
you've a specific question!  B^>

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.21|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || Hotrod motor groups soon.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.arch.storage
Subject: Re: SCSI (was Re: IPI-2 questions)
Date: 25 Jul 92 19:14:26 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <AJC.92Jul24120000@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
|   My understanding of the SCSI-2 standard is that it calls out a standard
| minimum delay of 200MHz (5 Mtransfers/sec). It also allows for the implementa-
| tion of Fast Differential (I believe that Fast Single-ended is not supported
| and would only allow a cable length of 0.5M) which calls out a minimum delay
| of 100MHz (10 Mtransfers/sec).

There is an implementors note that fast SCSI might require differential
to be reliable.  This hasn't turned out to be the case (actual experience).
Several drive vendors are saying that they support single ended fast SCSI,
but are also saying that they want the bus to be 4 meters or less, in
this case, rather than 6 m.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.arch.storage
From: hallam@zeus02.desy.de (Phillip M. Hallam-Baker)
Subject: Re: IPI-2 questions
Reply-To: hallam@zeus02.desy.de
Organization: DESY ZEUS Central Data Acquisition
Date: Thu, 23 Jul 1992 04:51:34 GMT

In article <BrMG3I.DnL@csn.org>, milton@teal.csn.org (Milton Scritsmier)
writes:

|>>There is the need to connect disk drives in a most efficient manner to
|>>a computer system, not to provide an interface for a "much broader
|>>range of devices"... Or would you like to have your swap device slowed down
|>>by your scanner running over a commonly used SCSI bus....
|>
|>You can use more than one SCSI bus per system. There's no requirement that
|>all your devices have to be on one peripheral bus. Presumably most systems
|>keep their high speed and low speed devices on separate peripheral bus
|>if performance is critical. The question is can SCSI provide the
|>necessary performance.

DEC have put two SCSI buses on VAXstations for years now. Damn usefull.

I've been looking at the specs of an AMPEX tape drive offering HIPPI as
an option in the near future. Anyone got any views on whether that may
be a future solution for desktop machines?

Thing that gets me though is adding interface boards which double the
cost of a machine. 


Phill Hallam-Baker
Newsgroups: comp.arch.storage