HDTenEightyP/NetNews huggingface dataset:
From: ted@telematics.com (Ted Goldblatt)
Subject: Re: SCSI (was Re: IPI-2 questions)
Organization: Telematics Intl., Inc.; Ft. Lauderdale, FL
Date: Mon, 27 Jul 1992 23:01:46 GMT

In article <1992Jul26.052449.18091@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes:
>
>How do you prevent two devices responding to the same
>low 8-bits of address?
>
>i.e. devices 4 and 12.
>
>The high bit is only visible on the 16bit bus. Is there some
>magic which differentiates between 8 and 16bit addresses,
>which is visible in the 8bit space?

Assuming your host adapter was at SCSI ID 0 and it wanted to
address a device at SCSI ID 4, in the SELECTION phase it would
assert DB(0) and DB(4); to address a device at SCSI ID 12, it
would assert DB(0) and DB(12) (at least it would if this were
legal :-), my reading of revision 10c of the SCSI-2 spec (most
recent I have) is that the range is explicitly limited to 0-7).

Since in neither case is the ID bit for the "other" device
asserted, it's not clear to me why it would care (it shouldn't
even "see" a SELECT or RESELECT that didn't have its SCSI ID
asserted).  The spec says that a device shouldn't respond if
_more_ than 2 bits are asserted, but it shouldn't care if only
1 is, in fact that's how the single initiator option works.
Obviously, the host adapter itself would have to be in the 0-7
range if any devices only understood 8 address bits, and target
to target operations wouldn't work too good...

ted

-- 
Ted Goldblatt    ted@telematics.com     (305) 351-4367
    Telematics Intl., Inc.   Ft. Lauderdale, FL
From: mjacob@kpc.COM (Matt Jacob)
Newsgroups: comp.arch.storage
Subject: Re: SCSI (was Re: IPI-2 questions)
Date: 24 Jul 92 16:10:32 GMT
Reply-To: mjacob@kpc.COM (Matt Jacob)
Organization: Kubota Pacific Computers Inc.

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

Emulex claimed ~8 mb/s. Async will run close to sync speed
if bus length is very short (like, millimeters).
From: lupe@ukw.uucp (Lupe Christoph)
Newsgroups: comp.arch.storage
Subject: Re: Open letter to Dave Olson, SGI [was SCSI vs. IPI]
Date: 29 Jul 92 22:14:40 GMT
Organization: cic

adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:

>In article <nefd2l0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:

| One group here does video image processing and has to handle a large
| (~GBYTES) data base of frames. These guys relied on the advice of
| Silicon Graphic, Germany and bought a SGI 4Dxxx with SCSI drives.
| (A frame is a mixture of vectors and bitimages.)
| 
| Requirement was, that about 30 frames / second have to be processed.
| Field experience showed that about 2 frames a second could be retrieved,
| yielding a transfer rate of 100 kBytes...

>>   Then something is *seriously* misconfigured, or the app is doing something
>>   silly like using unbuffered stdio (the latter sounds unlikely, given
>>   your later statements).  We haven't had disk i/o that slow in ages, unless
>>   you put really slow disks or i/o cards in the system somehow.

>It has been configured and reconfigured under the advice of
>engineering support from SGI.... Controller and disk came from SGI....

>The application does nothing else than to read in frames, one about
>50 kBytes, unbuffered (simple read()). One hint:  ...  more than
>90% idle, though single user mode!, and drive is kept selected.

In this thread, nobody has asked or volunteered if this app is using
the filesystem or reading from a raw disk. The performance sounds
like the latter, loosing revs all the time. This would also explain
the high idle time percentage.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |
Newsgroups: comp.arch.storage
From: hallam@zeus02.desy.de (Phillip M. Hallam-Baker)
Subject: Re: SUMMARY: O( terabyte ) tape system survey
Reply-To: hallam@zeus02.desy.de
Organization: DESY ZEUS Central Data Acquisition
Date: Sat, 25 Jul 1992 20:23:48 GMT

One point those who can afford the AMPEX may wish to consider. The
company has plans to produce a HIPPI module, they are advertising it as
avaliable in 92/93. The current drives can be upgraded.

