HDTenEightyP/NetNews huggingface dataset:
From: jmatrow@donald.WichitaKS.NCR.COM (John Matrow)
Newsgroups: comp.arch.storage,comp.periphs.scsi
Subject: Re: ?phone# for DPT (Distributed Processor Technology)
Keywords: DPT
Date: 15 Dec 92 14:54:27 GMT
Organization: NCR Corporation, Wichita KS

In article <mike.723761910@starburst.umd.edu> mike@starburst.umd.edu (Michael F. Santangelo) writes:
>Looking for a phone number for tech support at Distributed Processor
>Technology (DPT) to ask some question about one of their EISA SCSI
>controllers I pulled out of an EISA based AT&T StarServer '486 system.

Try 407-830-5522 and be prepared to leave your number for tech support
to call you back.

BBS is 407-831-6432 and 407-830-1070.

-- 
John Matrow   Systems Integration, NCR Peripheral Products Division
 NCR:654-8851 <John.Matrow@WichitaKS.NCR.COM>
(316)636-8851 <uunet!ncrlnk!ncrwic!john.matrow>
 FAX:636-8889 "Call (316)636-8628 to have array info faxed to you"
Newsgroups: comp.arch.storage
From: rcharlan@magnus.acs.ohio-state.edu (Randy F Charland)
Subject: ST01
Summary: Compatibility
Organization: The Ohio State University
Distribution: comp.arch.storage
Date: Thu, 17 Dec 1992 00:27:50 GMT

    I happened to have come across a Seagate ST01 SCSI HD controller but have 
not tried to use it.  Two questions, is this Seagate's first HD controller!! 
and will I have compatibilty problems with todays SCSI drives.

Thanks

Randy
Newsgroups: comp.arch.storage
From: ACPS7221@RyeVm.Ryerson.Ca
Newsgroups: comp.arch.storage
Subject: [Q] Kennedy PC type?
Date: 20 Dec 92 20:23:58 GMT
Distribution: na
Organization: Ryerson Polytechnical Institute


   Hello everyone:
   I have a Kennedy Tape backup unit, for a IBM pc compatible computer.
   Kennedy makes Tape units for mainframes, but did make a pc unit for a
   short while.
   Does anybody know what kind of unit the pc tape drive Kennedy made is?

   I have a Kennedy in my pc, but can't use it since I don't know if it is
   QIC-02, or QIC-40 or QIC-80 compatible (or anything else)

   Could some kind person please tell me  what  QIC standard is correct for
   this Kennedy tape drive?




                         Thank You Very Much In Advance,  Michael.
Newsgroups: comp.arch.storage
From: warren@stationd.storage.tandem.com (WARREN SAVAGE)
Subject: Re: Inner track transfer rate vs. Outer track transfer rate
Organization: Tandem Computers Inc, Cupertino CA
Date: Fri, 18 Dec 1992 17:16:58 GMT

In article <1992Dec18.145311.27416@sequent.com>, cyf@sequent.com (Cyrus Foughty) writes:
> I have heard two theories about one element that affects disk transfer
> rate.

> Theory 1: 
> 
> A higher transfer rate will result when using the outer tracks.

This is true only if the drive uses constant density recording.  It is quite 
common, especially on older disks to lay down the the same amount of bits 
regardless of radii, thus the xfer speed would be exactly the same.
 
> Theory 2:
> 
> A higher transfer rate will result when using the inner tracks.

Never true (to my knowledge).

The important thing to remember is that the inside of the platter and
the outside of the platter take the same amount of time to make one
revolution.  What can change is the number of bits that are recorded on
a track.
  
Newsgroups: comp.arch.storage
From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Subject: Info and Address of Auspex
Organization: University of Kaiserslautern, Germany
Date: Fri, 11 Dec 1992 18:02:05 GMT


Hello,

I have heard about a company named 'Auspex' to produce NFS-fileservers.

Is somebody out there running such a beast, and can give me a short survey?

Can somebody give me also the address of this company, perhaps a european
outlet, or even a german one ?

Thanks,

Reinhard Kirchner
Univ. of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de
From: prich@monk (Paul Richardson)
Newsgroups: comp.arch.storage
Subject: raid specs
Date: 18 Dec 92 01:14:48 GMT

Are there such things in existence (RAID specifications/standards),
are they online, and if so, where can I obtain them

--

/pgr

