HDTenEightyP/NetNews huggingface dataset:
From: elm@cs.berkeley.edu (ethan miller)
Newsgroups: comp.arch.storage
Subject: Re: Holocube storage (?)
Date: 15 Aug 92 18:18:12 GMT
Reply-To: elm@cs.berkeley.edu
Organization: Berkeley--Shaken, not Stirred
NNTP-Posting-Host: terrorism.cs.berkeley.edu
In-reply-to: opus@pioneer.unm.edu's message of 15 Aug 92 14:46:13 GMT

In article <_t7mh8b@lynx.unm.edu> opus@pioneer.unm.edu (Colby Kraybill) writes:
=> The subject of a storage device being researched that 
=> stored data in a three dimensional cyrstaline cube.  I believe that it
=> was supposed to be built by a company called MCC.  Storage compacities
=> were estimated into the Terabyte range with access times close to that
=> of say a 120ns RAM chip.

Check the proceedings of the 11th IEEE Mass Storage Systems Symposium.
The reference for the article is:

@inproceedings{holostore:redfield,
 title	= "Holostore Technology for Higher Levels of Memory Hierarchy",
 author	= "Steve Redfield and Jerry Willenbring",
 booktitle = msstitle,
 organization = mss11,
 month	= oct,
 year	= "1991",
 pages	= "155-159"
}

ethan
--
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
ethan miller--cs grad student   | "Anybody not wearing 2000000 sunblock's
elm@cs.berkeley.edu             |  gonna have a REALLY bad day.  GET IT?"
#include <std/disclaimer.h>     |  -- Sarah Connor, _Terminator 2_
Newsgroups: comp.arch.storage
From: kalyani@jpl-devvax.jpl.nasa.gov (Kalyani Rengarajan)
Subject: Need info on archive servers
Organization: Jet Propulsion Laboratory (NASA)
Date: Thu, 20 Aug 1992 18:30:37 GMT

Hi,
	Thanks for your responses on archive servers. I am interested
in the following servers: 
	AMASS  from Computer Upgrade Corporation, EPOCH, NETSTOR from
ZETACO, CommVault from AT&T, DFDSM from IBM and any other servers.
	I am looking for information such as: expandability, reliability,
ease of use, and performance etc. Any experience would be most
appreciated. I will summarize if there is any interest shown.


Thanks
Kalyani
From: tomv@cssc-syd.tansu.com.au (Tom Vasak)
Newsgroups: comp.arch.storage
Subject: WORM drive comparison wanted
Keywords: WORM, optical
Date: 14 Aug 92 05:33:06 GMT
Organization: Customised Software Solutions Centres, AOTC

I am looking for a critical comparison of various WORM optical disk drives.
I'm interested both in technical aspects (capacities, transfer rates, MTBF)
as well as real world experiences of performance and reliability.
 
Can anyone help?
 
-------------------------------------------------------------------------------
Tom Vasak
Telecom Australia
   
Email:            tomv@cssc-syd.tansu.com.au
Voice/VoiceMail:  +61 2 395-3223
Newsgroups: comp.arch.storage
From: teddy@proxxi.se (Teddy Hogeborn)
Subject: MS-DOS drivers for IDENTIDA Tape drive??
Summary: Need MS-DOS drivers for IDENTICA Tape drive.
Keywords: TAPE IDENTICA
Organization: proxxi
Date: Thu, 20 Aug 1992 23:40:56 GMT

I've come across a tape drive marked IDENTICA, with some kind of 8-bit PC card
to go with it. No drivers or any cable. Could someone please describe the kind
of cable needed and perhaps email an uuencoded driver for it?
The tape drive has a female 25-pin connector and the card has one 9-pin male
connector and one 25-pin female connector. It also has some cables going from
the card itself to two other ports: one femal 15-pin connector and a male 25-
pin connector. Hope this helps. Oh, and the tape drive fits 'standard' (As
I have been made to know) cassettes, that is 15*10*1.5 cm.

Noone imports these things anymore, so I hope there is someone who can help me.

Mvh Teddy
    80087
From: finger@convex.com (Jay Finger)
Newsgroups: comp.arch.storage
Subject: Sector sizes over 1024 bytes?
Date: 18 Aug 92 19:49:39 GMT
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
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.


Can the NeXT work with drives with sector sizes over 1024 bytes?  4096,
8192 for example.  Has anybody tried it?  Do you gain anything speedwise?


