HDTenEightyP/NetNews huggingface dataset:
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Interrupts vs Polling---WAS: cooling
Date: 27 Aug 92 11:49:05 MDT
Organization: Utah State University

In article <BtMC8n.B6H.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> It *is* sometimes important to get fast notice of cooling failure.
> Some systems, stopped abruptly, get hot enough to damage themselves.
> Their power-fail sequence tries to have residual power, not for the
> CPU or disks, but for the fans/pumps.

While I hate to inject folklore into comp.arch, the local university 
had a power failure a while ago. While all the machines kept running on
the UPS, the air conditioner for the machine room did not (it had been
left off the UPS), so they had to shut down.

Roger Ivie
ivie@cc.usu.edu
Newsgroups: comp.arch
From: John@boole.uucp (John Ahlstrom)
Subject: Re: Indexing in microprocessors
Organization: Boole & Babbage, Inc.
Date: Wed, 2 Sep 1992 21:18:39 GMT

In <08jn8-q.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:

>ugurdag@ces.cwru.edu (Fatih Ugurdag) writes:


>>Is there any microprocessor in which we can access registers in an
>>indexed fashion such as

>>"store source_register,register[index_register]"
>>if index_register holds the value of 3 then this becomes
>>"store source_register,register3"
>>This way we can support array operations in the register file.

>I think several pdp computers (including the pdp11) had this
>capability as the registers could be addresses as memory locations.
>-- 
>Dave Feustel N9MYI <feustel@netcom.com>
> 
>( New .sig under construction. Watch this space! )

I know the PDP-10 used the first 16 mem addrs as the names of the
16 registers.  I don't remember that about the pdp-11.

I believe the amd29000 has some such facility but I don't have
the reference handy.  Anyone else know about it?

John Ahlstrom
Boole & Babbage
I cannot confirm or deny whether my opinions are shared
by anyone else.  (Where did I plagiarize that from?)
From: mcvey@mpr.ca (Iain McVey)
Subject: Large gas-plasma displays
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Tue, 1 Sep 92 00:10:41 GMT

Several months ago, I heard of a company producing very large gas-plasma
computer displays.  They were on the order of meters x meters in size.

If you know of the company producing them, please drop me a line.

- Iain -
-- 
Iain McVey (mcvey@mpr.ca)    | Kodachrome, gives us those nice, bright colours,
Software Designer            | Gives the greens of summers,
MPR Teltech Ltd.             | Makes you think all the world's a sunny day.
8999 Nelson Way, Burnaby, BC | - Paul Simon
Newsgroups: comp.arch,comp.parallel
From: fineberg@nas.nasa.gov (Samuel A. Fineberg)
Subject: CM-5 Vector Units
Apparently-To: comp-parallel@ames.arc.nasa.gov
Reply-To: fineberg@nas.nasa.gov
Organization: CSC, NASA Ames Research Center, NAS Division
Date: Thu, 3 Sep 92 18:59:03 GMT

I am interested in finding some information on the CM-5 Vector units that 
were announced at HOT-CHIPS.  Is there a paper that goes along with the
talk?  Is there anything else available?  I will post a summary of any
responses.

Thanks,
Sam
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Indexing in microprocessors
Date: 3 Sep 92 13:02:17 GMT
Organization: Purdue University Statistics Department

In article <MOSS.92Sep2221832@ibis.cs.umass.edu> moss@cs.umass.edu writes:
>Computers that store the registers in memory can do the indexing, including
>the PDP-10 (and 20, but *not* the PDP-11), some Honeywell machines
>(predecessors to the Multics line), and the TI 9900. Some register window
>mechanisms may let you do this (sort of), but most processors do not seem to
>do it in the manner you have described. Some machines could get that effect by
>building and executing an instruction, or having an "execute" instruction.

Storing the registers in memory is neither necessary not sufficient.  The
9900 does store the registers in memory, but the indexing is a memory access
indexing, not a register indexing, and runs accordingly.  

On the other hand, the Univac 1100 series, at least some of them, had the
first 200 octal addrsses as registers, and the indexing could be done with
little time penalty.  With the essential demise of code modification at 
run time, the lack of register indexing makes the use of register vectors
quite difficult.

