HDTenEightyP/NetNews huggingface dataset:
From: lry1219@cfdd40.boeing.com (Larry Yeagley)
Newsgroups: comp.arch
Subject: Steve Chen & Supercomputing Systems Inc. - NYT article.
Keywords: Steve Chen, Supercomputing Systems Inc.
Date: 25 Jan 93 16:30:09 GMT
Organization: Boeing Computer Services, Seattle - CFD lab

Supercomputing Weenies of the Netland:

In the Friday (1/22/93) edition of the New York Times there appeared (in the
Business Day section) an interesting article on the fortunes of Steve Chen and
his company Supercomputing Systems Inc. According to the article, IBM, because
of its financial problems, will probably withdraw its support from Chen and his
operation. Accordingly, Chen & company are hustling about looking (with IBM's
help) for replacement support.

Happy trails,

+---------------------------+--------------------------------------------+
| Larry Yeagley             |    This space intentionally left unblank.  |
| lry1219@cfdd42.boeing.com |                                            |
+---------------------------+--------------------------------------------+
|  The advice, opinions and mistakes expressed here are my own and       |
|  certainly not Boeing's.                                               |
+------------------------------------------------------------------------+
Newsgroups: comp.arch
From: oasis@jcwrs.watson.ibm.com (GA.Hoffman)
Subject: Re: Idea on super fast memory system
Date: Wed, 27 Jan 93 19:26:40 GMT
Organization: IBM T.J. Watson Research Center

Been done .. RAMTRON.

g
-- 
gary a hoffman
RISC Systems, Watson Research
From: savel@hal.COM (Bharat Baliga-Savel)
Newsgroups: comp.arch
Subject: Re: Harvard Architecture
Date: 25 Jan 93 21:20:48 GMT
Organization: HaL Computer Systems Inc.
NNTP-Posting-Host: gorn.hal.com

hmmm! i was under the impression that it was specifically a separate 
Instruction Cache and Data Cache. 
-- 
-------------------------------------------------------------------------------
Bharat P. Baliga-Savel                                     /tmp/Design_Engineer
Ext. 1307
If it is fixed, it ain't broke!!!
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.arch
Subject: Re: DSP chip design
Date: 28 Jan 1993 00:27:06 GMT
Organization: U. C. Berkeley
Distribution: world
NNTP-Posting-Host: forney.berkeley.edu

In article <49154@ogicse.ogi.edu> stever@anago.cse.ogi.edu (Steve Rehfuss) writes:
>DSP chips are optimized for a certain class of algorithms, relative to
>general purpose microprocessors.  What's a good reference on the architectural
>tradeoffs being made vis-a-vis the class of algorithms targeted?

Edward Lee did a series of two articles for the IEEE's ASSP Magazine;
"Programmable DSP Architectures, Part I" appears in the October 88
issue and part 2 appears in the January 89 issue.  This series has a
lot of information on DSP architectures and why they are the way they
are.






--
Joe Buck	jbuck@ohm.berkeley.edu
Newsgroups: comp.arch
From: lando@zycar.lmsc.com (Jim Landowski x45016)
Subject: Re: HOw many PC's make an Amdahl mainframe
Reply-To: lando@zycar.lmsc.com
Organization: Sun Microsystems, Inc.
Date: Tue, 26 Jan 93 22:59:43 GMT


	Considering that the mainframes last bastion of use is in the very
large database management (and transaction processing). I don't think a
gaggle of PC's can compete here BUT if you include a fileserver (data-
server) then the picture changes and the PC, as a smart data entry/query
terminal will win... the software is what's needed (if it doen't already
exist). IMHO.

  - Jim L.

Newsgroups: comp.arch.storage
From: dannyb@panix.com (Daniel Burstein)
Subject: CMS JUMBO and DR-DOS/superstore
Organization: PANIX Public Access Unix, NYC
Date: Wed, 27 Jan 1993 19:13:38 GMT

Using the DRDOS "superstor" disk compressor gives (roughly) a 2:1
compression on the original data (mileage may, and does, vary).