She's got Jungle Fevah... - Stevie
email: Paul_Richardson@next.com
Newsgroups: comp.arch.storage
From: cyf@sequent.com (Cyrus Foughty)
Subject: Inner track transfer rate vs. Outer track transfer rate
Organization: Sequent Computer Systems, Inc.
Date: Fri, 18 Dec 92 14:53:11 GMT

I have heard two theories about one element that affects disk transfer
rate. Help me disect these and find which is true and which is false.
Of course I feel that there will be some cases where both are true and
both are false. So, based on that I will tell you that I am dealing 
with the HP97560 SCSI-2 disk drive.

Theory 1: 

A higher transfer rate will result when using the outer tracks. "outer"
is defined here as "tracks that are the greatest distance from the 
spindle". I.E., track numbering starting at zero.


Theory 2:

A higher transfer rate will result when using the inner tracks.
"inner" is defined here as "tracks that are the closest to the
spindle". I.E., track numbering starting at maximum track number and 
decreasing.

The main argument used in theory 1 has been: because the inner tracks
are physically smaller, the head must wait one or more rotations to
position at the beginning of the track. 

The main argument used in theory 2 has been the inverse of theory 1's
main argument. The head can position fast enough to read the next track
with minimal rotations, therefore because the tracks are physically 
smaller more can be read faster.

I am mainly concerned with reads, but the discussion on writes are welcome.

Of course I may totally misinformed. So pull back the blanket of 
discovery and let me peruse.

Thank you for all responses!

Cy
-- 
Cy Foughty 
Sequent Computer Systems, Dallas, TX  MaBell: 214.661.1900
cyf@sequent.com
Standard disclosure: This is my opinion and not Sequent's.  
Newsgroups: comp.arch.storage
From: ghamlin@dale.cts.com (Garrett Hamlin)
Subject: Hard Disk Mirroring
Organization: Titan Linkabit Corporation
X-Newsreader: Tin 1.1 PL5
Date: Fri, 18 Dec 1992 23:04:30 GMT

 

Does anybody know a quick and easy (or even slow and difficult) way to "mirror"
 two large hard drives (either SCSI or IDE) on a Novell fileserver?  The idea 
is to have a constantly updated backup copy of frequently changing data.  
Surely there is a number of vendors with solutions to this seemingly simple 
problem.  Thanks in advance for any advice!


--
Garrett C. Hamlin
Titan
3033 Science Park Road
San Diego, CA 92121
Newsgroups: comp.arch
From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Subject: Re: Any use for Branch if Even/Odd ?
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Tue, 15 Dec 1992 02:45:45 GMT


In article <1992Dec14.203631.16388@CSD-NewsHost.Stanford.EDU>, andy@SAIL.Stanford.EDU (Andy Freeman) writes:

>In article <id.08RV.WYB@ferranti.com> peter@ferranti.com (peter da silva) writes:
>>Close. As I recall, DEC is very fond of using even/odd for true/false values,
>>and the VMS interface definition has a lot of even/odd status returns, so it's
>>likely these instructions are to make it run VMS real good.
>
>Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
>has to test the sign bit, so why not use it whenever one can use any
>bit to split things into two classes?

VMS status codes record more than just true/false. The bottom three bits of
a status code are encoded as follows:

0	Warning
1	Success
2	Error
3	Informational
4	Severe error
5	Reserved to Digital
6	Reserved to Digital
7	Reserved to Digital

The other bits are:

3-15	Indicates the particular condition that occurred.
16-27	Indicates the system facility in which the condition occurred.
28-31	Control bits.

Thus from a status code, it is not only possible to discover the
success or failure of a routine or program (for example), but the degree of
success or failure, the actual error that occurred, the facility (part
of VMS, an application, etc) that caused that error, and whether that error
has been signalled. In this way, it is possible, for instance, to see three
different status codes to discover why SEARCH failed, e.g.:

$ SEARCH FILE.TXT STRING
%SEARCH-W-OPENIN, error opening DISK:[DIR]FILE.TXT;1 as input
-RMS-E-PRV, insufficient privilege or file protection violation
%SEARCH-I-NOMATCHES, no strings matched
$

Opinion: If the status codes were at the high end of the longword, the
error codes for a particular facility would be scattered all over the
range instead of in a single group of numbers; harder for us humans to
comprehend. Given that the VAX architecture has bit test operations,
why not do it this way?

Anyway, don't ask me, ask the developers. :-)

>-andy
>--

PJDM
--
Peter Mayne                     | My statements, not Digital's.
Digital Equipment Corporation   |
Canberra, ACT, Australia        | "AXP!": Bill the Cat