Using an execute instruction would probably be slower than using memory.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
From: djaggar@armltd.uucp (Dave Jaggar)
Newsgroups: comp.arch
Subject: Configurable/Switchable Endianess
Date: 26 Aug 92 09:20:51 GMT
Distribution: comp
Organization: Advanced RISC Machines Ltd

I am interested in microprocessors that are able to execute code, or
process data in either endianness, and how they achieve this.  For
instance the ARM6 family of CPUs have a pin or a bit in a system
register (depending on the model), which sets the endianness of the
processor, by determining which byte is selected off the data bus for
byte load/store operations.  The MIPS R3000 has a pin that you set at
reset, but what does this do internally (affect byte ops or word ops) ?
Is it the same on R6000, R4000xx ? The ATT Hobbit has switchable data
endianness (how do you switch ?), does this mean that the endianess of
code is fixed ? Does anyone implement a "load data of the other
endianness instruction" ?

Please post or mail replies, I'll summarise. 
Thanks,
Dave

--------------------------------------------------------------------------
Dave Jaggar					Advanced RISC Machines Ltd
djaggar@armltd.co.uk				Swaffham Bulbeck
Phone: +44 223 813 000 Ext 210			Cambridge CB5 0NA
Fax: +44 223 812 800				England
--------------------------------------------------------------------------
Newsgroups: comp.arch
From: bret@technix.mn.org (Bret Indrelee)
Subject: Re: 32 => 64 Transition
Organization: Private System - Saint Paul, MN
Date: Sun, 23 Aug 1992 16:28:14 GMT

In article <mcdonald.235@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>In article <l9b1usINN2aj@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>
>>    sizeof(INTEGER) = sizeof(REAL) = sizeof(DOUBLE PRECISION)/2.
>
>
>And indeed this is still very much true in Fortran 90.
>
>>A corollary of this is that there had better be a 32-bit integer data
>>type in C, unless your hardware implements quad-word floating point.
>
>Don't you mean the your machine needs it for **Fortran**?? That of course
>essentially decies the issue, as Fortran is still very much alive ...
>especially for high-end machines. Fortran 90 is probably more or less dead,
>but not Fortran 77, which remains a standard. That latter is very 
>important .... Fortran 90 is such a botch that to get it passed Fortran
>77 had to remain an official standard.

The initial statement (there had better be 32-bit integer in C) is correct.
Some people like to mix languages, calling a C routine from Fortran.  I
suppose the opposite is occasionally done as well, but from what I've seen
the common case is Fortran calls C.

No language is perfect.  It is a good idea to allow mixed language development
without unneccessary hassles.

-Bret

-- 
------------------------------------------------------------------------------
Bret Indrelee               |   Pretend there is something profound
email: bret@technix.mn.org  |   written here.
Newsgroups: comp.arch.storage,comp.databases
From: vanepp@fraser.sfu.ca (Peter Van Epp)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Tue, 1 Sep 1992 23:45:22 GMT

vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:

>I need to design a retrieval system for ~15TB of data, of which ~5TB are
>retrieved with a high frequency (25 requests/second) and an access time
>of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
>5TB are real random-access. The rest of the data is still accessed at a
>rate of 5 requests/second. Here, too, access is completely random.
>So far I've come up with the following ideas:

>1) Use large (10GB) WORM jukeboxes with many pickers (~40),
>   many drives (~150) and a *real* intelligent scheduler. No cache.

>2) Use 1) for the less-often-retrieved data, and several 625MB-OD
>   jukeboxes with even more drives and a less intelligent scheduler.

>I figure that doing some 25 media changes a second would be a real
>performance killer. Due to the response time restrictions (30 seconds)
>there is hardly a chance to build a decent queue for pending requests
>and schedule them appropriately.
>So what we really need is 5TB of something like a huge, if slow, hard disk.
>Is there any such kind of device? Any other ideas? Any help?

>Any kind of information is greatly appreciated (hints, pointers, ideas, etc.)

>--
>Volker Herminghaus-Shirai (vhs@rhein-main.de)

Seeing all other expensive solutions being proposed, have you looked at
Creo's optical tape units? Capacity is around a terabyte I believe, and 
access time is said to be 1 minite for the whole tape. The drives are 
however in the $250k range I believe. Since Creo is in town here send
e-mail if you need an address.

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
From: chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh)
Newsgroups: comp.arch.storage
Subject: Questions on Tape Drives
Date: 28 Aug 92 21:08:43 GMT