In a single hard-disk setup ("C:") it will leave a small amount of
housekkeping info in non-compressed partitions, which it names drive "D:",
and compresses drive C: as a portion of "D:"

this is generally transparent to the user, and drive "C:" is accessed just
like it would have been without compression.

Confused enough?  now to my question;

  I have the CMS Jumbo, and up to know, I've been directly back-upping
(sp?) the "C:" drive from the "C:" drive itself.  Straightforward, since
the drive "looks" normal (just twice the size)

  But, in looking further, I notice that in the "D:" drive is a huge
semi-visible file called "sstorxxx.yyy" (more or less) which is the
partition set aside for the compressed C: drive.  The CMS software seems
to offer me the option of simply backing up the entire "D:" drive,
including in it the C:/sstor section.

  So.... when I'm saving stuff to tape, can I simply do a "D:" drive
backup and get everything that way?  I realize I won't be able to access
individual files (at least not those inside the "C:/sstor" portion) but
for the full drive backup this would make life a bit easier.

  does anyone have any hands on expericen with this?

thanks

dannyb@panix.com
From: mcglk@cpac.washington.edu (Ken McGlothlen)
Newsgroups: comp.arch.storage
Subject: The possibly mythical $20 1GB "card"---news?
Date: 26 Jan 93 02:38:08 GMT
Distribution: usa
Organization: Dubious.
NNTP-Posting-Host: yang.cpac.washington.edu

Some months ago, the Associated Press reported that a new storage medium---a
solid-state "card" about the size of a standard playing card, only a bit
thicker---had been developed.  It reportedly held 1GB, had a decent access time
(rivaling that of fairly fast hard drives---I assume that means ~10ms), and the
media would be sold for about $20 per card.  There was no report on how much
the drive was going to cost, or when it would be available.

Since then, *nothing*.  Not a whisper from the media, no hint from the
comp.arch.storage participants, no nuttin'.

Has anyone else heard anything about this?  I know I read it, because my
roommate remembers the same story in the Seattle Times.  If so, I'd appreciate
some details on whatever happened to it---whether it proved infeasable, or is
being developed, or when it's going to be available from who. . . .

Thanks.

				---Ken McGlothlen
				   mcglk@cpac.washington.edu
				   mcglk@cpac.bitnet
Newsgroups: comp.arch.storage
From: mlaurenc@world.std.com (Matt Laurence)
Subject: Problems with 128 MB 3.5" M-O drive...
Organization: The World Public Access UNIX, Brookline, MA
Date: Thu, 21 Jan 1993 05:46:03 GMT

I have a dgr 3.5" magneto-optical drive that takes the standard 3.5"
128 MB cartridges, and it's worked pretty well up until now. And,
as far as I can tell, the drive is still working fine, but one of
the cartridges (only one out of four) refuses to mount. It was
formatted properly, same as the other three, with FWB's HDT Lite,
and I've been using it without fail for some time. For a while,
my computer was out of commission, so I moved the drive to an SE
running system 6.05, and it worked fine. When I switched the drive
back to my IIcx, however, this one cartridge refused to mount. It
goes in and sounds like it's mounting, but then it clicks a few
times, finally spinning down as if it's about to eject the disk, 
but it then instantly spins up again to try again. If I hold the 
eject button in, it eventually spits out. But it will NOT mount,
no matter what I do. All the others work fine, even those I used when
the drive was on the SE (I didn't expect any problems with any of
them).

This cartridge hasn't been unduly abused, exposed to any temperature
extremes or anything... does anyone have an idea why this reputedly
indestructible medium might suddenly go sour on me? I have a LOT of
vital data on there, and I really don't want to revert to an expensive
data recovery service to get it off...

ANY help or suggestions would be MUCH appreciated.

