HDTenEightyP/NetNews huggingface dataset:
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Keith's Computer, Hope Mills, NC
Date: Tue, 22 Dec 92 20:21:15 GMT
Followup-To: comp.misc

Note follow-up line.

In article <1992Dec21.220736.27684@rchland.ibm.com> kunkel@vnet.ibm.com writes:
>The B20 is the second smallest AS/400 ever shipped and was announced

So What

>4.5 years ago.  The current largest model is about 20 times faster
                            ^^^^^^^^^^^^^^^
So do you wish to compare the most expensive AS/400 you can buy to a
486/33.  Give me a break, or better yet give me some compile, & sort
times for say 1000 line RPG programs and 50-100MB database files using
the native compiler and #GSORT.  Even better yet I can mail you the one
I used & We'll compare

>(TPC-C type benchmark).  The B20 is also a multi-user system.  What

So was the SCO Unix on a 486/33 I tested it against.  The SCO box also
had *MORE* Crap hung off it.

>were the other 10 or 20 users doing when you compiled?  Any batch
>jobs running?  TPC-C is a system benchmark.  A compile is a CPU
>benchmark.  There is a different.  The AS/400 system has a couple

Yep, Transactions test the disk & I/O more than the CPU.  I shant argue
with you there.  However, I did the comparison *AFTER* We were switched
over when absolutely NOTHING was going on on the AS/400.  There were
only 3 Terminals and 1 Printer Varied on at the time.  Only one Terminal
was active.  On the '33 at the same time there were 2 Highspeed modems
doing a file transfer, and 3 or 4 people doing Word Processing.  Nothing
Heavy there either. 

>(many hand fulls on the high end) of cheap, off-the-shelf micros
>thrown in as a cost effect way of off loading I/O processing from
>the CPU.

So does my 486/33 (which was upped to a 66 last month or so).  I've got
a Digiboard C/X system with 4 286 CPU's in it (You know, the stuff your
brothers hang on the RS/6000).  The new ones use a RISC I think.  The
Disk Controller has a 16Mhz 68000 Chip.  And all the Drives Are SCSI (Oh
yea, that needs cpu's huh).  That's 5 more.  Oh and of course the SCSI
tape (8mm) has one too.  That makes a total of 11 dedicated cheap off
the shelf I/O processors, and you ain't just whistling dixie about
offloading.  I did a simple loop test on the Digiboard vs a pair of
16550's on the bus (ISA SIO card), and the System load difference is
amazing.  Like 1/10th.  The SCSI card takes care of the mirroring
transparently too.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
Newsgroups: comp.arch,comp.sys.intel
From: daved@convex.com (David Dorfman)
Subject: What is a TC-2000
Summary: please help me understnad this 
Keywords: help
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Tue, 22 Dec 1992 16:38:14 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

could someone polease drop me a mail message describing what a TC-2000
Computer is , who manufactures it and a general description of the
architecture.

Thanks
Dave Dorfman

Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: zrepachol@cc.curtin.edu.au
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 19:40:12 GMT

In article <15609357@zl2tnm.gen.nz>, don@zl2tnm.gen.nz (Don Stokes) writes:
> mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
>> Actually, I've seen alot of people here call RMS "the file system."  For those
>> of you who still think that RMS is the file system, I'll clue you in: RMS
>> is not the file system.
> 
> Perhaps you'd like to explain why the back of the RMS manual looks like:
> 
> 		V M S
> 		_________________
> 		
> 		*Volume 6B*
                         ^
Perhaps you could tell the nice reader what else is in vol 6.

> 
> 		*File System*
> 
> 		Record Management
> 		Services (RMS)
> 
> Seriously, RMS is all-pervasive in VMS.  Sure, you can do QIOs to the 
> XQP yourself, and RMS even provides an interface to make this a little
> easier.  But 99.999% of the time, there is no reason to do so.  This is
> what differentiates the VMS approach from the Unix universe.  Files on
> VMS can (almost) always be read and written using RMS, often this means
> that you can use tools intended for sequential files on indexed or 
> relative files.  Compare the Unix approach, where if you use anything 
> other than a sequential file, other utilities can't do anything useful
> with it.  It's a standardisation issue more than anything else -- provide
> a standard, easy way to do something and it will be used.  If you don't
> you get a plethora of non-standard wheel re-inventions.  Providing an
> ISAM package with the *FORTRAN* compiler (of all things) as one poster
> commented on, just doesn't cut it in this regard.
> 

But U*** still loses because it has no way of telling the application what
TYPE of file structure it is...

> This is what VAX C does.  It still succeeds in being dreadfully slow,
> although it wouldn't take much effort by someone who knew something about
> file handling to write a VAXCRTL that does block I/O and goes like a
> scalded cat.  VAXCRTL is completely braindamaged in nearly every respect,
> and seriously needs to be thrown away and started again.  
> 

Never a truer word spoken... The intertwining of the C language and Unix IO
is a *HUGE* mistake.

~Paul

Newsgroups: comp.arch
From: sl@wimsey.bc.ca (Stuart Lynne)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Wimsey Information Services
Date: Wed, 23 Dec 1992 07:22:57 GMT

In article <id.HD1W.X03@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Dec21.141558.18626@rchland.ibm.com> cecchi@rchland.vnet.ibm.com (Del Cecchi) writes:
>>  So How does that 486 run when you put 10 or 20 users on it doing order
>> entry?.  

>Now I won't say I was happy with the performance on the 286, but the current
>systems with moderately old 386es are adequate, and our 486 box screams.

My 486 used to scream. So I switched to a DX2-66. Now only my dog can hear it :-)