Hi, 

I have two questions on tape drives. Hope someone on the net can enlighten me.

1) Although tapes are cheap, but tape drives are more expensive than disk drives.
    Why is this the case? Also could someone tell me what is the breakdown of a
   tape drive's cost. For example, the tape transport mechanism, the R/W head, 
   and the A/D & DSP elctronics.

2) The "position angle" of a tape head with respect to a tape in 4mm and 8mm 
   tape drive is 90 and 200+ (?) degrees, but is 0 degree for linear scan tapes.
   Can someone explain what is the design consideration for this ? 
   Also, does this mean that for 4mm and 8mm tapes, the head must touch the tape
   during read/writes?

Thanks.

Tzi-cker
Xref: sparky comp.arch.storage:622 comp.databases:6529
From: mao@triplerock.CS.Berkeley.EDU (Mike Olson)
Newsgroups: comp.arch.storage,comp.databases
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Date: 3 Sep 1992 16:23:24 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: triplerock.cs.berkeley.edu

In <1992Aug29.210553.8744@rhein-main.de>, From: vhs@rhein-main.de
(Volker Herminghaus-Shirai) writes:

> I need to design a retrieval system for ~15TB of data ...
> 
> Any kind of information is greatly appreciated (hints, pointers, ideas, etc.)

my master's work at berkeley was on how to incorporate tertiary storage
into a database system cleanly.  i changed a bunch of internal interfaces,
defined a new abstraction like the file system switch, and added support
for a 327 gigabyte sony optical disk worm jukebox.

under this architecture, the database system manages the tertiary storage
device directly, rather than using an external file system interface to
it.  the advantage is that the dbms can make intelligent clustering,
caching, and prefetching decisions, and can consider optical device
performance characteristic (like very long pick times) when it optimizes
a query.

the jukebox storage manager uses a magnetic disk cache and extent-based
allocation to speed up accesses to data.

a description of the architecture is included in the postgres papers,
available by anon ftp from postgres.Berkeley.EDU (128.32.149.1) in
pub/postgres-papers.tar.Z.

this won't answer all your questions; in particular, you would have to
figure out clustering and caching policies to guarantee the performance
bounds you list.  it may help you out in identifying problems with these
devices and things you need to think about if you're designing your own
storage manager.
					mike olson
					project sequoia 2000
					uc berkeley
					mao@cs.berkeley.edu
Newsgroups: comp.arch.storage
From: wtchang@csie.nctu.edu.tw (Wen-Tsung)
Subject: Need info on current FIFO RAM devices
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: Tin 1.1 PL5
Date: Thu, 3 Sep 1992 02:06:17 GMT

  I would like to get some information on currently developed FIFO RAM devices, such as production factory, product number, access time, storage size, ... etc

  Thanks.

                                              Eric.

E-mail : wtchang@csie.nctu.edu.tw
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.arch.storage
Subject: Re: Questions on Tape Drives
Date: 1 Sep 92 01:30:56 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <44671@ucbvax.BERKELEY.EDU> chiueh@sprite.Berkeley.EDU (Tzi-cker Chiueh) writes:
| I have two questions on tape drives. Hope someone on the net can enlighten me.
| 
| 1) Although tapes are cheap, but tape drives are more expensive than disk drives.

It isn't, except for the very smallest disks, or the most expensive tape
drives (most 9 track's, for example).

|     Why is this the case? Also could someone tell me what is the breakdown of a
|    tape drive's cost. For example, the tape transport mechanism, the R/W head, 
|    and the A/D & DSP elctronics.
| 
| 2) The "position angle" of a tape head with respect to a tape in 4mm and 8mm 
|    tape drive is 90 and 200+ (?) degrees, but is 0 degree for linear scan tapes.
Yes, it is the difference between helical scan and linear drives.  The
helical scan moves the tape slowly, but has a rapidly rotating head
(on a drum).  It makes the tape transport simpler and more reliable (in theory)
for a given data density.

|    Also, does this mean that for 4mm and 8mm tapes, the head must touch the tape
|    during read/writes?