Phill Hallam-Baker
Newsgroups: comp.arch
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: Re: BUSES
Organization: National University of Singapore
Date: Sat, 25 Jul 1992 09:57:12 GMT

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
: In article <BrusoI.2so@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
: >In article <1992Jul23.092211.18462@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
: 
: 			.......................
: 
: >>Also, if I get my file within 0.5 sec as opposed to 1.0 sec, will I
: >>notice enough to pay for the hardware? 
: 
: >If you get a hundred files in 50 seconds as opposed to 100, you will notice.

Yes I would notice. But how often does that happen to the **average**
user. Remember that ALL users regardless of whether they need the Super
Duper Fast bus or not have to pay for it.

: 
: If you do not notice the difference in getting your file in .5 sec, you have
: an unusually slow reaction time.  With a useful window system, this is a
: real major nuisance.

Well................. Maybe I do. Somehow I don't think it's terribly
important. One example that comes to mind is OS/2 2.0. People are raving
about its features etc etc although the GUI/OS combo is bloated and not
terribly fast (in a typical configuration on an ISA bus machine).

Besides speed, what else do you think is important in a desktop bus?

jin meng
From: gkc@freddie.udev.cdc.com (gordon k chace x2367)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 23 Jul 92 14:16:07 GMT

In article <2369@nic.cerf.net>, davsmith@nic.cerf.net (David Smith) writes:
|> All CPUs I have seen to date (not every CPU by any means - if you know
|> of counter examples, please post) cannot do asynchronous address
|> generation.  When they request a word of memory they want it *NOW* or
|> within a cycle or two and will block until it arrives.  This makes it
|> impossible to get full bandwidth out of an interleaved memory system if
|> the cache is removed.

Counterexamples from many years ago: CDC 6600, 7600 and derivatives thereof.

My friends at the two Cray companies will probably include their systems
as additional counterexamples.

-- 
Gordon K. Chace
Control Data Systems, Inc.   phone (612) 482-6524   fax 482-2791
email gkc@udev.cdc.com
RISC: Really Invented on the Sixty-six-hundred by CDC
Newsgroups: comp.arch
From: bds@maui.linus.mitre.org (Barry D. Smith)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: The MITRE Corporation
	<id.YGRR.V_5@ferranti.com> <55117@mentor.cc.purdue.edu>
Date: Tue, 28 Jul 1992 13:56:51 GMT

In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   If an optimization involves extensive calculation, a superfast sub-imbecile
   can do it better than a human.
   -- 
   Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399


This is a wonderful quote, and I think I'm going to post it over my
desk.  I have 2 questions:

1) Did you think of it yourself, or did you quote someone else?
2) What exactly is a "superfast sub-imbecile?"

Barry Smith
Newsgroups: comp.arch
From: mac@kpc.com (Mike McNamara)
Subject: Re: Translating ML (was Re: MVC and MVCL)
Organization: Kubota Pacific Computer Incoporated, Santa Clara, CA
Date: Wed, 29 Jul 1992 15:54:35 GMT

In article <65D202Zn1bIR01@JUTS.ccc.amdahl.com> jjs40@cd.amdahl.com (John Sullivan) writes:
| Here's an interesting philosphical question:  If a new architecture
| (say, Alpha) is primarily used by customers to run translated code 
| from an older architecture (say, VAX) then what kind of synthetic 
| effect will this have on the priorities of the CPU designers in designing 
| higher-performance future generations of their machine?  
| 
| For example, if translated code makes a lot of use of "compatibility" type
| features that were never intended to be very fast, will these features win
| out in gates in future versions of the CPU as opposed to spending the gates
| on improving the "better" features from the new architecture?  Will architects
| have to "dirty" their architecture in future versions by adding new features
| (say, byte-wide or unaligned loads) to support better performance on 
| translated code?

	Not if the users of Alpha "free the underlying risc machine" and run
OSF / NT on it.  Perhaps we will see more NT and OSF kernels on alpha than VMS 
kernels on Alpha...

	Let the users decide..

	-mac

-- 
+-----------+-----------------------------------------------------------------+
|mac@kpc.com| Increasing Software complexity lets us sell Mainframes as       |
|           | personal computers. Carry on, X windows/Postscript/emacs/CASE!! |
+-----------+-----------------------------------------------------------------+
From: rhyde@ucrmath.ucr.edu (randy hyde)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 31 Jul 92 15:58:40 GMT