Newsgroups: comp.arch,comp.arch.storage
From: dfields@hydra.urbana.mcd.mot.com (David Fields)
Subject: Re: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO
Reply-To: dfields@urbana.mcd.mot.com
Organization: Motorola, Inc.  Computer Group
Date: Thu, 17 Dec 1992 15:31:41 GMT

In article <1992Dec16.211712.13142@twisto.eng.hou.compaq.com>, simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:
> In article <1gntdfINNu7@cbl.umd.edu> mike@cbl.umd.edu (Michael Santangelo) writes:
>>Can EISA, MicroChannel, or the new VESA LocalBus on PC's allow
>multiple controllers plugged into them (say two smart bus mastering
>>SCSI disk controllers on one of these buses) xfer data simultaneously
>>to main memory (DMA)?
>>
>Generally, shared bus architectures are shared by time-division multiplexing.
>In short, only one device may use the "bus" at a time, so the answer to your
>question is No.

I read waht he said and wasn't so sure from the example he gave that the
question he asked is the one he wanted to ask.  To controllers can be doing
DMA trnasfers at the same time byspliting the transfers into smaller chunks
and doing the "time-division multiplexing" of the bus via an arbitraition
scheme.

>There was a post about a new I/O architecture from Compaq.  This architecture
>does allow multiple controllers to perform simultaneously.

If the MIOC in Compaq's proposal is implemented with a multi-port interface
to main memory then it will.  You would loose some on cost of course.
--
Dave Fields	Motorola Computer Group		dfields@urbana.mcd.mot.com
SVR4: The Winchester Mystery Kernel		uiucuxc!udc!dfields
Newsgroups: comp.arch
From: finger@convex.com (Jay Finger)
Subject: Re: Any new instructions in a i486?
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Tue, 15 Dec 1992 15:54:25 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 article <1992Dec15.042513.23969@gandalf.ca> dperks@gandalf.ca (Dave Perks) writes:
>Is it also possible that since the Intel 486 supports supervisor-mode write
>protection, it is is used to allow something like copy-on-write?  If NeXT Step
>was designed to use this then the kernel would require fairly major changes.