-- 
===============================================================================
Jay Finger - finger@convex.com        | Convex Computer Corp
CONVEX System Integration and Support | 3000 Waterview Parkway
Product Specialist                    | Richardson, TX 75083
Newsgroups: comp.arch.storage
From: kalyani@jpl-devvax.jpl.nasa.gov (Kalyani Rengarajan)
Subject: Archive Servers
Organization: Jet Propulsion Laboratory (NASA)
Date: Wed, 12 Aug 1992 15:25:10 GMT

Hi
	I am looking for information on archive servers. Any help would be
appreciated.
Kalyani
Newsgroups: comp.arch.storage
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Open letter to Dave Olson, SGI [was SCSI vs. IPI]
Date: Mon, 17 Aug 1992 15:49:27 GMT
	<ADAMS.92Jul16014945@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<BrH2sz.5qM@csn.org>
	<ADAMS.92Jul16125743@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<nch5oa8@zuni.esd.sgi.com> <ADAMS.92Jul17162917@PDV2.pdv2.fmr.maschine
	<PCG.92Aug6153327@aberdb.aber.ac.uk>
	<ADAMS.92Aug6211332@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
	<obj29js@zuni.esd.sgi.com>
Organization: TH-Darmstadt


We should have met the holder of the copyright, frank bernard,
"bernard@sgi1.fmr.maschinenbau.th-darmstadt.de", last week, but could not. 

>So could you include the relevant chunk of code?  It shouldn't
>be more than 10-25 lines of code.  If you can't do that, how
>about some pseudocode?  Was the code in C, Fortran, or something
>else?  Did anybody ever trace the system calls to be sure that
>the I/O was really in large chunks (some fortran I/O statements
>go through some really slow library code, depending on what
>arguments are used)?

So I am not allowed to distribute parts of his code ;-<. Code was
writtten in "C".

>I've still, after almost 2 weeks, been unable to find ANYBODY
>in SGI (in Mt. View, CA, or in Europe), who admits to knowing
>anything about this.  Could you please give me some more
>names of people involved, or at least the phone #'s of the
>offices you talked to?

Frank Bernard has gathered everything in a file .....
I have mailed him to forward all information to you.

Sorry not beeing able to give you more assistance ....

best adams




Newsgroups: comp.arch.storage
From: davidc@meaddata.com (David Ciaciuch)
Subject: Archiving/migrating experiences
Organization: Mead Data Central, Dayton OH
Date: Thu, 20 Aug 1992 20:01:36 GMT

I'm in the market for an archiving/migrating subsystem.  I know of the
Epoch and TOFS.  I've heard of the Amass and Q-star products but don't know
too much.  What I'm looking for are any/all practical experiences re: any
of these products, whether they be "I currently own the ..." or "I evaluated
the ...".  I'll summarize if warranted.  Thanks in advance for any info.

Oh yeah, my configuration consists of 18 Sun 4/690s with an aggregate total
of ~60GB to manage.

-- 
David L. Ciaciuch                                     Engineering Productivity
Mead Data Central                                         (513) 865-6800 x6524
P.O. Box 933                                               davidc@meaddata.com
Dayton, OH  45401                                    ...!uunet!meaddata!davidc
Newsgroups: comp.arch.storage
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: HELP: Tape Drive Interface
Organization: Curtin University of Technology
Date: Mon, 17 Aug 1992 16:10:15 GMT

In article <1992Aug2.172615.1@vx24.cc.monash.edu.au>, eda918msft@vx24.cc.monash.edu.au writes:
...

Detail deleted... Its a Cypher 880 Micro Streamer. Formated interface. Allmost
any controler you get will talk to it. They are a good little unit, if you
don't mind 1600 bpi. Mail to ZCOOKBRUC@CC.CURTIN.EDU.AU for help, he has my
manuals... :-) There should be 69k people arround Monash who can help you
out on this one.

~Paul



Newsgroups: comp.arch.storage
From: opus@pioneer.unm.edu (Colby Kraybill)
Subject: Holocube storage (?)
Date: Sat, 15 Aug 92 14:46:13 GMT
Organization: Space and Planetary Image Facility


 
 
 A few years ago I was watching the Computer Cronicles on the local PBS
 station here.  The subject of a storage device being researched that 
 stored data in a three dimensional cyrstaline cube.  I believe that it
 was supposed to be built by a company called MCC.  Storage compacities
 were estimated into the Terabyte range with access times close to that
 of say a 120ns RAM chip.
 
 Please send e-mail on any information anyone knows about.
 
 
 -- 
 Colby Kraybill
 Space and Planetary Image Facility
 University of New Mexico
 opus@pioneer.unm.edu
 