-- 
Stuart Lynne <sl@wimsey.com> ......................... UNIX Facsimile Software
Wimsey Information Technologies ................... moderator biz.sco.binaries
uucp login:nuucp passwd:nuucp .................... ftp.wimsey.com:~ftp/ls-lR.Z
PD Software for SCO UNIX .................... ftp.wimsey.com:~ftp/pub/wimseypd
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Any new instructions in a i486?
Organization: Adobe Systems Incorporated
Date: Tue, 22 Dec 1992 04:30:40 GMT

In article <1992Dec21.190305.513@qb.rhein-main.de> vhs@rhein-main.de (Volker  
Herminghaus-Shirai) writes:
> Wrong. NeXT says it will run on 486SX, 486DX, and follow-ups to
> the '86 line. Support for Pentium is for sure. Since NeXT has worked
> together with intel on the port (from what I heard) I'd guess NeXT had
> to sign a contract banning support for Cyrix's part.
> 
Its almost certainly true that NeXT has Pentium hardware in house and is  
working closely with Intel. I doubt they signed a contract boycotting Cyrix  
though. Having such agreements in writing looks bad during Federal Trade  
Commission investigations if you know what I mean...
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Newsgroups: comp.arch,comp.sys.intel
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: Superscalar vs. multiple CPUs ?
Date: Wed, 23 Dec 92 20:03:26 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

In article <PCG.92Dec23144916@decb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:

>How innocent! I use both GNU Emacs and Microsoft Word, and they are both
>inconsiderate eaters of CPU time,

GNU Emacs is a LISP operating system disguised as a word processor. 

At least you don't need LISP for Word; I assume Word for Windows? I use it
when I need a really pretty document, but damned if I don't stick to
Word Perfect for DOS for my casual writing, cuz of the screen display.

I suppose if I bought a SVGA board with an accelerator on it, I'd be happy.
Until I realized how dinky my screen is at home when compared to the 17"
monitors here at work. 

> not to mention TeX. The latter eats up
>about 10 million instructions per page. As editors and word processors
>become more powerful, feature laden, and sport ever greater degrees of
>multimediality, the are going to suck up CPU even more.

So we'll be able to put sound in documents. Rah..