Yep, NeXTstep (and maybe Mach in general, somebody correct me if I'm wrong)
uses copy-on-write all over the place.  The programmers' references
mention copy-on-write in many places (at least the 2.x documentation does,
but that's for a 680[34]0).

-- 
===============================================================================
Jay Finger - finger@convex.com        | Convex Computer Corp
CONVEX System Integration and Support | 3000 Waterview Parkway
Product Specialist                    | Richardson, TX 75080
Xref: sparky comp.arch:11705 comp.sys.intel:2734
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 13 Dec 92 16:43:48 GMT
	<1992Dec8.000357.26577@newsroom.utas.edu.au>
	<PCG.92Dec9154602@aberdb.aber.ac.uk>
	<1992Dec9.211737.23911@walter.cray.com> <Bz25n0.202@metaflow.com>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 10 Dec 92 19:18:35 GMT, rschnapp@metaflow.com (Russ Schnapp) said:

rschnapp> (Bradley R. Carlile) writes:

Bradley> The limit of 4 or 6 may be the limit programming a superscalar
Bradley> chip like by simply letting the the chip group instructions
Bradley> together.  *However* if one uses the technique of software
Bradley> pipelining like we used to use on the VLIW machines of
Bradley> yesteryear FPS-120B (before 1976), FPS-164, and the FPS-264
Bradley> (1985?).  These machines could issue up to 10 instruction every
Bradley> cycle {I wrote software for 7 years that used these
Bradley> instructions}.

rschnapp> Don't forget about out-of-order (i.e., dataflow) execution
rschnapp> techniques.  You can gain plenty of additional fine-grain
rschnapp> parallelism.

Ah, there are indeed many interesting tricks to support high levels of
micro parallelism *in the implementation*. To me the really interesting
problem is not how to do it, though, it is whether it is worth doing it,
and for which classes of codes.

I have yet to find evidence that *general purpose* codes have an
intrinsic degree of micro parallelizable operation (let's call it
superscalarity) that makes it worthwhile to have a degree of parallel
*instruction issue* within a single stream not greater than 2-4.

  The codes that can be easily micro-parallelized are usually *special
  purpose*, in that they have a structure (e.g.  FIFO reference patterns)
  that are best suited to a SIMD/vector processor approach.

Otherwise *general purpose* codes have a degree of macro parallelism
(let's call it multithreading) that can be best exploited with multiple
CPUs, and that can exploited up to a degree of parallel *instruction
streams* with independent contexts not greater than 2-4 (again).

  Then are are codes that can be easily macro-parallelized, and these
  are again *special purpose*, in that they have a structure (e.g.
  LIFO reference patterns) that are best suited to a MIMD approach.

Naturally all this depends on how you define a "code"; for example a
timesharing system might be considered a single, highly parallelizable
code, or as a collection of fairly hard to parallelize different codes.
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta
Newsgroups: comp.arch
From: dfox@quack.sac.ca.us (David Fox)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 19 Dec 1992 17:15:45 UTC

>|>> So far, the most "open" system I can think of is a 386 running DOS:
>|>> - systems available from all sorts of people
>|>> - CPU's available from (at least) AMD, Intel, IBM, and Cyrix

I don't agree.  For a system to be open requires it not to be
proprietary.  Of course, 386s running DOS are a lot more 'open' than 
Macintoshes, for example.  But Unix (or at least _some_ unixes) foster
a much more open environment because source code to many things is
usually provided.  For example, your choices for a C compiler are
plentiful, but that depends on how much $$ you are willing/able to
shell out to the various software writers to try those compilers out.
With Unix, one can get gcc for free, including source.

IBM was very open when they published the source code to the
PC BIOS.  However, that openness was short lived, and the PC started
becoming more and more proprietary.  

In my opinion, license agreements, non-disclosure agreements, and
trade secret information just doesn't make for 'openness.'

>UNIX is a single user system too. The only evidence of a multiuser capability 

Huh?  Unix has always been a multi-user system.  I run Unix on a
386SX/16 and have had two additional users doing other things online.
If that isn't multi-user, I don't know what is.

>I would guess that W/NTs single user functionality should outstrip that of UNIX
>fairly easily. I bet that in '94 or whenever Microsoft will be comming out with

I don't see that.  Maybe by 1998, DOS will come with a 'dd' command.
>being able to offer additional functionality.
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 14 Dec 92 08:57:14 MDT
Organization: Utah State University

In article <1992Dec12.143116.17635@infodev.cam.ac.uk>, rf@cl.cam.ac.uk (Robin Fairbairns) writes:
> In article <endecotp.723992157@cs.man.ac.uk>, endecotp@cs.man.ac.uk (Phil Endecott) writes:
> |> Can anyone think of a use for the branch if even and branch if odd
> |> instructions on the Alpha?  I'm completely baffled.
> 
> It's a VMS-ism.  All VMS routines return a completion code.  If it's
> odd, the routine succeeded (and there are oodles of ways it can
> succeed, sometimes); if it's even the routine failed.
> 
> All very smooth and neat - VMS has some dinkum ideas in there if you
> pay attention.

Incidentally, I noticed a while ago that the ASCII code for 'Y' is odd and
for 'N' is even; that is, on VMS, ask a Yes/No question and test the low bit...
-- 

Roger Ivie                      "My God! That computer is full of Pentium!
ivie@cc.usu.edu                  It's a wonder that you haven't been turned
                                 into mutants!"
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: UIUC SCS
Date: Sat, 19 Dec 1992 16:55:40 GMT

In article <1992Dec19.012355.26665@ll.mit.edu> ejon@ll.mit.edu (Eric Jones) writes:


>But isn't that exactly his point?  Sure you can write an ISAM file 
>structure using fseek (and if you're REALLY smart, you might even
>write an efficient one), but then how's anyone else going to use
>your files?

By RTFM of course!!

Consider the converse: 

You write a file using the oddball formats of VMS.

You send it to someone else.

He can't read it because it's oddball.

How does he read it??
The only way is to RTFM and here the FM refers to the 1600 pounds
of VMS stuff or Disk 47 of the 677 volume CD manuals.

The Unix way has proven to be the best way; its one of the biggest
reasons VMS is a current sales disaster.

The doc for your own ISAM is maybe 2 pages long.

Also consider this: if you write that file on VMS using the VMS
proprietary method, you can't read it on any other machine using
the same code. If you did it the C/Unix way, you code will run as-is
on any machine using standard C. Even VMS. 

Doug McDonald
Newsgroups: comp.arch
From: keiths@cae.wisc.edu (Keith Scidmore)
Subject: Alpha Architecture Quirks
Organization: College of Engineering, Univ. of Wisconsin--Madison
Distribution: usa
Date: 14 Dec 92 07:29:41 CST
Keywords: Alpha 21064

Can any of you DEC people on the net answer the following 21064-AA Alpha 
Questions?  You can mail your replies or post them if I have my facts
wrong or you feel the need to continue this thread.

1)  I read that the 21064 divide unit is not pipelined and takes one cycle 
    per bit to produce a result.  Isn't this going to kill floating point
    performance?  FP constants can be converted by the compiler but
    what about the rest of the divides?  Doesn't the scoreboard have to stall
    for 64 cycles to get the result of a divide with data depenencies?  I'm
    lead to think that DEC isn't interested in the FP performance of this chip,
    or do I have my facts wrong?

2)  The 21064 has no integer divide.  Again, isn't this going to make math
    performance poor.  Integer constants can be converted to multiplies
    but this is only a partial solution.

3)  The manuals say that the 21064 is superpipelined.  Where?  How can this
    claim be justified in light of the floating point divider not being
    pipelined at all?  It seems to me that all issues are superscalar but
    that there is no superpipelining.