Matt
mlaurenc@world.std.com
From: meb@waikato.ac.nz
Newsgroups: comp.arch.storage
Subject: Re: VCR as a backup medium?
Date: 27 Jan 93 11:25:18 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <1993Jan26.045638.12425@netcom.com>, nagle@netcom.com (John Nagle) writes:
> gps19@herald.usask.ca (Gregory P. Siemens) writes:
>>Is it possible to use a VCR as a backup device.  What hardware and 
>>software would be needed?  I,m trying to come up with a cheap way of
>>storing large amounts of data.  If the hardware does not exist would it
>>be difficult to construct(ie. what would be required).  I would
>>appreciate any(!!) enlightenment on this subject(reasons it will or 
>>won't work, etc.).
> 
>       It's been done, but I haven't seen an adapter for doing it since
> about 1987.  Heavy redundancy in the data is necessary (one system
> recorded everything six times) because of the high noise level and
> dropout problems with VCRs.  VCRs are not well suited to stop-start
> operation, so buffering is a problem.  
> 
>       8mm drives are often warmed-over camcorder decks, and 8mm backup
> is a mature technology, although the drives still cost too much.
> At least the tape is cheap.  But VHS backup seems a dead technology.
> 
> 					John Nagle

I would be interested in any articals, information, or even adds documenting 
previous VCR interfaces. I have developed an interface that can store over 
600 Megabytes of error corrected data on a standard 3 hour tape ($5-00). 
Only 26% of the data is redundant for error correction and resulting error 
rates are very low ( 10**-11 --> 10**-13). Anyway if previous work in this area
has been done, i need references for my literature review.   

	Thanks M. Baguley

Marcus Baguley
Computer Science Dept.
Waikato University
Private Bag
Hamilton
New Zealand

EMAIL meb@waikato.ac.nz
From: C567237@mizzou1.missouri.edu (Scot Sullivan)
Newsgroups: comp.arch.storage
Subject: Re: 4 Floppy Drives?
Date: 27 Jan 93 15:53:43 GMT
Organization: University of Missouri

Does anyone out there know how to have 2 3.5" drives and 2 5.25" drives on the
same PC?  I already have the 2 3.5", plus a CD-ROM and tape backup.  I could re
ally use some 5.25" drives, but I don't know how to do it, or even if it is pos
sible.  Can someone help me?
Thanks,
          Scot Sullivan  C567237@Mizzou1.Missouri.edu
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.arch.storage
Subject: Re: Managing a Terabyte (was: Re: Dumping a Gigabyte )
Followup-To: comp.arch.storage
Date: 21 Jan 1993 14:14:42 GMT
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
	<1993Jan20.173950.20531@murdoch.acc.Virginia.EDU>
Reply-To: stephen@acm.org
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: sdm7g@elvis.med.Virginia.EDU's message of Wed, 20 Jan 1993 17:39:50 GMT

In article <1993Jan20.173950.20531@murdoch.acc.Virginia.EDU> sdm7g@elvis.med.Virginia.EDU (Steven D. Majewski) writes:

[Lots of unassailable stuff - has anyone not worked this out yet? Then:]

|[ (**) This imbalance has other implications. Processor speeds are 
|increasing faster than disk i/o speeds. At what point is uncompressing a
|compressed instruction stream, or incremental compilation of a minimal
|I-code faster than paging in code from virtual memory?  ] 

You lose big on optimisation this way. When compressing the results of
translation tasks (whether that's parsing natural language or generating
code) *for rapid decompression* you want to save the input **and
selected choicepoint oracles**. As the compression folks will tell you,
data modelling is the important part.... So the "I-code" shouldn't be so
minimal, or rather, it should be augmented with the results of any
computationally expensive decisions that the full compiler might once
have made. (The advantage to two streams is architecture independence,
of course).

Damn, here I go giving all my secrets away.... ;-)
----------------------------------------------------------------------
stephen p spackman    +49 681 302 5288(o) 5282(sec)    stephen@acm.org
      dfki / stuhlsatzenhausweg 3 / d-w-6600 saarbruecken 11 / germany