Most of the world has problems getting an ASCII text message correct and
software companies now want to throw in full motion video?!?! Ack-pttthpft.

                    I have talked to Ehud, and lived.
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Xenix Support, FICC
Date: Wed, 30 Dec 1992 18:39:53 GMT

In article <1992Dec26.003022.25532@bilver.uucp> wbeebe@bilver.uucp (Bill Beebe) writes:
> >Now I won't say I was happy with the performance on the 286, but the current
> >systems with moderately old 386es are adequate, and our 486 box screams.

> Maybe I *really* am dumber than a box of dirt, but why, in this day of
> networking, would anyone do team development on a single box when it would
> appear that team development on networked single-user boxes would be a lot
> more efficient?

Because team development on networked multiuser boxes is better than either.
Not everyone needs 27 MIPS full time. You can do low-impact stuff on shared
boxes, and have database and compile servers for big builds. Because a 386
with an adequate bus underneath is is plenty fast for typical software
development tasks, even multiuser. Because distributed computing means that
some system you've never heard of can stop you dead. Because we don't have
enough money to buy the sort of workstation we'd like for every developer,
but we've got a perfectly adequate network of Xenix boxes already. Because
the tools we need aren't available on UNIX, but are available on Xenix, and
multiuser development on DOS is a joke. Lots of reasons.

> Why do we still need multi-user boxes except to support obsolete business
> practices?

Because they work?

Sure, we're moving over to workstations, but it's going to take time.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: feustel@netcom.com (David Feustel)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: DAFCO: OS/2 Software Support & Consulting
Date: Thu, 24 Dec 1992 23:15:05 GMT

kolding@cs.washington.edu (Eric Koldinger) writes:

>In article <Bzs3zn.43H.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:

>The AS/400 uses a tagged memory-system and tagged registers to protect
>capabilities (or pointers, as they call them).  There are also a number of
>operations that only take place on capabilities.  This makes it rather unlikely
>that they'd use a stock micro-processor from the workstation group.  You could, 
Is there an description of the AS/400 hardware architecture available?
Thanks.
-- 
Dave Feustel N9MYI <feustel@netcom.com>
 
                        Happy Holidays to ALL!!!
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Compaq's Proposed Scalable I/O Architecture
Date: 23 Dec 92 19:36:15 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Distribution: usa
Organization: GE Corporate R&D Center, Schenectady NY


  This whole thing reminds me of 1950s mainframe design ala GE. The
heart of the system was the memory controller, and CPUs connected to the
memory controller(s), as did the i/o controller(s) (IOC). Off the i/o
controllers were the peripheral controllers (MPC - microprogrammed
controllers), and off those were the actual devices. With bandwidth
appropriately higher as you got closer to the memory.

  You had eight port memory controllers which could talk to any mix of
1-7 CPUs and 1-7 IOCs. If memory bandwidth became a problem you split
the memory between more memory controllers. If you ran out of i/o you
split devices between MPCs, or MPCs between IOCs. All datapaths to
memory were 72 bits, I *think* the IOC to MPC was 36, but I could be
wrong.

  Now a limit of 8 anythings isn't going to suffice in all cases today