In article <id.RKUR.GFF@ferranti.com> peter@ferranti.com (Peter da Silva)  
writes:
> I don't know about you, but I'm glad they don't make cars with
> manual chokes any more, or that need double-clutching when you shift.
> -- 
> Peter da Silva                                               `-_-'
> $ EDIT/TECO LOVE                                              'U` 
> %TECO-W-OLDJOKE Not war?                        Have you hugged your  
wolf today?
> Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713  
274 5180

I am glad, however, that auto manufacturers do give me the choice of
manual or automatic, depending on whether I want to do the shifts
myself and get better localized performance, or have the car do it and
give me better average performance.
Newsgroups: comp.arch
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Fri, 24 Jul 1992 06:43:42 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <BrM813.Du5@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>In article <1992Jul15.163217.434@urbana.mcd.mot.com> dfields@urbana.mcd.mot.com writes:
>>There are several other cases in UNIX and I'm sure other OS's which
>>are similar.  A block move that doesn't trash the cache is of great
>>use to the OS.

>It's not obvious why you need special instructions for it, however.
>If I recall correctly, the first MIPS chips had the physical address
>space in their kernel virtual space *twice*:  the second was uncached,
>specifically so you could do things like bulk data copying without
>trashing the cache.

Not only "the first MIPS chips", but R2000/R3000/R4000 have two
"segments" (kseg0 and kseg1), which are "unmapped", i.e. are a 1:1 image
of the physical address space which is 512 MBytes.
kseg0 is at virtual addresses 0x80000000 to v.a. 0x9fffffff
kseg1 is at virtual addresses 0xa0000000 to v.a. 0xbfffffff
kseg0 is cached, kseg1 is uncached.
Both "map" to phisical addresses 0x00000000 to 0x1fffffff.
BTW virtual addresses 0x00000000 to 0x7ffffffff is (mapped, cached) user
space (kuseg), v.a. 0xc0000000 to 0xffffffff is (mapped, cached) kernel
space (kseg2/ksseg-kseg3).

IMHO the main reason for having both is
- to have the cached segment for normal data accesses to/from memory
- to have the uncached segment for accesses to (among others) I/O
  registers that are memory mapped. Imagine what would happen if You
  continuously polled a cached I/O register B-{)
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
From: noah@cs.washington.edu (Rick Noah Zucker)
Newsgroups: comp.arch
Subject: what is a non-split transaction bus called?
Date: 24 Jul 92 01:10:46 GMT
Distribution: na
Organization: Computer Science & Engineering, U. of Washington, Seattle


	I was writing something and wanted to refer to a bus that did
not use split-transactions.  I realized that I did not know the adjective
for such a bus.  One person I asked locally said, "That's simply a bus.
If it is split-transaction, then you need to say so".  Someone else said
she uses the term "hold the bus" protocol, but admitted that that is not 
a technical term.  I have seen the term continuous connect used, but
thought that there must be something better.  What do you call it?

						  Rick Noah Zucker
						  noah@cs.washington.edu

P.S. Unless you have a reason to, please just use e-mail.
Newsgroups: comp.arch
From: mcvey@mpr.ca (Iain McVey)
Subject: Re: What's in a name?
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada
Date: Tue, 28 Jul 92 22:03:06 GMT

In article <1992Jul28.181448.24805@Princeton.EDU> mfterman@phoenix.princeton.edu (Mutant for Hire) writes:
>As for CD players, there are oodles of technical advances over CD's
>that make them far superior to records. Also note that all the
>companies got together behind a single standard for the new format.

technical advances?  far superior?  ( wrong group, but here goes )

The only thing CD's have done for sound reproduction is removed media
noise.

brick wall filtering introduces annoying harmonics, and your ear does
hear quantization noise.

Don't get me wrong, I own a CD player and love the crisp sound you get
every time, and the fact that I don't have to wipe down the discs each
time I play them.  I also realize that a $200 CD player will definitely
out perform a $200 turntable.

But if you have a decent turntable and haven't used it in a while, dig
it out and play some of your records.  You will be surprised at how good
they do sound.  There is a warmth that comes from vinyl that is very
difficult to produce from a CD player.

Let's face it, cd's are so popular because of their ease of use and
lack of background noise, not because the sound they do produce is of
any superior quality.