----------------------------------------------------------------------
From: ufe@dlva.dl.ac.uk ()
Newsgroups: comp.arch.storage
Subject: Re: VCR as a backup medium?
Date: 27 Jan 1993 09:09:21 GMT
Organization: SERC Daresbury
Distribution: world
Reply-To: ufe@dlva.dl.ac.uk ()
NNTP-Posting-Host: vxstn2.dl.ac.uk


I remember test driving a VCR system on a VAX over 6 years ago - I think
it was called DIGIDATA and have seen a site which uses one. However, it
was quickly overtaken by 8mm.

However, I attended a presentation last year (by CONVEX) which referred
to a 2nd attempt to harness the technology with much improved capacity
and data rates - forgotten the name, but DD2 comes to mind.

Cheers,
	Mark
========================================================================
Mark Enderby			   JANET - ENDERBY@UK.AC.DARESBURY
Systems Manager		  	   EARN/Bitnet - ENDERBY@DARESBURY.AC.UK
SERC Daresbury Laboratory
Keckwick Lane						
Daresbury
Warrington	tel:   0925-603353
WA4 4AD		Int:+44-925-603353
UK		fax:   0925-603174
Newsgroups: comp.arch.storage
From: jmalcolm@sura.net (Joseph Malcolm)
Subject: Re: Managing a Terabyte (was: Re: Dumping a Gigabyte )
Organization: SURAnet, College Park, MD, USA, NA, Earth, Milky Way
Date: Wed, 27 Jan 1993 15:32:20 GMT

In article <1993Jan21.050327.16863@netcom.com> nagle@netcom.com (John Nagle) writes:
>     I don't see that it is necessary to get rid of backups.  But it is
>necessary to be able to do them on a continuous, background basis.
>This is certainly possible.  Multics did it in the 1960s; UNIVAC
>mainframes had it in the 1970s.  Unfortunately, UNIX, DOS, and the Mac
>traditionally have weak backup tools, and that's all anyone knows any more.

Perhaps you could explain how Multics did backups? (Then
we might be able to continue the proud Unix tradition of
stealing ideas from Multics.)

-- 
Joseph Malcolm				jmalcolm@sura.net		
SURAnet Operations			+1 301 982 4600
From: gps19@herald.usask.ca (Gregory P. Siemens)
Newsgroups: comp.arch.storage
Subject: VCR as a backup medium?
Date: 25 Jan 93 19:58:07 GMT
Article-I.D.: access.1k1gofINNiek
Organization: University of Saskatchewan
NNTP-Posting-Host: herald.usask.ca
X-Newsreader: TIN [version 1.1 PL7]