-- 
Colby Kraybill
Space and Planetary Image Facility
University of New Mexico
opus@pioneer.unm.edu
From: towen@relay.nswc.navy.mil (Thomas F. Owen)
Newsgroups: comp.arch.storage
Subject: EMASS and Cray Experiences
Date: 14 Aug 92 12:59:38 GMT
Organization: Code E402, Naval Surface Warfare Center

Does anyone have any experience with using EMASS from E-Systems on a
Cray YMP system?  We are looking at various archive mechanisms, and I
am told that EMASS is a Cray supported product.  I would like to get
experiences of other users, especially if they use EMASS with DMF and
MLS.  We are investigating the feasibilty of EMASS, but want other user
experiences such as:  performance, reliablity, ease of installation,
ease of use, operator requirements, etc.  Any experiences would be most
appreciated.  I will summarize comments and post the results.

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


===================================================================
Thomas F. Owen (towen@relay.nswc.navy.mil)
Work: (703) 663-7614
Paper Mail: NAVSWC, Code E402, Dahlgren VA 22448
Newsgroups: comp.arch.storage
From: wllarso@sandia.gov (William L Larson)
Subject: Contemporary Cybernetics: CY-10i-SUN
Organization: Sandia National Laboratories
Date: Fri, 14 Aug 92 22:38:53 GMT

Does anyone out there have any hands on experience with this device?
It is a relabeled Exabyte 10 tape jukebox.  If you have had to work
on it, please drop me a line, I need some help.
Newsgroups: comp.arch.storage
From: sss@world.std.com (Sergiu S Simmel)
Subject: New discussion forum around Kala -- The Persistent Data Server
Organization: Penobscot Development Corporation, Arlington MA
Date: Sat, 22 Aug 1992 14:39:55 GMT





---------------------------------------------------------------------
                 PENOBSCOT DEVELOPMENT CORPORATION

                              announces

              A NEW FORUM FOR DISCUSSION AND INFORMATION 

                                  on 
                                  
                  THE KALA(tm) TECHNOLOGY AND PRODUCT
---------------------------------------------------------------------



Welcome to Kala -- The Persistent Data Server. Now, you can ...

        o keep yourself up-to-date with Kala's new developments, 
        o share your experience in using Kala with others, 
        o hear what others have to say about it, 
        o ask us questions and benefit from the answers we provide to
          others, 
        o participate in discussions on Kala-related technical topics,
          such as data/object persistence, visibility management,
          databases and file systems, etc.,
        o learn more about the Kala technology, including as yet 
          undocumented details,
    	o give us important technical and business feedback on our
    	  products,

        o and more ...

... by subscribing to our new Kala Forum. This forum, organized as a 
mailing list, will be moderated, so we will try to keep its focus and 
orientation straight, and the junk mail out.

To subscribe (and subsequently for any other requests regarding your
subscription, such as change of address, unsubscription, etc.), direct
your request to:

                --------------------------
                kala-request@world.std.com
                --------------------------
        
To contribute to the on-going discussions address your messages to:

                    ------------------
                    kala@world.std.com
                    ------------------

Since we value most advertizing by word-of-mouth and personal
reference, please forward this message to whomever you believe could
also benefit from subscribing.

We are looking forward to your subscription request and your
participation in 

                   ###   ==============  ###
                   ###   The Kala Forum  ###
                   ###   ==============  ###




 _     _     ____   _         ____ tm ____________________________________
 \\   /     |    \   \       |    \       \\\\ 
  \\ /__     \ __ \   \       \ __ \       \\\\ 
   \\    \    \    \   \       \    \       \\\\  
    \\    \    \    \   \       \    \       \\\\  No more than you need !!!
     \\'   \'   \'   \'  '----'  \'   \'      \\\\  No less than you want !!!
      ........................................................................