Yes, which is also the case for QIC.  Well, it doesn't actually touch
the *head* (in either case), but it contacts the 'shell' around the
heads.
--
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
From: bzs@ussr.std.com (Barry Shein)
Newsgroups: comp.arch.storage
Subject: Re: Info on flopticals?
Date: 30 Aug 92 06:55:02 GMT
Organization: The World


I heard of these from someone who works on the biz, I believe there
was even some sort of standards committee for them.

I'm not sure if it was mag media + optical or CD/ROM + rewriteable
optical on the same disk, but part of the disk was definitely RO and
part RW.

It didn't impress me as that hot an idea, but I guess the motivation
was that you would have the software for some package on the disk and
be able to put your work in that package on the same disk.

I dunno, sounds overly "modular" to me, except perhaps as some sort of
turnkey delivery system (e.g. the software for a router with network
stats dribbled onto the writeable portion, or maybe a printer with
installed software and some fonts, and you can download more fonts
onto the writeable portion after installation, something like that,
actually, that's not a bad application come to think of it.)


--
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
Newsgroups: comp.arch.storage
From: nondas@kfk.de (Nondas Kapetanios, IAI, Zi. 237, Tel. 5743)
Subject:  Information for mass storage systems. 
Reply-To: nondas@kfk.de
Organization: Institute of Applied Informatics/Nuclear Research Center-Karlsruhe (Germany)
Date: Thu, 3 Sep 1992 08:18:20 GMT



Hello,

we want to come in contact with vendors providing mass storage systems suitable for accomodating
at least 3-4 TBytes and at most 10-12 TBytes. Addresses, telefon numbers or email-addresses are
useful. We would also like to know about the software data management provided by each environment.
Especially, environments that can support UniTree or any other system approaching the IEEE reference
model for mass storage systems. 

Any responses, please, to my email-address:  nondas@kfk.de

Thank you very much in advance

Sincerely 
Epaminondas Kapetanios

Newsgroups: comp.arch.storage,comp.databases
From: chip@osh3.OSHA.GOV (Charles Yamasaki)
Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
Organization: U.S. D.O.L - Occupational Safety & Health Admin.
Date: Thu, 03 Sep 1992 03:37:36 GMT

In <22302@venera.isi.edu> rod@isi.edu (Rodney Doyle Van Meter III) writes:

>In article <1992Aug31.043738.19685@psg.com> randy@psg.com (Randy Bush) writes:
>>vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
>>
>>> I need to design a retrieval system for ~15TB of data, of which ~5TB are
>>> retrieved with a high frequency (25 requests/second) and an access time
>>> of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
>>> 5TB are real random-access. The rest of the data is still accessed at a
>>> rate of 5 requests/second.
>>
>>Optical RW store, a la HP.
>>-- 
>>randy@psg.com   ...!uunet!m2xenix!randy

Any more info on the optical jukebox scene?  I need to provide backup
for as many as 20 networked Unix systems with an average of about 1GB
each.  I'd like to be able to do a complete backup of all the systems
overnight.  The whole thing must be able to operate completely
unattended and should have multiple drives to help reduce contention. 
Of course, with this I'm going to need backup software that will support
multiple platforms (NCR SVR4 and SCO SVR3.2.4).

I realize I could use a tape jukebox and probably save some money, but
I'm hoping to be able to use this as large scale on-line (albeit slow)
storage as well.  Granted, I haven't checked if SCO or NCR can support
optical as mounted filesystems.

Sorry to stray from the original topic, but there seemed to be such a
pool of expertise here I couldn't resist.
-- 
-----------------------+---------------------------------------------------
Charles "Chip" Yamasaki| The opinions expressed here are my own and are not
chip@osh1.OSHA.GOV     | supported or even generally accepted by OSHA. :-)
-----------------------+---------------------------------------------------
From: dingbat@diku.dk (Niels Skov Olsen)
Newsgroups: comp.arch.storage
Subject: Info on flopticals?
Date: 25 Aug 92 09:57:28 GMT
Organization: Department of Computer Science, U of Copenhagen

Some time ago I heard somone mention somthing called flopticals (or 
something similar), which is a combination of a magnetic and optical
media. The capacity was mentioned to be 20mb (even more later) with 
access time as harddisks a few years ago, and normal 3.5" floppy 
package.