Is it possible to use a VCR as a backup device.  What hardware and 
software would be needed?  I,m trying to come up with a cheap way of
storing large amounts of data.  If the hardware does not exist would it
be difficult to construct(ie. what would be required).  I would
appreciate any(!!) enlightenment on this subject(reasons it will or 
won't work, etc.).
		Mail me or reply/post

			THANX		G 
From: kondoff@aspen.NSA.HP.COM (Al Kondoff)
Date: Tue, 26 Jan 1993 06:29:17 GMT
Subject: Re: IEEE Mass Storage Ref Model
Organization: HP Networked Systems Architecture - Cupertino, CA
Newsgroups: comp.arch.storage

The IEEE MSS is P1244, and will issue a new version of  their reference
model in the next several months. If you're interested in more details,
contact bbaird@nsa.hp.com (he's our standards rep). I'm not familiar with
IEEE rules on releasing their documents, but Bob Baird should be able to
point you in the right direction.

As for the reference model, its intention is to describe a model where
hosts can access tertiary storage in a uniform manner. The hope is that
multiple vendor's products will interoperate. Primary members are the
U.S. national labs, supercomputer manufacturers, and mass-storage system
hardware providers, as well as a few F100 companies.
Newsgroups: comp.arch.storage
From: joed@mozart.cbs.umn.edu (Joe Dalsin)
Subject: Long term archiving.
Organization: University of Minnesota - Plant Biology
Distribution: na
Date: Mon, 25 Jan 1993 15:51:59 GMT

Given the recent introduction of read/write optical drives what is the preferred
method of long term archiving of large data sets?  Can one get expect good 
shelf life from 8mm tapes?  What are peoples experiences with permanent (or 
as close as possible) storage of large computer files?  

Thanks in advance for any replies.  I'll post a summary if there is enough
response.

Joe Dalsin,  Plant Biology, University of Minnesota, joed@mozart.cbs.umn.edu
 
-- 
/////////////////////////////////////////////////////////////////
//  You can't trust big business so brew it at home.
//                                        
//  Joe Dalsin                     %_%%%______                   
Newsgroups: comp.arch.storage
From: cecchi@rchland.vnet.ibm.com (Del Cecchi)
Subject: Re: REQUEST: IBM 9347 001  9 Track Tape Unit Information
Date: Thu, 21 Jan 1993 21:36:28 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester

In article <80462.189310024@kiwi.gen.nz>, clark@kiwi.gen.nz (Clark Mills) writes:
|> Many thanks to:
|> 
|> Basile STARYNKEVITCH <basile@soleil.serma.cea.fr>
|> kirchner@informatik.uni-kl.de
|> "Derrick J. Brashear" <db74+@andrew.cmu.edu>
|> Doctor Math <root@sanger.chem.nd.edu>
|> johnl@iecc.cambridge.ma.us (John R. Levine)
|> Gary Turner <srgpgct@grv.grace.cri.nz>
|> ag@nextcube.in-berlin.de (Andreas Gradert)
|> brumba@maize.rtsg.mot.com (Alan J. Brumbaugh)
|> ross@kiwi.gen.nz (Ross George)
|> 
|> It appears that the machine is a SCSI I (IPI) interface which dosn't use the
|> standard SCSI command set and isn't pin-compatible (Thanks IBM!).  The
|> `telephone type jack' is a twisted pair ethernet connector and the thing only
|> accepts 1600 & 3200 bpi tape. 
|> 
|> Thanks very much for your help...  clark
|> Bottom line: Worth more to me as parts :-)
|> -- 
|> Domain: clark@kiwi.gen.nz  -----------------------------+-------------------+
|> Voice : 64-25-935002        Disclaimer: All errors are  | $ nice -20 work & |
|> Fax   : 64-9-8494282                    line niose!     | $ exec games      |
|> Snail : PO Box 47-195, Ponsonby, Auckland, New Zealand  +-------------------+

I don't know anything about a 9347, but I do know that IPI and SCSI are two
different things altogether.  so the commands being different and the pins being
different are understandable.   You're welcome, dude. 

Del Cecchi  
cecchi@vnet.ibm.com
Newsgroups: comp.arch.storage
From: jcooley@world.std.com (John Cooley)
Subject: Joining ESNUG
Organization: The E-mail Synopsys Users Group (ESNUG)
Date: Thu, 21 Jan 1993 05:53:34 GMT


  If you're using the Synopsys Design Compiler and/or their ATPG product, you 
  might be interested in joining the E-Mail Synopsys Users Group (ESNUG).

  What we are is a group of hardware designers from all over the world who
  wish to trade experiences, bug reports and the techniques that we've
  found that work best in getting a design from a behavioral description
  to a final fully tested product.  This is a grassroots forum independent
  of Synopsys, Inc.

  A Sample of What We Discuss:

	- Known Synopsys Compiler Bugs    - Implementing Boundry Scan

	- Mentor related issues    - EDIF related issues

	- Hierarchical Compliations   - design_analyzer   - JTAG

	- How Various ASIC Vendors Model Their Macros.   - Clock Constraints

	- Using ATPG Tools   - The Best Way To Write State Machines in Verilog

	- Using VHDL   - System Simulation vs. Synopsys Friendly Code

	- Clever Workarounds to Known Pitfalls   - Testing Strategies

  In order to insure an open discussion, but yet keep our respective managers
  happy in having our company's projects remain SECRET, submissions to be 
  posted to the ESNUG mailing list can be stripped of identifying engineers 
  and company names if so requested.

  In addition, to further secure privacy and to avoid e-mail headers that
  are hundreds of names long, each mailing is a batch of singlely addressed 
  e-mail letters.

  If you want to join ESNUG, please send me e-mail to "jcooley@world.std.com"
  saying you wish to join and why.  (Please don't send a copy of this letter
  back to me, I know what you're refering to when you're writing.)

					- John Cooley
					  ESNUG Moderator

 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    | Preferred Address: jcooley@world.std.com
     /o o\  /  it's a FEATURE!"   |    Backup Address: jcooley@miracle.com
    (  >  )                       |              (508) 429-4357
     \ - /       |   Snail Mail: P.O. Box 6222, Holliston, MA 01746-6222
     _] [_       |     "This here ain't no one's opinion 'cept my own."
From: hendrick@ctron.com (James R. Hendrick)
Newsgroups: comp.arch.storage
Subject: Backup Advice Wanted!!
Date: 25 Jan 93 18:19:59 GMT
Distribution: comp
Organization: Cabletron Systems Inc.


Hello All,
	We are in the process of re-vamping our strategy for performing
backups. Currently, we have slightly less than 5G at one site, somewhat
less at another two sites that must be done each night. In addition, we
perform as-requested backups of many other areas during the day. As
you can well imagine, this is getting a bit out of hand.

	What I would like from you all is recommendations/warnings
about what hardware (stackers, carousels, R/W Optical devices, etc)
and software you have knowledge about. I am NOT looking for blatant
sales pitches, but UNBIASED responses from folks that have to live
with the stuff.

Thanks in advance,

Jim

P. S. I'll summarize if it seems warranted

--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.              ###   " My opinions, etc are    ###
### P. O. Box 5005                      ### exclusively the property    ###
### Rochester, NH 03867-5005            ### of nobody in particular."   ###
### (603) 337-7572                      ###                             ###
### fax:(603)337-7370                   ###                             ###
###########################################################################
From: ufe@dlva.dl.ac.uk ()
Newsgroups: comp.arch.storage
Subject: Recordable CDs
Date: 26 Jan 1993 08:17:09 GMT
Organization: SERC Daresbury
Distribution: world
Reply-To: ufe@dlva.dl.ac.uk ()
NNTP-Posting-Host: vxstn2.dl.ac.uk


Has anyone had experience with the new recordable-CDs for producing data
in ISO 9660 format ?

We wish to allow users to take away data in a (relatively) indestructible
form and in a format that can be easily read on cheap readers attached
to PC's and workstations. CD-R with ISO 9660 seems to be the ideal 
system ... but are there any problems ?

Cheers,
	Mark
========================================================================
Mark Enderby			   JANET - ENDERBY@UK.AC.DARESBURY
Systems Manager		  	   EARN/Bitnet - ENDERBY@DARESBURY.AC.UK
SERC Daresbury Laboratory
Keckwick Lane						
Daresbury
Warrington	tel:   0925-603353
WA4 4AD		Int:+44-925-603353
UK		fax:   0925-603174
Newsgroups: comp.arch.storage
From: mek@hydrox.enet.dec.com (Mark Klamerus)
Subject: IEEE Mass Storage Ref Model
Date: Thu, 21 Jan 93 14:24:52 PST
X-Received: by usenet.pa.dec.com; id AA20917; Thu, 21 Jan 93 14:24:53 -0800
X-Received: by enet-gw.pa.dec.com; id AA16419; Thu, 21 Jan 93 14:24:51 -0800
X-Received: from hydrox.enet; by decwrl.enet; Thu, 21 Jan 93 14:24:52 PST
X-To: comp.arch.storage.usenet
X-Apparently-To: comp.arch.storage.usenet


	Can someone tell me what this is?  I recently had a question
	regarding this in a pros/cons relation to SQL/Database.

	What is this model/methodology?  Does it have a number?
	Is there documentation regarding this on the net?

	thanks,
	Mark Klamerus

Newsgroups: comp.arch.storage