-- 
  ___    ___    ___   ________________________________________________________ 
 |   `  |   `  |   `  Sergiu S. Simmel       Penobscot Development Corporation
  \ __   \ __   \ __   50 Princeton Road      Internet: sss@world.std.com
       \      \      \  Arlington, Mass        Voice:  +1-617-646-3951
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Threaded Code
Date: 14 Aug 92 21:13:57 GMT
	<GLEW.92Aug7185506@pdx007.intel.com>
	<1992Aug10.141731.10007@email.tuwien.ac.at> <martin.713808550@bert>
Reply-To: jinx@zurich.ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: martin@math.rwth-aachen.de's message of 14 Aug 92 16:09:10 GMT

In article <martin.713808550@bert> martin@math.rwth-aachen.de (  Martin Schoenert) writes:

|   Date: 14 Aug 92 16:09:10 GMT
|   From: martin@math.rwth-aachen.de (  Martin Schoenert)
|
|   So I wrote my own tests.  First I defined a virtual (stack) machine with
|   28 instructions (not just 2 as in Anton's tests).  For this virtual
|   machine I wrote a small test program, which computes the number of primes
|   less than 40000 in a very straightforward way.  Then I wrote and tested
|   the following 6 implementations of this virtual machine.
|
|   ...
|
|   If a compiler performed those optimizations the implementations of
|   bytecode and direct threaded interpreters such as 'swi' and 'sub' would
|   be just as efficient as the implementations using gcc's label pointers.
|   Such optimizations might also be worthwile in other situations where
|   label pointers would not help at all.

Actually, I'm not convinced.  I don't know what your bytecode is like,
but I can tell you that our interpreter lost a factor of 2 in speed
when recoded in C (and compiled with gcc) from the original 68k
version.

One of the major sources of this performance difference was not the
instruction dispatch, which after all, a switch can do moderately
well, and where you are inherently dispatching on a compact type code,
but on two other places where first-class labels would be useful (we
used addresses of instructions in machine language), namely:

- "return addresses" into the interpreter.  
Our interpreter is one big loop and manipulates its own stack.  When
"invoking itself recursively", it pushes a "return address" on the
stack.  The 68k version just pushed the address of the return
instruction, as you would expect.  The C version pushes a "return
code" that we dispatch to (with a switch) on return.

If you wonder why we don't use C function calls, the answer is pretty
straight-forward:

x Function call overhead, as you noticed yourself.
x Implicit state.  Scheme has first-class continuations which imply
that you must be able to capture the stack of pending operations.  The
code for doing this with the C function-call stack would not be
portable.

- "primitive procedures" of the language.  Again, a primitive of the
language is naturally represented as the address of its first
instruction in assembly language.  In portable C you would have to use
a table of procedures (with its associated cost) or another switch
statement.
From: martin@minster.york.ac.uk
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ... (cooling)
Date: 13 Aug 92 10:58:50 GMT
Organization: Department of Computer Science, University of York, England

hallam@zws010.enet.dec.com says:
> Perhaps this will supur the developmen of some non standard cooling
> methods. My favorite suggestion is to use the heat sink to keep the
> coffee warm...

Perhaps this is time to ask something I've often wondered....

Why doesn't anyone (to my knowledge!) use heat pipes, and/or stirling engines
for cooling big chips like the alpha?
Both technologies can move vast amounts of heat, and have been around for many
years - certainly longer than there have been chips to cool!


Martin

INTERNET: martin@minster.york.ac.uk
JANET:  martin@uk.ac.york.minster
surface:
        Dr. Martin C. Atkins
        Dept. of Computer Science
        University of York
        Heslington
        York YO1 5DD
        ENGLAND
From: guyd@harpo.hursley.ibm.com (Guy Dawson)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 18 Aug 92 09:45:49 GMT
Reply-To: guyd@harpo.hursley.ibm.com (Guy Dawson)
Organization: IBM, Austin

Reading K&R2, section 2.2 Data Types and Sizes, for a '64 bit' CPU I
would expect the
following sizes :-

char		8 bits
short		32 bits
int		64 bits
long		128 bits

For me, the key phrase is given in the short table of sizes :-

int	an integer, typically reflecting the natural size of integers on the
host machine


Time to duck for cover?

Guy
By me, for me.
Newsgroups: comp.arch
From: john@netnews.jhuapl.edu (John Hayes)
Subject: Caches and Hashing
Keywords: risc caches
Organization: Applied Physics Laboratory of Johns Hopkins University
Date: Mon, 17 Aug 1992 21:41:13 GMT

There was an interesting idea in a recent article in Microprocessor
Report.  The article was describing HP's PA-RISC.  Here is what caught
my eye:
	"The caches are direct mapped to eliminate the performance
	impact of multiplexers that would be required with set-
	associativity.  To reduce the cache miss rates, the addresses
	are hashed before they drive the cache SRAMS."*

This raises several questions in my mind:
1) How much does hashing improve the miss rate of a direct-mapped
cache?
2) The argument for direct mapped caches is that they have a better
effective access time than set-associative caches because direct
mapped caches do not need multiplexers to select the data.  Would
the cost of hashing eliminate this advantage?  In other words:
would a direct mapped cache with hashing or a set-associative
cache (with associated multiplexers) give the best performance?
3) What hash function does HP use?

I would be interestered to hear from anyone who knows the answer
to these questions from papers or first-hand knowledge.  I will
summarize to the net.

* Case, Brian, "HP Reveals Superscalar PA-RISC Implementation",
Microprocessor Report, Vol. 6, No. 4, March 25, 1992, p. 17.

-----------------------------------------------------------------
	John R. Hayes
	Applied Physics Laboratory
	Johns Hopkins University
	john@hecate.jhuapl.edu -or- john@aplcomm.jhuapl.edu
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 23 Aug 92 14:27:26 GMT
Organization: UIUC SCS

In article <l9b1usINN2aj@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:


>* Fortran compatibility.  Fortran 77 (yeah, I know that '90 is
>different) mandates that

Fortran 90 is not different from Fortran 77. It is (almost, very closely)
a superset of Fortran 77.


>    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.

Doug McDonald
Xref: sparky comp.arch:8927 alt.folklore.computers:12626 comp.benchmarks:1313
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: dinosaur horsepower
From: Geoff@equinox.gen.nz (Geoff Mccaughan)
Date: 12 Aug 92 20:27:58 +1200
Organization: Equinox Networks
X-Newsreader: Tin 1.1 PL4

mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
>
>Subjectively the same problems I did then run faster now on a high end
>PC .... which also draws little balls showing the atom positions
>on the screen, doing ball color fills in software, in real time.

Presumably you mean doing the colour fills in real time [whatever that may
mean], not plotting the atom positions?

--
Geoff, "heisenberg will get you!" geoff@satori.equinox.gen.nz
Voice: +64 (3) 3852101
        "Hi. You have just entered the fourth dimension. Small isn't it?"
Newsgroups: comp.arch,comp.arch.storage
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Subject: Re: Memory Hierarchy Questions
Organization: Bergen Scientific Centre, Bergen, NORWAY
Date: Fri, 21 Aug 1992 07:15:34 GMT

In article <y6#nqyb.ken@netcom.com> ken@netcom.com (Ken Kofman) writes:
>Hi,
> 
>I have a few questions, and I hope this is the right place to post them.
> 
>Along these lines, I have also developed an interest in learning about
>the kinds of memory hierarchies being designed into real-world larger
>systems.  The Patterson/Hennessey book was a good start, but I'm also
>interested in actual data.  How does doubling main memory from 200Meg to
>400Meg, from 0.5Gig to 1Gig, or from 1Gig to 2 impact the miss rate?  

   It will not affect the miss rate.
   The miss rate of such a system is solely determined by the cache so
increasing main memory will only decrease the miss penalty since the pager
has to go to disk less often.
   In the real world of large environmental simulations it DOES help to
increase main memory of workstations to 256-512MB+ levels.
-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-05)544653
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: PALcode instructions vs TRAP instructions
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Mon, 17 Aug 1992 09:52:39 GMT

In article <1992Aug16.195833.58188@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>In article <34303@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
>> ivie@cc.usu.edu (CP/M lives!) writes:
>>>Not really. The OS will believe the console code about how much memory is
>>>available. The console reports the memory size as smaller than physical by
>>>the amount of memory needed for the PALcode and the console. The OS will not
>>>try to use the memory thus reserved for PALcode.
>> 
>> 	This would seem to be dangerous, because of wild pointers.  Just
>> because the OS doesn't know about the memory doesn't mean that there won't
>> be a write to those locations.  I do hope that PALcode fetches are checked
>> for illegal accesses.
>
>The problem with wild pointers should be solved as soon as the OS is up far
>enough to initialize the page tables. If the page tables don't include the
>console memory, the OS can't get at them.

Mmm.  But waht about bugs (eg wild pointers) in the OS?  I mean, am I missing
something, or don't OSes still have bugs in them?  B^>/2

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.22|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US hotrod motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.arch,comp.sys.ibm.pc.hardware