(and didn't then), but the idea of hierarchical bandwidth is hardly new,
since these machines were shipping in the late 50s.

  One interesting artifact of this design is that cache may be on the
CPU *or* on the memory controller. Putting it on the controller
certainly eases problems of consistency, assuming you can resolve timing
problem having the cache off the CPU.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: timhu@ico.isc.com (Timothy Hu)
Newsgroups: comp.arch
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-
Date: 21 Dec 92 21:34:04 GMT
Organization: Interactive Systems Corp., Boulder CO

> Sun's CMW (shipping in volume as of 12/17/92) only needs a regular admin and a
> security officer (who is required for any secure facility anyhow), and is being
> evaluated for the DISA CMW (B2+ security).

How can you tell if a machine has any security installed?
-- 
Timothy Hu timhu@ico.isc.com	 | The intelligence (or lack of) expressed
Interactive Systems Corporation  | above does not necessarily reflect the
Resource Solutions International | that of anyone else.
Newsgroups: comp.arch
From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Tue, 22 Dec 1992 01:14:14 GMT


In article <id.2K0W.G37@ferranti.com>, peter@ferranti.com (peter da silva) writes:

>You seem to have a strong opinion about this, so could you explain to me
>precisely how the UNIX API is lacking, and what specific features of NT
>would be impossible under a UNIX API.

Which UNIX API? (Here we go again. :-)
Asynchronous I/O.
Waiting for multiple synchronisation objects.
ACLs on objects.
Quotas.

>Why did Microsoft have to create
>a completely new API from scratch, and implement it in such a way that
>programs using it are entirely insulated from their UNIX API environment
>(POSIX shell)?

Which new API? POSIX 1003.1, which is a standard and therefore hardly new?
1003.1 is an API standard, not a shell standard.

>
>Well for UNIX, where access to virtually all system resources is provided
>through the filestore, I would agree. But NT has half a dozen different
>mechanisms for interacting with the system... how can multiuser security
>be managed if it only protects a minor part of the system?

All interactions with the NT kernel go through the object manager, and hence
through the security subsystem.

>Since OS/2 and NT have virtually the same level of backwards-compatibility
>with DOS, how do you make out that the OS/2 approach is any way diferent?

NT uses the protected subsystem approach made popular by Mach. OS/2 provides
a DOS API, but the NT kernel knows nothing about DOS, since DOS (and OS/2, and
POSIX, and...) APIs are provided by the subsystems.

>I'm sorry, but you seem to be discussing a completely different set of
>software packages than I'm familiar with or have been discussed in the
>media.
>-- 
>Peter da Silva                                            `-_-'
>Ferranti International Controls Corporation                'U` 
>Sugar Land, TX  77487-5012 USA
>+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

We seem to have moved into software architecture. :-)

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

Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Def  of a workstation (a lark)
Reply-To: vhs@rhein-main.de
Date: Sun, 3 Jan 93 23:53:27 GMT