4)  In one place I'm sure I read that all memory accesses are 64-bit yet
    there are provisions for long word writes discussed elsewhere (in
    multiprocesor environments, for example).  Which is it?

Thanks in advance.

Keith R. Scidmore


P.S.  I cancelled two earlier versions of this article that were mangled.
I hope it worked.
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Keith's Computer, Hope Mills, NC
Date: Sun, 20 Dec 92 16:10:18 GMT

In article <BzGn32.37C@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>There were other choices. PICK for instance was a very highly regarded system
>but was killed through over agressive attempts to control it. Imagine a world in
>which EBSIDIC, not ASCII was the standard for charaters. We would see people
       ^^^^^^^
EBCDIC maybe, what is EBSIDIC?

And, EBCDIC has some superior features to ASCII, Especially when
converting Zone Style (string) and Packed (BCD) numbers into printable
characters and back.

IBM shops have been using EBCDIC for 30 years.  It *IS* a standard for
them, and the S/36 enviroment we use on our SCO UNIX box does everything
EBCDIC also.  There are some interesting searching & sorting impacts
from using EBCDIC also.

>praising the merits of the EBSIDIC standard as if the deliberate convolutions of
>the system were an advantage rather than a serious drawback.

here is no SERIOUS drawback to EBCDIC.  None, other than compatability
with ASCII systems.  There are also some advantages with business
applications.  EBCDIC was no "deliberate convolution", and when you look
at the BINARY representation of the codes *AND* the way numbers are
represented on the IBM style RPG/COBOL/... systems it begins to make
very good sense.

I grew up on ASCII and used EBCDIC later, and while I generally use
ASCII now whenever possible, this is more for portability reasons,
rather than because it is "BETTER" in any way.  Be real.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Xref: sparky comp.arch:11818 comp.sys.dec:6569 comp.sys.sgi:18239 comp.sys.hp:14271
From: tmm@asns.tredydev.Unisys.COM (Tim McCaffrey)
Newsgroups: comp.arch
Subject: Re: [Anet: Compaq Proposal]
Date: 18 Dec 92 19:09:22 GMT
Organization: Unisys Corporation, Devon Engineering Offices

Silly me, after seeing the proposal go by four times you think I would 
save one.  Oh well, from memory:

You talk about "hot" insertion.  How do you go about notifying system
 / application software that the device is now available.  Assuming
you are talking about something a little more sophisticated than DOS
or Windows, you may want to know when a device goes online/offline.

What is the byte order for the address information?  (so much for
no little/big endian issues).

How do tell one device from another?  Will a device always have the
same address no matter what slot is in?  Will the same slot always
the same address (range)?  What happens when I pull out my modem and
insert a hard disk (bye, bye data?).

Obviously, these are mostly software issues, but the hardware needs
to be designed so that the software does not become cumbersome.

If you use this interconnection scheme for loosely linking CPUs:
Above problems with hot insertion, as well as possible security
issues (having one CPU being able to cruise through another
system's memory space is not exactly secure).

Nice idea, but you are not dealing with a DOS (simple, single user,
single tasking) world anymore.  For example, think of the issues
you would have to deal with to remove an active, but flaky modem
module, and insert a good one.  You would have to reinitialize and
have it pick up the data link more or less where you left off.
Again, lots of software issues here, but the hardware needs to 
be able to tell the software:  1) the modem module was pulled,
2)  Another module was installed, 3) it is not the same module,
but is compatible.

Good luck..
					Tim McCaffrey