To tie this in with the comp.arch discussion, a computer system is far
more than its cpu.  How well the cpu fits into the rest of the system,
the quality of the overall systems architecture, and the quality of the
other components have more to do with the quality of the overall system.

CD players tend to have very poor supporting components, such as the
preamps on the outputs of the D/A.  This does more to contribute to
distortion and anomolies than the actual D/A converter and filters.

Similarly it tends to be the bus on a DOS box that is the limiting
factor to its performance, expandibility and flexibility.

People tend to attack the cpu in DOS boxes, and worry over backwards
compatiblity.  Perhaps we should look to improve the rest of the system
as well.

- Iain -

-- 
Iain McVey (mcvey@mprgate.mpr.ca)   | - As you can see, I am still alive.
Software Designer                   |   Born that way, you know?
MPR Teltech Ltd.                    | - How romantic, two ships passing out
8999 Nelson Way, Burnaby, BC        |   In the night. - Hawkeye Pierce
From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: MP interrupt handling  was(Re: Sun 600MP Benchmark Anomaly)
Date: 24 Jul 1992 17:37:43 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ouroborous

In article <1992Jul24.133407.18743@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
| As near as I can tell, the new SUN MP systems have symmetric hardware where
| any cpu can field an interrupt, but I don't know how a SUN multiprocessor
| arbitrates who (whom?) gets an interrupt when all cpus are interrupt-
| enabled.  Apparently the "big lock" problem currently hangs the suns....

We solved it, as usual for the 4.1.2mp product, in the simplest way.
The bus arbiter has a register which tells it which CPU to send
interrupts to, and the software has responsibility for updating it. We
knew that the interrupt dispatch policy would be different for various
versions of the operating system, so we didn't lock it down in the
hardware.

Yes, the "big lock" does impact the policy. It means that if one CPU is
inside the kernel, and some other CPU is idle, we really do want the
interrupt to go to the cpu that is inside the kernel.  In practice, we
only have to update the interrupt target register if we receive an
interrupt and fail to acquire the lock; the common case seems to
slide on through the path in minimum time.

I think the SunSoft guys did a paper on how they are handling
interrupts in their multithreaded kernel, but I'm not up on that.
Newsgroups: comp.arch
From: gideony@microsoft.com (Gideon Yuval)
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Date: 24 Jul 92 16:33:22 GMT
Organization: Microsoft Corporation

In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>Finally, there are some applications that benefit from simply having
>larger integers.  John Mashey has mentioned robotics as one such area
>(although I have talked to robotics manufacturers who take a
>completely different approach). But, once again, you have to prorate

Mashey says the robotics guys' reason for using 64-bit integers is that
they don't trust 53-bit mantissas. Given this reason, I wouldn't
expect an Intel man (selling 80-bit X87 math) to have that issue
come up.
-- 
Gideon Yuval, gideony@microsoft.com, 206-882-8080 (fax:-883-8101;TWX:160520)
Newsgroups: comp.arch
From: thapar@hplabsz.hpl.hp.com (Manu Thapar)
Subject: MASCOTS'93: Call for Tools
Date: Tue, 28 Jul 1992 17:10:03 GMT
Organization: Hewlett-Packard Laboratories Palo Alto,CA



=============================================================================

CALL FOR TOOLS  --  MASCOTS'93

International Workshop on Modeling, Analysis and Simulation
of Computer and Telecommunication Systems

Part of the 1993 SCS Western Multiconference on Computer Simulation

Jan. 17 - Jan. 20 1993, Hyatt Hotel, La Jolla
San Diego, California USA

=============================================================================

The MASCOTS'93 workshop is expected to be a major event in the areas
of Modeling, Analysis, and Simulation of Computer and Communication
Systems. For the TOOLS FAIR that will be held during MASCOTS'93, we
are looking for interesting entries of modeling, analysis, or
simulation systems, both from academic and industrial backgrounds.

We are especially looking for TOOLS/SIMULATION SYSTEMS in the areas of
  - Multiple Processor Systems
  - Massively Parallel and Scalable Systems
  - Systolic Structures and Vector Machines
  - Real-Time Systems
  - Computer Architectures
  - VLSI Systems
  - Artificial Neural Networks
  - Fault Tolerant Systems
  - Visualization
  - Large, Distributed, Data Base Systems
  - AI Applications and Expert Systems
  - Vision and Image Processing
  - Robotics
  - Communication Systems / Telecommunication Systems
  - Intelligent Simulation Systems