I haven't heard anything about it since, so if anyone could point
me to articles, tests, or even pruduct information I would be most
gratefull.

Thanks,

Niels
From: ajc@pa.dec.com (AJ Casamento)
Newsgroups: comp.arch.storage
Subject: Re: Info on flopticals?
Date: 27 Aug 92 14:58:49 GMT
Organization: Digital Equipment Corporation




In article <1992Aug25.095728.20697@odin.diku.dk> dingbat@diku.dk (Niels Skov 
Olsen) writes:


>> Some time ago I heard somone mention somthing called flopticals (or 
>> something similar), which is a combination of a magnetic and optical
>> media. The capacity was mentioned to be 20mb (even more later) with 
>> access time as harddisks a few years ago, and normal 3.5" floppy 
>> package.

>> I haven't heard anything about it since, so if anyone could point
>> me to articles, tests, or even pruduct information I would be most
>> gratefull.

>> Thanks,

>> Niels

Niels,

  The only "Floptical" I know of is a product by Insight Peripherals (I think
maybe they are in Fremont, CA). It's not really a combination of magnetic and
optical media, but rather a combination of magnetic and optical technology.
They use a standard floppy magnetic media, but they use laser optics for both
tracking and positioning. This is where the data density and access times are
a win. I believe that they can write 20MB of data on a 3.5" floppy and that
they can read (but not write) a standard DOS floppy.

  I remember seeing something in the San Jose Mercury News business section a
few weeks ago to the effect that 3M was going to market this technology (I 
would assume with their media).

  Anyway, that's how I understood the technology. I apologize if any of this
turns out to be in error, it was quite a while ago that I was looking at it.

I hope that helps.

				Thanx,
				  AJ

ps. Wasn't SONY supposed to be out this summer with a 3.5" form factor CD that
    was write-able and could record up to 70min of music? Or is my mind failing
    again?


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************
From: hal@eecs.cs.pdx.edu (Aaron Harsh)
Newsgroups: comp.arch.storage
Subject: Credit card sized media
Date: 2 Sep 92 21:30:01 GMT
Article-I.D.: pdxgate.6055
Organization: Portland State University


  I know that storage media the size of credit cards exist, but no press is
ever given to any forms except flash memory.  In particular, I recall seeing
an ad for small rectangular optical memories that could hold 1-2MB.

  Can anyone point me to a company that manufactures these (or any other
permanent memories of this size)?


Aaron Harsh
hal@eecs.cs.pdx.edu
Newsgroups: comp.arch.storage,comp.databases
From: ajc@pa.dec.com (AJ Casamento)
Subject: Re: Info on flopticals?
Organization: Digital Equipment Corporation
	<AJC.92Aug27095849@thendara.pa.dec.com>
	<1992Aug28.025724.18833@msc.cornell.edu>
Date: 28 Aug 92 12:43:29


Maynard Handley <maynard@groo.msc.cornell.edu) writes:

>>I remain mystified as to why anyone would want to buy these things.

Personally, I think they're a bridge/hold-over. With the tons of PC products
in the world people got really used to using sneaker-net to move data and "fun"
programs from machine to machine.

As the capacity of these machines continues to increase the need for higher
volume distribution and back-up media has been increasing. But people STILL
want to play sneaker-net to the old machines (a lot of the PCs have never been
near a network in their lives, and many of the home machines have never really
needed one). 

Now using a series of 20MB floppies may not be the cleanest installation you
can think of, but most of the installs that I can easily think of (including
an OS) could pretty readily be done in under 15 floppies. And most would be
under ten. I think a lot of folks are willing to live with that level of pain
to be able to read PC floppies in the same drive.


Personally, I think that the newer 3.5" Magneto/Opticals are a better bet. But
I don't think they'll pick up fast enough. Now, if somebody was to be smart
enough to add the firmware to be able to read a CDROM (the optics are the same
but the format is different so it requires additional firmware...at least that
is what Pioneer told me about modifying one of their drives). Then you'd have
to get the software folks to start using the 3.5" size for their CDROMs. But, I
think that would be an overall win. And I think the resulting volumes would be
enough to really pull the media costs for M/O into line. IMHO, of course.

				Thanx,
				  AJ

	
      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************