In article <1993Jan3.052930.27869@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari)  
writes:
> 	We all spend time with strange people for New Years..
>  
> 	So I'm trying to explain to a friend who has just bought a 
> 	new Gateway system (dx2-66, lb ATI ultra @ 1024x768, running
> '	OS/2) what a workstation is (he asked, because I was discussing
> 	the schools computer lab and used the word), and, well.. 
>  
> 	Can anyone give me a definition of workstation, other than 
> 	cost, that seperates it from modern high-end PC systems (in his
> 	case, one that cost no more than $3500).  
> 
> 	At first I was tempted to talk about UNIX or RISC, but these
> 	were less than satisfactory (UNIX because he could be running
> 	UNIX, and RISC sounds deficient--those old M68k based Suns are
> 	still workstations...and then there's the 386i...)..
>  
> 	Anyone?  Come to think of it, it's pretty muddled to me, too.

The high lowest common denominator. Workstation software relies
on stuff like TCP/IP suppport, the UNIX tool set, multiuser/multitasking
OS, high resolution screens, mouse, etc. The lowest common denominator
for a PC is still an 8088 with MDA and 512K (realistically). 
You won't find software that's written for and
really takes advantage of the resources of high-end PCs, even if that's
what the vendors want to make you think. E.g. M$-Windoze's incredibly
clumsy mouseless mode (since they can't rely on everyone having a mouse)
that shines through the mouseful mode, clumsifying the latter, too.
(Additional menu items for move, resize, etc that are useless if you have
a mouse since no one in his sane mind would use them then.)
The video-mode desaster is another example. I have yet to see a workstation
that keeps switching between "text-mode" and a horrendous amount of
"graphics-modes" (except for the RS6000, which does text/graphics mode. Sigh.
A decent workstation has IMHO *at least* the following items of which the
software can and does take advantage of:
	a high-resolution screen
	a pointing device
	an ethernet connection (or token ring if your management was bribed ;-)
	a UN*X operating system with TCP/IP support and a C compiler
	a boot prom that allows for interactive diagnosis etc.
	a decent amount of RAM and hard disk space
	a tape drive for backups and data exchange as opposed to floppy disk
	other items I may have forgotten (it's already tomorrow...;-)

Software writers are usually driven to write for the lowest reasonable
common denominator, so if any of the above items don't exist in the base
configuration of a workstation line, forget at least 50% of their usefulness
if you have them. (E.g. >50 AIX or SCO UNIX installation disks vs. one tape.
Newer releases may give you one or two floppies and a tape, but still no
delivery on CD-ROM, as far as I see. Also no installing via ethernet, since
not everybody has it, etc.)

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de), NeXTmail welcome

Looks good on the outside, but -
	intel inside
Newsgroups: comp.arch
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: VMS vs "Unix"
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 24 Dec 1992 14:41:23 GMT

In article <23DEC199215322500@jhuvms.hcf.jhu.edu> ecf_stbo@jhuvms.hcf.jhu.edu (When I boot to device appear to me these a messages it is) writes:
:In article <1992Dec23.195640.17777@crd.ge.com>, davidsen@crd.ge.com (bill davidsen) writes...
:>  joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename
:> 
:>may work from anywhere on the net, but you need to know the node name,
:>physical device name, and lots of syntax with variable numbers of
:>colons, and [names] as well.
:
:It's very easy for the system manager can set up logical names to make
 
Would all of you carrying on this ridiculous holy war please take it
elsewhere? It has nothing to do with computer architecture.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Xenix Support, FICC
Date: Tue, 22 Dec 1992 15:31:03 GMT

In article <id.2K0W.G37@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> You seem to have a strong opinion about this, so could you explain to me
> precisely how the UNIX API is lacking, and what specific features of NT
> would be impossible under a UNIX API.

In article <1992Dec22.011414.21727@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
> Which UNIX API? (Here we go again. :-)

The basic UNIX model of resources as objects in the file name space, the basic
UNIX system calls, and so on. Clean extensions are, as they have always been,
encouraged.

> Asynchronous I/O.
> Waiting for multiple synchronisation objects.

I've proposed a general asynchronous *interface* for system calls, that would
allow both of these. There is no conflict with the UNIX API that would require
abandoning it.

> ACLs on objects.

Andrew has this, without abandoning the UNIX programming model.

> Quotas.

I've seen both hierarchy and user quotas.

> >Why did Microsoft have to create
> >a completely new API from scratch, and implement it in such a way that
> >programs using it are entirely insulated from their UNIX API environment
> >(POSIX shell)?

> Which new API?

Win32.

> POSIX 1003.1, which is a standard and therefore hardly new?

That's not the native API, nor the one Microsoft is using for primary NT
software development. And you can't make Windows calls from a program
running under the POSIX shell.

(shell, in this case, is apparently Microsoft's term for an emulation
 environment... it's not the command line interpreter)

> >Well for UNIX, where access to virtually all system resources is provided
> >through the filestore, I would agree. But NT has half a dozen different
> >mechanisms for interacting with the system... how can multiuser security
> >be managed if it only protects a minor part of the system?

> All interactions with the NT kernel go through the object manager, and hence
> through the security subsystem.

But is the object manager mapped into a filestore name space? If not, what
was meant by that original remark, do you think?

> >Since OS/2 and NT have virtually the same level of backwards-compatibility
> >with DOS, how do you make out that the OS/2 approach is any way diferent?

> NT uses the protected subsystem approach made popular by Mach. OS/2 provides
> a DOS API, but the NT kernel knows nothing about DOS, since DOS (and OS/2, and
> POSIX, and...) APIs are provided by the subsystems.

How does this affect the quality of the emulation: that is (getting back to
the original comment), why would you have to buy "all new software" under
OS/2 but not under NT?
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"