TOOLS accepted for presentation will be demonstrated in a separate
session at MASCOTS'93. Also, a poster area will be available for
exhibition during the whole workshop. Thirty minute presentations of
each TOOL (including 5-10 min. for Q&A and equipment change) may be
given "live" on a computer system or prerecorded on video tape.

Equipment available:
   Sun SPARCstation 2 (8 Bit color) 
   IBM PC 386         (VGA color)
   Macintosh II       (8 Bit color)
   Video Cassette Recorder for VHS and S-VHS format (NTSC and PAL)
   Scan Converter and Beamer for large screen display


A brief DESCRIPTION of up to two pages (including figures) of each TOOL 
accepted will be included in the workshop proceedings.


Please send abstracts of proposed tools to:

Thomas Braunl
Univ. Stuttgart IPVR
Breitwiesenstr. 20-22
D-7000 Stuttgart 80
Germany
email: braunl@informatik.uni-stuttgart.de

  or

Manu Thapar
HP Research Labs
1501 Page Mill Road
Palo Alto, CA 94304
USA
email: thapar@hplabs.hp.com


SCHEDULE
September  1, 1992  Deadline for TOOLS submissions
September 21, 1992  Notification of acceptance
October   15, 1992  Deadline for camera-ready copy
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Date: 27 Jul 92 01:36:28 GMT
Organization: Auspex Systems, Santa Clara

>Implementing shared libraries or shared
>memory can enforce a global allocation mechanism, with all DLLs and all
>shared memory areas in the system having system-wide unique virtual
>addresses. Otherwise at least shared libraries could not be shared
>(relocation) with all processes.

Unless, for example, your shared libraries are built in
position-independent form; SunOS 4.x/SVR4 shared libraries don't require
system-wide unique virtual addresses, for example.

Shared memories don't necessarily require them, either.

>And there are memory mapped files as filesystem implementation
>technique. You clearly need more than 32-bit addressed virtual memory
>to implement memory mapped files.

Umm, the machine running on my desk has a 32-bit virtual address space,
and the OS on that machine supports memory-mapped files.

The OS doesn't support memory-mapped files larger than 2GB, but then it
doesn't support files larger than 2GB, period.  A future version of the
OS may support files larger than 2GB, although it may not let you
memory-map chunks larger than 2GB or 4GB or so if you don't have an
address space larger than 4GB; you may have to map part of the file, and
move the mapping window around.

I would not be surprised if a movable mapping window like that weren't a
pain, though.
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: BUSES and other things
Date: 25 Jul 92 14:08:28 GMT
Organization: Purdue University Statistics Department

In article <1992Jul25.095712.17550@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

			..................

>Besides speed, what else do you think is important in a desktop bus?

For the hundreds of thousands of users (this is a conservative estimate
based on observations at a few universities) who do mathematical typing,
an extremely important thing to have would be a large variety of characters
available for simultaneous display on the screen, with the file in a
serial form, so that it could be easily edited and transmitted to other
users and processors.  Tex and similar constructs are fine for typesetting,
but not for producing the original.
-- 
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: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 21 Jul 1992 17:25:50 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <19190001@hpcss01.cup.hp.com> markw@hpcss01.cup.hp.com (Mark Williams) writes:
>But the patch didn't really fix the anomaly.  It helped two processor
>performance, but did not change the fact that 4-processor system ran no
>faster than a two processor system, at least in all the benchmarks I've
>seen.  

On the only benchmark that matters to me, they (running 4.1.2,
probably with the patch but I really don't know) work great.  Of
course, my benchmark suite is (optimizing) compiler testing.  If we
had twice as many 4P 600s, I'd be twice as happy, because I'd test
twice as much.

>Bottom line:  the 600MP (with SunOS 4 and the May patch) performs poorly as
>an MP system, but it is a fine uniprocessor with better I/O than a workstation.

In my (limited) experience it is a fine MP system.  Careful with those
blatant generalizations, sir.  I think I could make a few myself
about, say, the use{ful,less}ness of pattern-matching compiler
optimizations on non-SPEC codes.

Bottom line: Beware of benchmarks.

David Chase
Sun
Newsgroups: comp.arch