sl35746@uxa.cso.uiuc.edu (By-Tor) (12/14/90)
I just had a talk with one of our system administrators here, and I told him about the A3000UX. He told me that Sun came out with a workstation that was 286 based and ran Unix along with PC's in windows that multitasked. I don't know of the model number, but he said they didn't sell, and Sun discontinued. AmigaDOS and Unix will not run at the same time, and there is a much smaller demand for Amiga compatibility than IBM compatibility, so I would think that there isn't going to be much of a demand for these things unfortunately. Considering you can buy a Sparcstation now for $3000 that comes inside a 1200x800 monitor that will outperform an A3000, with the expansion capability to reach 100 MIPS, I really don't see where the market is. Another interesting point he made was that Sun is almost guaranteed to support their computers. Commodore is just starting out, so things will be even harder. I don't really see the point of putting Unix on an Amiga. I think they should have just made a Unix box that was competitive, and started from there. The fact that AmigaDOS and Unix are totally isolated basically makes the point almost moot to combine them in one box. The Unix side is limited to the hard- ware that is needed to keep it Amiga compatible. I guess they only real market niche they could sneak into, and probably won't succeed in reaching, is a low-cost color workstation. If the current implementation of X doesn't support color, then there is no way anyone will buy it for color.
es1@cunixb.cc.columbia.edu (Ethan Solomita) (12/14/90)
I don't object to your stating your opinions, but PLEASE try to get your facts straight. Your message is riddled with errors. In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes: >I just had a talk with one of our system administrators here, and I told him >about the A3000UX. He told me that Sun came out with a workstation that was >286 based and ran Unix along with PC's in windows that multitasked. I don't >know of the model number, but he said they didn't sell, and Sun discontinued. That is a 386. It was called the Sun 386i. It failed for many reasons, not the least of which was its price of over $10,000 and the fact that it was much slower than the SparcStation which was cheaper. >AmigaDOS and Unix will not run at the same time, and there is a much smaller >demand for Amiga compatibility than IBM compatibility, so I would think that >there isn't going to be much of a demand for these things unfortunately. >Considering you can buy a Sparcstation now for $3000 that comes inside a >1200x800 monitor that will outperform an A3000, with the expansion capability >to reach 100 MIPS, I really don't see where the market is. The A3000UX isn't meant to be an AmigaDOS machine. It is meant to be a Unix machine. And yes, you can get the Sun Sparcstation SLC for appr. $3,000 on educational discount only (if a department in your school will buy it, that is), but the machine is totally unexpandable and doesn't even come with a hard drive. You have to hook it up to a network or buy an external drive and a case. Of course, there is no disk drive or tape drive attached either, that is extra and external. As to performance, once the 040 starts shipping the Amiga will be around the same speed of the Sun SLC (it is the slowest of the sparcstations), if not faster. And there is no way that the SLC could be expanded to 100 MIPS. It can't be expanded internally! >Another interesting point he made was that Sun is almost guaranteed to support >their computers. Commodore is just starting out, so things will be even harder. >I don't really see the point of putting Unix on an Amiga. I think they should >have just made a Unix box that was competitive, and started from there. The >fact that AmigaDOS and Unix are totally isolated basically makes the point >almost moot to combine them in one box. The Unix side is limited to the hard- >ware that is needed to keep it Amiga compatible. What should they have put it on? They already make Amigas and aren't about to start making their own Sparc chips like Sun is. The Amiga is simply the computer. Just because it runs on an Amiga doesn't mean it should have to run AmigaDOS. And the isolation isn't necessarily permanent. You don't know what Commodore is planning and neither do I. >I guess they only real market niche they could sneak into, and probably won't >succeed in reaching, is a low-cost color workstation. If the current >implementation of X doesn't support color, then there is no way anyone will >buy it for color. Since when doesn't X support color? Currently (I believe) the AmigaDOS version of X doesn't support color (although the new version has been shown) but the Unix X most certainly does support color. Basically, an A3000UX with 040 and UofL graphics card would make an excellent low-end color workstation, but then again so would an A3000 without Unix. -- Ethan Woody Allen on Los Angeles: "I mean, who would want to live in a place where the only cultural advantage is that you can turn right on a red light?"
rjc@wookumz.ai.mit.edu (Ray Cromwell) (12/14/90)
After weeks of the a3000ux discussion almost finally dying, someone decides to revive it again. Look, just face the facts that the reasons for purchasing something is dynamic and not merely based on some algorithm for determing absolute value of a product and then weighing it arithmatically again other products. If this wasn't so, Sega Genesis or Turbo Graphics would have no market against nitendo. Vax/Dec/NeXT/IBM would have no market against Sun. People willl buy Amiga3000UX's because they like them or see some value of owning them, not because some f(x)->power vs price equation says the Sun is better. I just hope this settles it. Obviously its impossible to force a change on someones opinion. So if you think the a3000ux is going to fail. Don't buy it. Let Commodore worrying about digging their own financial grave.
schweige@aldebaran.cs.nps.navy.mil (jeffrey schweiger) (12/14/90)
In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes:
<I just had a talk with one of our system administrators here, and I told him
<about the A3000UX. He told me that Sun came out with a workstation that was
<286 based and ran Unix along with PC's in windows that multitasked. I don't
<know of the model number, but he said they didn't sell, and Sun discontinued.
I don't know about a 286 box, but the Sun 386i is a capable machine. Sun
however does appear to be discontinuing the line.
<AmigaDOS and Unix will not run at the same time, and there is a much smaller
<demand for Amiga compatibility than IBM compatibility, so I would think that
<there isn't going to be much of a demand for these things unfortunately.
<Considering you can buy a Sparcstation now for $3000 that comes inside a
<1200x800 monitor that will outperform an A3000, with the expansion capability
<to reach 100 MIPS, I really don't see where the market is.
Sun's SPARC equipment is impressive (so are the SPARC-clones), and I like
being able to use them (I'm typing this on a SPARCstation 1+), but let's not
severely overstate the capabilities. I presume from the price that you are
referring to the SPARCstation SLC - (and I think that $3000 may be a bit low
even for that). The SLC has a single 20Mhz SPARC processor advertised at
12.5 Dhrystone MIPS (overall SPECmark 7.6), and is not expandable. It has a
monochrome 1152x900 noninterlaced display.
<Another interesting point he made was that Sun is almost guaranteed to support
<their computers. Commodore is just starting out, so things will be even harder.
A valid point with regard to Unix workstations, but it should be noted that
Sun seems to be trying very hard to get out of the Motorola 680x0 workstation
business and concentrate on the SPARC machines only. With regards to the
version of Unix for a 68030 based workstation, Commodore will be supplying
and supporting a newer system than Sun. It's my understanding that Sun will
not be producing a version of SVR4 for the Sun3 line. SunOS 4.1 will be the
final Sun3 release. SVR4 (SunOS 5.0) will be for the Sun4/SPARC line only.
<I don't really see the point of putting Unix on an Amiga. I think they should
<have just made a Unix box that was competitive, and started from there. The
<fact that AmigaDOS and Unix are totally isolated basically makes the point
<almost moot to combine them in one box. The Unix side is limited to the hard-
<ware that is needed to keep it Amiga compatible.
<
<I guess they only real market niche they could sneak into, and probably won't
<succeed in reaching, is a low-cost color workstation. If the current
<implementation of X doesn't support color, then there is no way anyone will
<buy it for color.
Commodore marketing obviously doesn't agree with you with regards to the
A3000UX, and if the Virginia Tech purchase is any indication, neither do a lot
of other people.
Jeff Schweiger
--
*******************************************************************************
Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645
Internet (Milnet): schweige@taurus.cs.nps.navy.mil
*******************************************************************************bj@cbmvax.commodore.com (Brian Jackson) (12/15/90)
In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes: >Another interesting point he made was that Sun is almost guaranteed to support >their computers. Commodore is just starting out, so things will be even harder. Sun just recently gave a fixed cut-off date for support of their 680x0 products. So the key word in there is "almost" :) >I don't really see the point of putting Unix on an Amiga. I think they should >have just made a Unix box that was competitive, and started from there. Define "Unix box." In the not too distant past Sun defined this as a big box with a monochrome monitor and Unix, all powered by a lone 68010. Is that a "Unix box"? If so then I would have to argue that a 25 mhz 68030 in a SMALL box with a COLOR monitor running Unix would qualify as well. >The fact that AmigaDOS and Unix are totally isolated basically makes the point >almost moot to combine them in one box. What other operating systems do you have running concurrently with Unix now? If you consider the A3000UX to be a "UNIX box" with the ability to also be an Amiga it takes on a different glow, no? > The Unix side is limited to the hardware that is needed to keep it Amiga >compatible. The hardware 'required' to run Unix is a subset of the hardware required to run AmigaOS. That means that Unix in an "Amiga box" gets to take advantage of graphics coprocessors and the like - things that Unix in other boxes can't. Some might consider this a plus. ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEmie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | |---------------------------------------------------------------------| | It requires a very unusual mind to undertake the analysis of | | the obvious." | -----------------------------------------------------------------------
cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) (12/15/90)
In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes: >I just had a talk with one of our system administrators here, and I told him >about the A3000UX. He told me that Sun came out with a workstation that was >286 based and ran Unix along with PC's in windows that multitasked. I don't >know of the model number, but he said they didn't sell, and Sun discontinued. > >AmigaDOS and Unix will not run at the same time, and there is a much smaller >demand for Amiga compatibility than IBM compatibility, so I would think that >there isn't going to be much of a demand for these things unfortunately. >Considering you can buy a Sparcstation now for $3000 that comes inside a >1200x800 monitor that will outperform an A3000, with the expansion capability >to reach 100 MIPS, I really don't see where the market is. > >Another interesting point he made was that Sun is almost guaranteed to support >their computers. Commodore is just starting out, so things will be even harder. >I don't really see the point of putting Unix on an Amiga. I think they should >have just made a Unix box that was competitive, and started from there. The >fact that AmigaDOS and Unix are totally isolated basically makes the point >almost moot to combine them in one box. The Unix side is limited to the hard- >ware that is needed to keep it Amiga compatible. > >I guess they only real market niche they could sneak into, and probably won't >succeed in reaching, is a low-cost color workstation. If the current >implementation of X doesn't support color, then there is no way anyone will >buy it for color. Well, normally I reside on "your side of the fence." That is to say, that I would prefer to have a 15 MIP SPARC box over an 030 based box given similar pricing. This is fine for people with a somewhat technical background, as they can get used to dealing with unix, shell programming, C programming, etc. However, I would speculate that 75% of the people who use computers have no idea what those things are, and even a smaller percentage that do know what they are would be able to cope well with the task. I think products like the Amiga 3000 are aimed at that grey area of people in between. The machine is simple enough to use that you can pop off-the-shelf software in and use it, but at the same time it offers the ability to run unix if you want/need it. I would think that very few people actually WANT unix and even fewer need it. However, it is "nice" that it will be available. All this talk about the 3000UX being a workstation is a little on the silly side (though I have done it myself in the past <blush>). Anyone who really needs a workstation will probably go out and buy a Sun/Apollo/etc. The markets are very different. You don't buy a Corvette to haul logs, and you don't buy a pickup to race around the track. Best regards and happy holidays, Chris ------------------------------+--------------------------- Chris Mauritz |D{r det finns en |l, finns cmm1@cunixa.cc.columbia.edu |det en plan! (c)All rights reserved. | Send flames to /dev/null | ------------------------------+---------------------------
rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (12/15/90)
>I just had a talk with one of our system administrators here, and I told him >about the A3000UX. He told me that Sun came out with a workstation that was >286 based and ran Unix along with PC's in windows that multitasked. I don't >know of the model number, but he said they didn't sell, and Sun discontinued. Actually it was a 386 machine, (I seem to remember that it was called the sun 386i). As I rember it was a good deal more expensive then the comprable dos machines (Anyone have a price range? I seem to remember a figure aroun 10K, but this could be wrong), enough so that you really had to have a need for both a UNIX workstation and a DOS PC for it to become worth the cost. >AmigaDOS and Unix will not run at the same time, and there is a much smaller >demand for Amiga compatibility than IBM compatibility, so I would think that >there isn't going to be much of a demand for these things unfortunately. >Considering you can buy a Sparcstation now for $3000 that comes inside a >1200x800 monitor that will outperform an A3000, with the expansion capability >to reach 100 MIPS, I really don't see where the market is. I think that the market will be for people like myself, who have been using amiga for a long time (I've still got a vintage 1000 from '86 that still work perfectly), who have invested in an accelerated amiga (a3000 in my case) that LIKE amigaDOS, but also have some use for UNIX. I really don't want to shell out $3K+ for another machine just to run unix (not to mention that I don't have any deskspace as it is), but I would like to have some of the features of unix for developing programs (and insuring that they are indeed portable to UNIX systems). right now I can use CMU's machines, but once I graduate I'll be on my own, so it would be nice if I could get UNIX for my 3000. I don't see the amiga becoming a major contender in the workstation market, there are already several VERY tough compeditors (DEC,HP,SUN etc.), but the distinction between a high end PC and a low end workstation is pretty fuzzy. Also UNIX can be used as a way to get amigas into government offices (which could mean lots of $$$$ for C=). I'm glad that C= is going to be offering UNIX, I think that it will strengthen the amiga's reputation and increase sales. // Rick Golembiewski rg20+@andrew.cmu.edu \\ \\ #include stddisclaimer.h // \\ "I never respected a man who could spell" // \\ -M. Twain //
davewt@NCoast.ORG (David Wright) (12/15/90)
In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes: >almost moot to combine them in one box. The Unix side is limited to the hard- >ware that is needed to keep it Amiga compatible. You couldn't be more wrong here. ANY Amiga with slots will outperform a PC-Compatible runing a Unix-type OS, with the exception of some (rare) clones that have full 32-bit EISA busses, and even then you would still not be able to beat the 3000 in performance, even with a '486. Unix demands a lot of RAM, and a very fast bus. the IBM ISA bus is very slow, and in most clones is only 16 bits wide. They also have much less DMA channels, and hardware has to be trickily configured to work around every other board in the system. I put Unix boxes togather every day, and in many loaded systems based on PC-type motherboards, it is simple IMPOSSIBLE to configure a system the way a client might want, due to hardware conflicts. An Amiga 3000, with an '030 or a '040 would leave a '386 or '486 system in the dust when it comes to hard drive and memory transfer speed over the bus, even if the PC was using an EISA bus. Not to mention that the 3000 will AUTOMATICALLY recognize over 1.2 GIGABYTES of RAM, with no user configuration whatsoever. Microsoft has locked the PC user into yet another memory bottleneck, if they ever got OS-2 off the ground. It only recognizes a maximum of 16 megabytes of RAM, and I have seen some PC clones that can now have up to 24 megabytes of RAM on the motherboard (a total waste in a machine with a 16 bit bus). There is just no way that the '386 clone you would be atlking about (if you want to try and compare by price) would have full 32-bit EISA slots, and full access to that much memory, thus making the 3000UX a far better machine to run Unix. But I suspect that being able to tell people that a machine can also run DOS will matter more to most people than how fast the hardware itself actually is. People believe what they read in PC world, not what their intelligence should tell them. > >I guess they only real market niche they could sneak into, and probably won't >succeed in reaching, is a low-cost color workstation. If the current >implementation of X doesn't support color, then there is no way anyone will >buy it for color.
ST402248@brownvm.brown.edu (F. Scott Porter) (12/17/90)
> An Amiga 3000, with an '030 or a '040 would leave a '386 or '486 >system in the dust when it comes to hard drive and memory transfer speed >over the bus, even if the PC was using an EISA bus. Not to mention that the >3000 will AUTOMATICALLY recognize over 1.2 GIGABYTES of RAM, with no user >configuration whatsoever. Unfortunately you are missing out on how the current crop of PC's handle High throughput devices. Most of the '386 and '486 machines have private memory buses which are not only 32 bits wide but extremely fast since they are very specialized. Some of the newer machines also implement SCSI devices in the same manner. Thus your argument about slow ISA and EISA buses doesn't apply to memory and sometimes doesn't apply to hard disk access. These things then become very machine specific. I'm not advocating any particular point of view about the relative speed/value of PC's versus Amiga's (grown out of that). Just trying to point out some mis-information. -- Scott. (ST402248@brownvm.brown.edu) Sig file left blank due to squashed creativity which is in turn squashed by the graduate school experience.
seanc@pro-party.cts.com (Sean Cunningham) (12/17/90)
In-Reply-To: message from rg20+@andrew.cmu.edu Even though Commodore has got the most complete version of the new Unix standard, have backing from AT&T, and are supporting the standards of the market's leader, people still underestimate them. That's going to make it all the more exciting when the doomsayers and the skeptics have to eat their words. The more and more Commodore is underestimated, the more likely the "big boys" and the wanna-bes get caught off guard and never see it coming. :') Sean >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .SIG v2.5 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< UUCP: ...!crash!pnet01!pro-party!seanc RealWorld: Sean Cunningham ARPA: !crash!pnet01!pro-party!seanc@nosc.mil Voice: (512) 992-2810 INET: seanc@pro-party.cts.com ____________________________________ // | * All opinions expressed herein | HELP KEEP THE COMPETITION UNDER \X/ | Copyright 1990 VISION GRAPHICS | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
davewt@NCoast.ORG (David Wright) (12/17/90)
In article <39228@nigel.ee.udel.edu> ST402248@brownvm.brown.edu (F. Scott Porter) writes: >Unfortunately you are missing out on how the current crop of PC's handle >High throughput devices. Most of the '386 and '486 machines have private >memory buses which are not only 32 bits wide but extremely fast since >they are very specialized. Some of the newer machines also implement As someone who puts these things togather at least once a week, I am not missing out on anything. I am quite aware that some *real* 386 systems have a seperate 32-bit memory bus. NO 386-SX (which are the most common 386 computers you will find) do. And even on the systems that do, there is seldom more than 8 megabytes provided for on the motherboard, and the completely non-standard busses used for the memory (as in the WYSE PC systems, etc.) means you can't take one mfgr.'s card and use it in another. Even on the systems I have seen that support up to 16 meg on the motherboard (remember the 3000 supports 18), there is seldom expansion provided beyond 16 megabytes. And I was not wrong when I said that OS-2 only supports 16 meg of "real" RAM. >SCSI devices in the same manner. Thus your argument about slow ISA >and EISA buses doesn't apply to memory and sometimes doesn't >apply to hard disk access. These things then become very machine >specific. I'm not advocating any particular point of view about the >relative speed/value of PC's versus Amiga's (grown out of that). Just >trying to point out some mis-information. This is again true, but even less than the RAM. I have yet to see ANY PC with SCSI built into the motherboard, although I am sure there must be one somewhere. I HAVE seen 32-bit EISA HD controllers, so at least a 32-bit controller could be added. But the whole point I was making was that the 16-bit bus on the Amiga 2000 series blows away (it's not even close) the 16-bit bus on ISA PC's, and the 32-bit bus on the Amiga 3000 series does beat the EISA bus, even if only by a smaller margin in some speed areas (but by more in others). And none of this stuff on the PC is truely "auto config". The PS-2's will do a kind of "auto config", IF youcopy the special driver onto your setup disk, and IF don't move your cards around, and IF the battery in your system doesn't go out and take your CMOS settings with it. On the Amiga your system is configured automatically every time you turn your computer on. You can move cards around, add cards, remove cards, anything, and it won't require you to run some kind of setup program. So setting up an Amiga-based system as a Unix box WOULD be faster, and most certainly WOULD be easier than on a ISA based system (which was the whole point of this thread). Everytime I have to hunt down which board is at which address, and what interupt it uses, and where it's shared memory is I have to cringe and wish I was working with an Amiga. Dave
ST402248@brownvm.brown.edu (F. Scott Porter) (12/18/90)
> So setting up an Amiga-based system as a Unix box WOULD be faster, >and most certainly WOULD be easier than on a ISA based system (which was the >whole point of this thread). Everytime I have to hunt down which board is at >which address, and what interupt it uses, and where it's shared memory is I >have to cringe and wish I was working with an Amiga. > Dave This is the part I was disputing. Since UNIX only cares about memory and disk speed private busses for these things make the issue much less straight forward than you are assuming. I'm not claiming that ISA or even EISA is faster than Amiga slots (I have no idea whether this is true or not) but that this is not an issue especially on most '386DX and '486 machines. With private memory buses and the somewhat rare private disk buses one cannot state categorically that these DOS based machines have slower I/O throughput. Since these are the only devices that UNIX really cares about (Other than Ethernet, which had a slower bandwidth than either of these buses anyway) if they aren't on the expansion slot bus than the bus is somewhat irrelevant. Of course if you are doing high bandwidth Data collection like I do, you better have something better than any of these anyway like direct access dual ported memory, etc... -- Scott (st402248@brownvm.brown.edu)
peter@sugar.hackercorp.com (Peter da Silva) (12/18/90)
In article <39304@nigel.ee.udel.edu> ST402248@brownvm.brown.edu (F. Scott Porter) writes: > This is the part I was disputing. Since UNIX only cares about memory > and disk speed private busses for these things make the issue much > less straight forward than you are assuming. You're missing the big one: VIDEO. Do you know how many wait states it takes to go from a 33 MHz 386 to a typical VGA card? Neither do I, but it was 17 wait states on the 16 MHZ machine I was using for X. Puts the overhead of Amiga high res screens into perspective, eh? And those Sun River fiber optic workstations must chew up quite a bit of CPU. Plus, a 16 MB hard memory limitation isn't to be sneezed at, either. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
thad@cup.portal.com (Thad P Floryan) (12/18/90)
It appears everything in and out of PORTAL between Dec.14 and Dec.17 has been
lost in the Great Bit Bucket. I've checked several other Bay Area sites and
did not find this, so I'm reposting. Sigh. If the original did, somehow,
get out during that period, send your nastygrams to CS@cup.portal.com ("CS" is
PORTAL's "Customer Service").
==============================================================================
bj@cbmvax.commodore.com (Brian Jackson) in <16532@cbmvax.commodore.com>
mentioned, in passing:
[...]
What other operating systems do you have running concurrently with Unix
now?
[...]
That's NOT a fleeting question! Three items may be of interest:
1) several years ago, in BYTE, was an article describing a 68020/68881/4MB RAM
card that simply plugged into an IBM-PC and ran UNIX, concurrently, with what
ever normally runs on an IBM-PC (MS-DOS, presumably). The card was a real
product and sold for $990 (special deal until the end of that year the article
appeared). A true, concurrent co-processor under DOS.
2) also several years ago, an "IBM 370" plug-in card for IBM PC systems was
available, and would run (I believe) OS/370. The card(s) utilized a pair of
customized 68000 chips (new masks) to completely hardware-emulate ALL the
instructions of an IBM 370 mainframe and permit the "mainframe" OS to run
concurrently with MS-DOS in an IBM-PC. The card set was sold by IBM.
3) more recently, you recall my discussing SVR3 curses vs. BSD curses and my
mentioning I "found" Aspen Scientific who provides a SVR3.2-compliant curses
(either binary or source) which functions under VMS, MS-DOS, etc. The demo
disk they first sent required me to run it under MS-DOS. Ugh; my favorite
joke for years has been "MS-DOS vadanya!" :-) But, I did need to run the demo
disk. Solution? I borrowed a "DOS-73" card (8 MHz 8086/8087, a full,
complete IBM/PC on a card, with IBM/Microsoft MS-DOS 3.10), plugged it into an
expansion slot on one of my 3B1/UNIXPC/PC7300 systems, created a 30MB "DOS" HD
partition (done SMARTLY as a single, 30MB UNIX file, no need to actually muck
with my UNIX HD partitions), loaded the demo disk, and ran the demos. A true,
concurrent co-processor under UNIX. Actually I kept the DOS-73 card since now
I can run ephemeris v4.21 in a window under UNIX to track astronomical events
of interest to me without bogging down the 68010.
The approach taken by AT&T/Convergent/Alloy for that DOS-73 card, circa 1985,
is similar in principle but quite different in approach to the BridgeBoard for
the Amiga. Point being: there ARE coprocessor cards out there running
different OS's concurrently with a host system. And I actually heard a rumor
that someone DID plug an OS/370 card into an A2000 along with a BridgeCard and
had all of AmigaDOS, MS-DOS and OS/370 running concurrently in the same "box".
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]davewt@NCoast.ORG (David Wright) (12/18/90)
In article <39304@nigel.ee.udel.edu> ST402248@brownvm.brown.edu (F. Scott Porter) writes: >This is the part I was disputing. Since UNIX only cares about memory >and disk speed private busses for these things make the issue much >less straight forward than you are assuming. I'm not claiming that I am aware that Unix really only cares about memory and disk speed (assuming you aren't doing a lot of terminal I/O, or a lot of graphics which are going over the bus) >this is true or not) but that this is not an issue especially on >most '386DX and '486 machines. With private memory buses and the This is where it is MOST important. You have a quite decent CPU that is bottlenecked by a very slow, and limited bandwidth bus. Like I said, MOST 386 systems, IF they are the real 386-DX and not 386-SX will have some amount of 32-bit memory on a private bus. But almost all of the units I have seen only support 8 meg on the motherboard, and only provide 1 *proprietary* slot for more memory expansion. There is NO industry standard for private busses, and one mfgrs RAM card won't work on another motherboard. And in almost every case these expansion RAM boards only let you add another 8 meg of RAM, for a maximum of 16 meg without using the slower (and usually 16 bit) bus. There is no way you are going to run 16 users with only 16 meg of RAM without doing quite a bit of swapping. >somewhat rare private disk buses one cannot state categorically that >these DOS based machines have slower I/O throughput. Since these are I never mentioned DOS at all. I am refering strictly to PC clones with ISA (and EISA) busses running some form of Unix. Someone running DOS will probobly not even see these things, since they only show up when you have several programs (and users) running at once. And Windows notwithstanding, you just don't normally run more than one or two things at a time under DOS. >the only devices that UNIX really cares about (Other than Ethernet, which >had a slower bandwidth than either of these buses anyway) if they aren't What kind of Ethernet are you using? Even the slowest will do 10 megabits/sec, and you can buy right now boards that will do over 100 megabits/sec. Stick 3 or 4 of these things in an ISA/EISA machine and watch your performance go down the tubes... >on the expansion slot bus than the bus is somewhat irrelevant. Of course >if you are doing high bandwidth Data collection like I do, you better have >something better than any of these anyway like direct access dual ported >memory, etc... I don't do any data collection, but I can tell you once you put more than one or two users on any Unix box you will quickly hit the limits of the ISA bus, unless you are running terminals at <=9600 (I always use 38400 or faster). There is nothing wrong with using a fast '386 as a personal workstation, as long as it is just that, personal. Trying to use a ISA-based system as the heart of a multi-user network is just a waste of any companies revenues. You would be better of buying a Sun, or a larger scaleable system like a Sequent or Pyramid and using more terminals. Dave >
m0154@tnc.UUCP (GUY GARNETT) (12/19/90)
In article <1990Dec14.045924.20212@ux1.cso.uiuc.edu> sl35746@uxa.cso.uiuc.edu (By-Tor) writes: >I just had a talk with one of our system administrators here, and I told him >about the A3000UX. He told me that Sun came out with a workstation that was >286 based and ran Unix along with PC's in windows that multitasked. I don't >know of the model number, but he said they didn't sell, and Sun discontinued. > >AmigaDOS and Unix will not run at the same time, and there is a much smaller >demand for Amiga compatibility than IBM compatibility, so I would think that >there isn't going to be much of a demand for these things unfortunately. >Considering you can buy a Sparcstation now for $3000 that comes inside a >1200x800 monitor that will outperform an A3000, with the expansion capability >to reach 100 MIPS, I really don't see where the market is. > >Another interesting point he made was that Sun is almost guaranteed to support >their computers. Commodore is just starting out, so things will be even harder. >I don't really see the point of putting Unix on an Amiga. I think they should >have just made a Unix box that was competitive, and started from there. The >fact that AmigaDOS and Unix are totally isolated basically makes the point >almost moot to combine them in one box. The Unix side is limited to the hard- >ware that is needed to keep it Amiga compatible. > >I guess they only real market niche they could sneak into, and probably won't >succeed in reaching, is a low-cost color workstation. If the current >implementation of X doesn't support color, then there is no way anyone will >buy it for color. I think you missed the point. Commodore *IS* trying to make a competitive, low cost Unix workstation. That it is an Amiga is almost irrelavant to the Unix discussion; Commodore took their most powerful design, and implemented a Unix for it. This is why the 3000UX doesn't even attempt to run AmigaDOS programs under Unix - they are not trying to sell unix boxes to Amiga owners, they are trying to sell unix boxes to buyers who want unix boxes. The reason they used a 3000 as the base machine is simple, too. In order to keep the workstation price down, the design and construction had to be inexpensive; by using an Amiga 3000, the design was already done and paid for (and there is nothing less expensive than that!), and the 3000UX also benefits from the fact that the assembly line is already set up, and from economies of scale with the A3000. The fact that it is *ALSO* an Amiga is gravy; better graphics performance at lower cost than would othewise be possible. Some users of the 3000UX might also be curious about AmigaDOS (or simply want to play Falcon, who knows) so the capability to boot and run AmigaDOS was left in (and besides, it might have cost Commodore more to take *OUT* AmigaDOS that to leave it in). I think Commodore has a shot at a good piece of market share in the low-end color workstation market. *IF* they don't blow it by some stupid pricing or marketing decision ... Wildstar
ST402248@brownvm.brown.edu (F. Scott Porter) (12/19/90)
>There is NO industry standard for private >Busses, and one mfgrs RAM card won't work on another motherboard. And in >almost every case these expansion RAM boards only let you add another 8 >meg of RAM, for a maximum of 16 meg without using the slower (and usually 16 >bit) bus. There is no way you are going to run 16 users with only 16 meg of >RAM without doing quite a bit of swapping. The Amiga 3000's motherboard memory could also be considered to be a private bus since it is connected to the RAMBO memory controller directly and not through a bus, and it isn't even in a slot. More memory than fits on the motherboard would also have to go into a possibly slower slot. > I don't do any data collection, but I can tell you once you put >more than one or two users on any Unix box you will quickly hit the limits >of the ISA bus, unless you are running terminals at <=9600 (I always use >38400 or faster). There is nothing wrong with using a fast '386 as a >personal workstation, as long as it is just that, personal. Trying to use > ISA-based system as the heart of a multi-user network is just a waste of >ny companies revenues. You would be better of buying a Sun, or a larger >caleable system like a Sequent or Pyramid and using more terminals. You think that I would use a PC of any kind as a high bandwidth file server (Amiga included)? You must be kidding. I also wouldn't use one for high bandwidth data collection either. Less venom, and a little respect would be nice too. None of us are stupid. And I still claim that you can't state categorically that the Amiga by the very nature of its bus out-performs intel based Unix boxes on I/O. This statement requires numbers, such as load under different numbers of real world processes. I hate to take the side of intel based boxes, since I would rather mow lawns for a living than write any more assembler on one. Flat address spaces FOREVER! -- Scott.
karl@ddsw1.MCS.COM (Karl Denninger) (12/25/90)
In article <1990Dec17.052316.19609@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <39228@nigel.ee.udel.edu> ST402248@brownvm.brown.edu (F. Scott Porter) writes: >>Unfortunately you are missing out on how the current crop of PC's handle >>High throughput devices. Most of the '386 and '486 machines have private >>memory buses which are not only 32 bits wide but extremely fast since >>they are very specialized. Some of the newer machines also implement > As someone who puts these things togather at least once a week, I >am not missing out on anything. I am quite aware that some *real* 386 >systems have a seperate 32-bit memory bus. NO 386-SX (which are the most >common 386 computers you will find) do. And even on the systems that do, >there is seldom more than 8 megabytes provided for on the motherboard, and >the completely non-standard busses used for the memory (as in the WYSE PC >systems, etc.) means you can't take one mfgr.'s card and use it in another. >Even on the systems I have seen that support up to 16 meg on the motherboard >(remember the 3000 supports 18), there is seldom expansion provided beyond >16 megabytes. And I was not wrong when I said that OS-2 only supports 16 meg >of "real" RAM. As someone who also puts these things together daily, services them to the chip level, and runs both DOS and Unix on these systems, I can assure you that the 386SX is not representative of anything. The 386/25 and /33 caching systems are more representative. And both are CHEAP and FAST. The SX machines are more like an Amiga 500 -- intentionally crippled hardware for a overly price-conscious consumer. Anyone who runs Unix on an SX-based system deserves the slow speed. "Seldom" does not equal "not available" on the RAM expansion. Check with the 486 owners -- most of them can do 64MB on the motherboard, using 4MB SIMMS. No problem; plug and play. >>SCSI devices in the same manner. Thus your argument about slow ISA >>and EISA buses doesn't apply to memory and sometimes doesn't >>apply to hard disk access. These things then become very machine >>specific. I'm not advocating any particular point of view about the >>relative speed/value of PC's versus Amiga's (grown out of that). Just >>trying to point out some mis-information. > This is again true, but even less than the RAM. I have yet to see >ANY PC with SCSI built into the motherboard, although I am sure there >must be one somewhere. I HAVE seen 32-bit EISA HD controllers, so at least a >32-bit controller could be added. But the whole point I was making was that >the 16-bit bus on the Amiga 2000 series blows away (it's not even close) the >16-bit bus on ISA PC's, and the 32-bit bus on the Amiga 3000 series does beat >the EISA bus, even if only by a smaller margin in some speed areas (but by more >in others). This is a non-issue. The ISA PC bus can pass 8MB of data per second. The best SCSI fixed disks we have available today can do 2MB/second. MOST disks cannot sustain that kind of transfer rate for long, even in synchronous mode. SCSI has a maximum transfer rate of 5MB/sec. That is STILL well under the ISA bus machine's bus bandwidth. Since there is little or no reason to put anything ELSE on that bus other than perhaps video, you have 4X the needed processor <> disk bandwidth. Anyone who tries to sell you more bandwidth than you need is a thief -- of your money, that is. Note that "real" controllers for the ISA bus, those which do bus mastering (AHA1542B for example) are here and do work. They take nearly all the load off the processor, do intelligent seek ordering, overlapped command/data requests, and all kinds of other wonderful things. Today EISA is a waste of money, as is MCA. ISA is more bus than you can use for disk I/O. Hell, I can do better with an ISA PC than most workstations in disk performance with a little judicious tuning of disk parameters! The one place where it COULD matter is in frame buffers. But only a fool has their CPU doing display-intensive work -- that's what special chips are for, right? And those chips damn well better be on their own PRIVATE memory bus, or you ARE going to see performance problems. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
davewt@NCoast.ORG (David Wright) (12/25/90)
In article <1990Dec24.220257.12208@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >"Seldom" does not equal "not available" on the RAM expansion. Check with >the 486 owners -- most of them can do 64MB on the motherboard, using 4MB >SIMMS. No problem; plug and play. Sure, but most people consider the '386 similar in performance to an '030 (though I am not one of them. In real-world use I have found the '030 to be faster). If you look at systems designed around the '040 you might also find that. I am also sure it has something to do with the price and market. No one would buy a '486 system that handled that much memory just to run DOS software, it would most certainly be for Unix. I am also sure that if you are using 4mb SIMMs (which aint cheap by far), you will be quite limited in your memory configuration, as you useually are when you use a system (like the Amiga 3000) that can handle 256k and 1mb chips. You either have a little RAM, or a lot of RAM, without small increments inbetween. For 4mb chips I would assume this would be even worse. >This is a non-issue. The ISA PC bus can pass 8MB of data per second. The >best SCSI fixed disks we have available today can do 2MB/second. MOST disks >cannot sustain that kind of transfer rate for long, even in synchronous >mode. Hogwash. It may be able to do BURSTS of that high, but I would like to see an 8 Mhz bus do 8mb a sec for any amount of time, even if the controller was taking over the machine to do it. > >SCSI has a maximum transfer rate of 5MB/sec. That is STILL well under the >ISA bus machine's bus bandwidth. You mean SCSI-I here, not SCSI-II. > >Since there is little or no reason to put anything ELSE on that bus other >than perhaps video, you have 4X the needed processor <> disk bandwidth. >Anyone who tries to sell you more bandwidth than you need is a thief -- of >your money, that is. Oh? Like maybe 64 port I/O boards? Or maybe even 16 port boards? Just how many users are you trying to stick in there without using some kind of I/O board in the ISA backplane? And all these other boards you are adding are further cutting down on the available bandwidth of the ISA bus. Next, if you are trying to run X on a VGA board, that will suck up a lot of the ISA bus bandwidth right there, not to mention the main CPU time. And finally, have you ever used a SCSI system with more than one drive? Don't forget that ALL the drives on a single host adapter share the same data port, and therefore help to eat up any remaining room that might have been left. If you have 2 or three SCSI devices, (best example would be a hard disk and a tape drive, with the tape drive backing up the hard disk), it is EASY to hit the limit of the ISA bus, even if the drives only do 2mb/sec. And as many of the better drives have on-board caches, which do read-ahead, you are likely to get big gushes of data coming in, from each device on the SCSI bus. > >Note that "real" controllers for the ISA bus, those which do bus mastering >(AHA1542B for example) are here and do work. They take nearly all the load >off the processor, do intelligent seek ordering, overlapped command/data >requests, and all kinds of other wonderful things. Agreed. And using a caching controller can help a lot too. >Today EISA is a waste of money, as is MCA. ISA is more bus than you can use >for disk I/O. Hell, I can do better with an ISA PC than most workstations >in disk performance with a little judicious tuning of disk parameters! Depends on who you are selling to. To Joe Blow off the street, that's true. But this thread was about the performance of ISA systems as Unix servers/workstations. Jow Blow doesn't do this kind of work, and certainly wouldn't pay the >$6000 for an entry level 16 user system. The only way ISA is "more than you can use" is if you have ONE device attached to it, and don't expect to do lots of large-scale data transfer (like swaps). Dave
karl@ddsw1.MCS.COM (Karl Denninger) (12/26/90)
In article <1990Dec25.045537.13517@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >In article <1990Dec24.220257.12208@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >>"Seldom" does not equal "not available" on the RAM expansion. Check with >>the 486 owners -- most of them can do 64MB on the motherboard, using 4MB >>SIMMS. No problem; plug and play. > Sure, but most people consider the '386 similar in performance to an >'030 (though I am not one of them. In real-world use I have found the '030 to >be faster). If you look at systems designed around the '040 you might also find >that. I am also sure it has something to do with the price and market. No one >would buy a '486 system that handled that much memory just to run DOS >software, it would most certainly be for Unix. I am also sure that if you are >using 4mb SIMMs (which aint cheap by far), you will be quite limited in your >memory configuration, as you useually are when you use a system (like the >Amiga 3000) that can handle 256k and 1mb chips. You either have a little >RAM, or a lot of RAM, without small increments inbetween. For 4mb chips I >would assume this would be even worse. Actually, this isn't that bad at all. With the systems I've sold and worked with, you can choose 1, 2, 4, 8, 16, 32, 48 or 64MB of RAM. That ought to be enough choices for nearly anyone. There ARE uses for 8MB+ in the DOS world -- Windows 3.0 in enhanced mode for example. And oh, by the way, Windows 3.0 is true multitasking AND protection of system memory space (ie: task partitioning) as well. '386 systems CAN equal the performance of an '030, depending on the memory architecture and design of the system as a whole. The main determinant is the cache arrangement; how well it's implemented and what method is used. Those differences don't tend to show up on benchmarks like the dhrystone, but they sure do under multiuser load. Properly designed 486 systems blow the '030 out of the water. The '040 is a reasonable match there, again dependant on the intelligence of the system design. Neither chip has an inherent advantage, unless you want to run MSDOS :-) . >>This is a non-issue. The ISA PC bus can pass 8MB of data per second. The >>best SCSI fixed disks we have available today can do 2MB/second. MOST disks >>cannot sustain that kind of transfer rate for long, even in synchronous >>mode. > Hogwash. It may be able to do BURSTS of that high, but I would like to >see an 8 Mhz bus do 8mb a sec for any amount of time, even if the controller >was taking over the machine to do it. Remember, some ISA PC's (this one for example) can clock at either 8, 10, 12 or 16Mhz. My current SCSI controller (Aha1542) can run comfortably at 50% bus utilization at an 8MHZ rate; this will max 2 SCSI drive transfer rates without trouble. If I'm willing to do some tweaking I can get perhaps 10-20% more, but this is more than the drives themselves can deliver, so I'm quite happy. In fact, I have to back off the controller transfer rate so as not to starve the drive read-ahead cache (which causes SCSI disconnects and thus slows down the transfer rate) If you shop motherboards carefully, and mess with the Aha1542 parameter block, you can get a 10Mhz transfer rate at 60% utilization without problems. >>SCSI has a maximum transfer rate of 5MB/sec. That is STILL well under the >>ISA bus machine's bus bandwidth. > You mean SCSI-I here, not SCSI-II. Yes, I mean affordable disk drives. :-) >>Since there is little or no reason to put anything ELSE on that bus other >>than perhaps video, you have 4X the needed processor <> disk bandwidth. >>Anyone who tries to sell you more bandwidth than you need is a thief -- of >>your money, that is. > Oh? Like maybe 64 port I/O boards? Or maybe even 16 port boards? Just >how many users are you trying to stick in there without using some kind of >I/O board in the ISA backplane? And all these other boards you are adding >are further cutting down on the available bandwidth of the ISA bus. Oh? Let's see..... 64 X 3840 X 2 bytes per second (38.4kbaud) = ~500 KB/sec, or not enough to even bother. It's lost in the noise and overhead. That's with a good (ie: Equinox) design that knows how to take the load off the processor. I have 24 ports in this system; with all 24 up, full duplex, 38.4k, it requires something like 5% of the processor to service the card. And a vanishingly small portion of ISA bus bandwidth. Interrupt-driven I/O on ANY system CPU will murder it. That's why you use intelligent I/O boards for these kinds of things. >Next, >if you are trying to run X on a VGA board, that will suck up a lot of the >ISA bus bandwidth right there, not to mention the main CPU time. Anyone who does this deserves what they get. Get a TIGA board if you want to do X windows; 14" screens aren't big enough anyway -- REGARDLESS of processor or system type. 17" is a minimum for reasonable utilization under "X". Try running Framemaker on a 14" screen sometime -- it's unusable. VGA is a cheap hack; it has reasonable resolution, fabulous color, but it isn't fast. No one has claimed it is/was. Get real video capability if you want it; the price isn't that unreasonable. Certainly cheaper on the ISA machine than equivalent capability on the Ami! (TIGA and i860 boards are just coming online for the Amigas) And for Gods' sake, get the frame buffer memory OUT of the system memory map and on a private bus where it belongs! >And finally, >have you ever used a SCSI system with more than one drive? Don't forget that >ALL the drives on a single host adapter share the same data port, and therefore >help to eat up any remaining room that might have been left. If you have 2 or >three SCSI devices, (best example would be a hard disk and a tape drive, >with the tape drive backing up the hard disk), it is EASY to hit the limit >of the ISA bus, even if the drives only do 2mb/sec. And as many of the better >drives have on-board caches, which do read-ahead, you are likely to get big >gushes of data coming in, from each device on the SCSI bus. Oh? This system, right here, has THREE Maxtor SCSI drives on it PLUS a SCSI tape. Sure, I can't max all three drives -- with one adapter anyway. With two adapters I can get damn close; Chantel makes the drivers which will allow this to work. I also have 24 high-speed serial ports on that same bus, and ethernet. The bus is STILL idle, at maximum registered load, more than 20% of the time. And I'm running ISA on this system; I don't have EISA. In fact, if I crank up the Adaptec the drive caches starve and cause SCSI bus disconnects. That is, the faster transfer rates on the controller translate to SLOWER real-world throughput! The fact of the matter is that you can't get anywhere near 2MB/second out of today's SCSI drives. A little over 1MB/sec is the best SCSI transfer rate I've measured on ANY system, and that was on a MIPS 3260 server. Cheating by repeatedly reading the same sector or track doesn't count -- I'm talking about reading 30-40MB data areas sequentially, so as to take into account head movement and settling time. When you start doing REAL I/O, with head movement all over the disk, you're not going to achieve anywhere near those rates with ANY disk drive. In the >real world<, 1MB/sec of sustained transfer rate per spindle is FANTASTIC. If you want more, you have to go to IPI or IPI-2 technology, which can do roughly double that (2.25MB/sec in real transfer rate). But those are 8" drives.... and much more money! That's ok though -- I can get more throughput with the 1542B than my $35K Sun workstation at work does under equivalent load. I didn't spend anywhere near as much money as Sun did either :-). >>Note that "real" controllers for the ISA bus, those which do bus mastering >>(AHA1542B for example) are here and do work. They take nearly all the load >>off the processor, do intelligent seek ordering, overlapped command/data >>requests, and all kinds of other wonderful things. > Agreed. And using a caching controller can help a lot too. A caching controller is usually a lose on a Unix machine. Put the memory on the system board, and crank the cache buffers. MOST of the time that's a win. The sole exception today seems to be when you have a 16MB hard RAM limit, and can use it all for user processes - then the cache controller gives you additional "buffer pool". Of course, with either of these strategies, a UPS is a must -- otherwise one power hit and the drive's data turns into soggy bread (which will make you MOST unhappy!). >>Today EISA is a waste of money, as is MCA. ISA is more bus than you can use >>for disk I/O. Hell, I can do better with an ISA PC than most workstations >>in disk performance with a little judicious tuning of disk parameters! > Depends on who you are selling to. To Joe Blow off the street, that's >true. But this thread was about the performance of ISA systems as Unix >servers/workstations. Jow Blow doesn't do this kind of work, and certainly >wouldn't pay the >$6000 for an entry level 16 user system. The only way ISA is >"more than you can use" is if you have ONE device attached to it, and don't >expect to do lots of large-scale data transfer (like swaps). Nonsense. 486 ISA systems make damn fine Unix workstations. The problem with servers is in the Ethernet performance, and that problem lies in the driver and board maker's camp -- not the ISA bus. Ethernet can pass, at a maximum, 1MB (megabyte) per second. Not a bit more. For high-speed graphics, get a real graphics card, and you'll have what you need. Don't try to make the processor do work it wasn't designed for through an inferior interface (VGA). NEITHER the Amiga 3000 or the ISA machine will make a good server. For that you need a real system bus, such as VME. You need real ethernet cards which can sustain high throughput (none of the ISA or Ami ones can do this at the protocol level). You need real drivers, which can use the power you have in the cabinet, and enough CPU to drive the boards to their limits. You need an operating system which is tuned specifically for this purpose. There's more needed too, but you get the idea.... Sure, I can make a reasonable server out of a Sun Sparcstation, a Mips Magnum, an ISA machine, and probably even an Amiga 3000UX. The question is how much throughput do you really expect to have, and how well will that system coexist with the rest of your network. I know where the limits are on the ISA system, the MIPS series, and the Suns. I have no idea on the 3000UX -- but I'll bet ethernet performance will be one of the sore spots. Hell, ISA Ethernet is faster than Ethernet on MCA systems! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
amiga@ccwf.cc.utexas.edu (Paul) (12/29/90)
Windows 3.0 is NOT true multitasking!!!!!!!! -- Amiga@ccwf.cc.utexas.edu .....Paul......
daveh@cbmvax.commodore.com (Dave Haynie) (01/04/91)
In article <1990Dec24.220257.12208@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >This is a non-issue. The ISA PC bus can pass 8MB of data per second. The >best SCSI fixed disks we have available today can do 2MB/second. MOST disks >cannot sustain that kind of transfer rate for long, even in synchronous >mode. >SCSI has a maximum transfer rate of 5MB/sec. That is STILL well under the >ISA bus machine's bus bandwidth. Uh, not quite. The ISA bus manages 4MB/s. However, you can't actually achieve that without some form of true DMA. Any CPU driven transfer is going to run from somewhere below 2MB/s (any 8MHz '286 system) on up, depending on the speed of the local memory the thing has available. Most asynchronous SCSI drives have a peak transfer rate of 1.5MB/s. There's a special asynchronous mode that manages 2.5MB/s. Synchronous mode can go as high as 5MB/s, and under SCSI-2 that's up to 10MB/s. That's hardly the only issue, though, if you're also considering running something like UNIX on this system. Assume a basic 1.5 MB/s SCSI drive. On the ISA bus, any PC is going to spend at least 40% of any given transfer period fetching data from the SCSI bus. That's assuming a fully buffered, interrupt driven SCSI controller that funnels the 8 bit SCSI data into 16 bit data for the ISA bus transfer. You can easily approach 100% of the transfer time with weaker SCSI card designs. The A3000, with the same drive, spends about 4% of the transfer time actually performing the I/O operation. Which gives you 96% of your CPU time to spend on other tasks, even with the drive running at peak. If you were just running MS-DOS or something, the two approaches would give you the same performance, but the former is going to drastically bog down under UNIX, especially if you get into much paging activity. >Since there is little or no reason to put anything ELSE on that bus other >than perhaps video, you have 4X the needed processor <> disk bandwidth. >Anyone who tries to sell you more bandwidth than you need is a thief -- of >your money, that is. You're still thinking single-tasking. In my opinion, anyone who makes your whole system drop down to the speed of the SCSI bus just to do a disk transfer is a their -- of your money and your CPU time. >They take nearly all the load off the processor, do intelligent seek ordering, >overlapped command/data requests, and all kinds of other wonderful things. Sure, you can take the load off the processor with any true DMA device, and if you make it intelligent it can do more for you. But on ISA there's nothing you can do to make the DMA device and the CPU access memory at the same time. So while you're transferring data, you have the CPU switched off. Again, it doesn't matter if you're not running a real OS, but since the only actual use for a PClone is UNIX anyway (assuming you don't have a better platform for UNIX), get need as much bandwidth as possible -- you can use it all. >Today EISA is a waste of money, as is MCA. For MS-DOS, sure. No arguments. Get a real OS and the differences will be striking. >Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) >Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] >Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price" -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
daveh@cbmvax.commodore.com (Dave Haynie) (01/04/91)
In article <1990Dec25.234322.836@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >NEITHER the Amiga 3000 or the ISA machine will make a good server. For that >you need a real system bus, such as VME. The A3000 bus, like EISA and MCA, isn't all that slower than full 32 bit VME. VME can kick up to about 66MB/s (as I recall). Zorro III theoretical limits (the numbers the VME, EISA, MCA, and NuBus people always give you) are 50 MB/s for single cycle, 150 MB/s for burst cycles. Typical values depend on the bus master -- the A3000 bus master implementation itself hits around 20 MB/s for single cycles. The A3000 local bus (where the 68030 and SCSI DMA sit) runs a minimal 20 MB/s to memory, which maxes out at around 44 MB/s (on-page burst to Fast RAM). CPU slot expansion memory can go considerably faster. While you can clock a "PC-AT" bus faster, the Industry Standard Architecture bus has a standard clock speed of 8MHz. It is 16 bits wide, and a transfer across it takes 4 clock cycles. Thus, you have a basic 4 MB/s bus. The A3000 will work as well as any personal computer and most workstations in an I/O intensive environment. No ISA bus machine even need apply. As for what's available now, VME would certainly win, since MCA and EISA are too new to have a good number of high performance cards available, and Zorro III is even newer still. >I have no idea on the 3000UX -- but I'll bet ethernet performance will be >one of the sore spots. Hell, ISA Ethernet is faster than Ethernet on MCA >systems! Hmmm, I'm sure all them folks with RS/6000 systems would be a little surprised by that comment. It depends on who built the boards, of course. The only Ethernet boards available now for the A3000 are Zorro II boards, which of course are slow, like ISA boards. The C= board is a non-DMA board, which is faster than the Ethernet boards we have in our PCs around here, but we most likely don't have the fastest ISA ethernet boards available. We also don't have the fastest Amiga compatible ethernet boards either -- two third parties (Hydra in England, who's board is marketed in the US by GVP, and ASDG) make bus mastering Ethernet cards which you'd expect to be much faster. >Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
telam@pyrps5.pyramid.com (Thomas Elam) (01/05/91)
In article <17084@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1990Dec24.220257.12208@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: > >>This is a non-issue. The ISA PC bus can pass 8MB of data per second. The >>best SCSI fixed disks we have available today can do 2MB/second. MOST disks >>cannot sustain that kind of transfer rate for long, even in synchronous >>mode. >>SCSI has a maximum transfer rate of 5MB/sec. That is STILL well under the >>ISA bus machine's bus bandwidth. > >Uh, not quite. The ISA bus manages 4MB/s. However, you can't actually >achieve that without some form of true DMA. Any CPU driven transfer is >going to run from somewhere below 2MB/s (any 8MHz '286 system) on up, depending >on the speed of the local memory the thing has available. Most asynchronous >SCSI drives have a peak transfer rate of 1.5MB/s. There's a special >asynchronous mode that manages 2.5MB/s. Synchronous mode can go as high as >5MB/s, and under SCSI-2 that's up to 10MB/s. > >That's hardly the only issue, though, if you're also considering running >something like UNIX on this system. Assume a basic 1.5 MB/s SCSI drive. On >the ISA bus, any PC is going to spend at least 40% of any given transfer >period fetching data from the SCSI bus. That's assuming a fully buffered, >interrupt driven SCSI controller that funnels the 8 bit SCSI data into 16 bit >data for the ISA bus transfer. Why is this, Dave? Because you are talking about a non-DMA design? Could the ISA bus-based PC spend less than the 40% by using a DMA design? > You can easily approach 100% of the transfer >time with weaker SCSI card designs. The A3000, with the same drive, spends >about 4% of the transfer time actually performing the I/O operation. Which >gives you 96% of your CPU time to spend on other tasks, even with the drive >running at peak. If you were just running MS-DOS or something, the two >approaches would give you the same performance, Because MS-DOS (or at least the non-interrupt-driven processing) just initiates the transfer then just spins in a loop waiting for the transfer to complete? Is that the way the PC's BIOS works? If so, I guess a getc() (get character) function would have to wait for a whole block to be read before returning a single character, correct? > but the former is going to >drastically bog down under UNIX, especially if you get into much paging >activity. Because it couldn't do its normal thing of scheduling another process, right? [deletion] >>They take nearly all the load off the processor, do intelligent seek ordering, >>overlapped command/data requests, and all kinds of other wonderful things. > >Sure, you can take the load off the processor with any true DMA device, and if >you make it intelligent it can do more for you. But on ISA there's nothing you >can do to make the DMA device and the CPU access memory at the same time. By "the same time," you mean upon demand, right? In other words, the CPU would be running in the scheduler or in another task (process), merrily accessing memory upon its demand, until the DMA has a word or burst to transfer, upon which it grabs the bus from the CPU and does the transfer. Right? >So while you're transferring data, you have the CPU switched off. Again, it >doesn't matter if you're not running a real OS, but since the only actual use >for a PClone is UNIX anyway (assuming you don't have a better platform for >UNIX), get need as much bandwidth as possible -- you can use it all. [deletion] >>Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) >>Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] >>Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price" > > >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "Don't worry, 'bout a thing. 'Cause every little thing, > gonna be alright" -Bob Marley I really appreciate your explanations, Dave. If I could get you to answer these questions I have, I would feel almost enlightened! Tom Elam
Radagast@cup.portal.com (sullivan - segall) (01/06/91)
>> >>That's hardly the only issue, though, if you're also considering running >>something like UNIX on this system. Assume a basic 1.5 MB/s SCSI drive. On >>the ISA bus, any PC is going to spend at least 40% of any given transfer >>period fetching data from the SCSI bus. That's assuming a fully buffered, >>interrupt driven SCSI controller that funnels the 8 bit SCSI data into 16 bit >>data for the ISA bus transfer. > >Why is this, Dave? Because you are talking about a non-DMA design? >Could the ISA bus-based PC spend less than the 40% by using a DMA design? > (I just finished designing a PC card, so I feel reasonably qualified to answer some of your questions. I should say though, that my end of the development, was mostly on the card, and not on the bus, so this information is really what I've gleaned from my co-developer while the design was in progress.) The ISA bus doesn't support multiple bus masters, so to get something into motherboard memory, you have to go through the CPU in some way shape or form. This makes a true DMA card impractical since you'd only be able to DMA to card memory, and that would not be addressable in 8088 mode, since all of the addressable memory of the 8088 is already allocated (and on the motherboard, or in display cards.) >> You can easily approach 100% of the transfer >>time with weaker SCSI card designs. The A3000, with the same drive, spends >>about 4% of the transfer time actually performing the I/O operation. Which >>gives you 96% of your CPU time to spend on other tasks, even with the drive >>running at peak. If you were just running MS-DOS or something, the two >>approaches would give you the same performance, > >Because MS-DOS (or at least the non-interrupt-driven processing) just >initiates the transfer then just spins in a loop waiting for the >transfer to complete? Is that the way the PC's BIOS works? If so, I >guess a getc() (get character) function would have to wait for a whole >block to be read before returning a single character, correct? > No, because the CPU is intricately involved in the transfer. Actually, I can't think of any OS that doesn't do what you are describing above to some degree or another. During a disk transfer under amigados, the task waiting on input has to wait for the entire transfer to complete. On the other hand, since the CPU isn't involved in the transfer, it is free to run other (CPU bound) tasks, (like the task scheduler.) For an IBM running UNIX, you could run other tasks during the latency time, but during the transfer the CPU is required to do the copying. Not very noticeable when only one task ik LC~?~?~?~?~?ik is running, but Fk~?~?~?~?~?~ >> but the former is going to >>drastically bog down under UNIX, especially if you get into much paging >>activity. > >Because it couldn't do its normal thing of scheduling another process, >right? > >[deletion] > >>>They take nearly all the load off the processor, do intelligent seek orderin g >, >>>overlapped command/data requests, and all kinds of other wonderful things. >> >>Sure, you can take the load off the processor with any true DMA device, and i f >>you make it intelligent it can do more for you. But on ISA there's nothing y o >u >>can do to make the DMA device and the CPU access memory at the same time. > >By "the same time," you mean upon demand, right? In other words, the >CPU would be running in the scheduler or in another task (process), >merrily accessing memory upon its demand, until the DMA has a word or >burst to transfer, upon which it grabs the bus from the CPU and does >the transfer. Right? > >>So while you're transferring data, you have the CPU switched off. Again, it >>doesn't matter if you're not running a real OS, but since the only actual use >>for a PClone is UNIX anyway (assuming you don't have a better platform for >>UNIX), get need as much bandwidth as possible -- you can use it all. > >[deletion] > >>>Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) >>>Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] >>>Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price" >> >> >>-- >>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" >> {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy >> "Don't worry, 'bout a thing. 'Cause every little thing, >> gonna be alright" -Bob Marley > >I really appreciate your explanations, Dave. If I could get you to >answer these questions I have, I would feel almost enlightened! > >Tom Elam
karl@ddsw1.MCS.COM (Karl Denninger) (01/07/91)
In article <17091@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1990Dec25.234322.836@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: > >>NEITHER the Amiga 3000 or the ISA machine will make a good server. For that >>you need a real system bus, such as VME. > >The A3000 bus, like EISA and MCA, isn't all that slower than full 32 bit VME. >VME can kick up to about 66MB/s (as I recall). Zorro III theoretical limits >(the numbers the VME, EISA, MCA, and NuBus people always give you) are 50 MB/s >for single cycle, 150 MB/s for burst cycles. Typical values depend on the bus >master -- the A3000 bus master implementation itself hits around 20 MB/s for >single cycles. The A3000 local bus (where the 68030 and SCSI DMA sit) runs a >minimal 20 MB/s to memory, which maxes out at around 44 MB/s (on-page burst >to Fast RAM). CPU slot expansion memory can go considerably faster. Ah, but it depends on how good of a job you can do interfacing with that bus. The VME people have a lot of experience with it, and they do a hell of a job. The "PC" people, whether ISA, EISA, MCA or Amiga, all seem to be more interested in shaving $5.00 off the price of the card than they do performance. >>I have no idea on the 3000UX -- but I'll bet ethernet performance will be >>one of the sore spots. Hell, ISA Ethernet is faster than Ethernet on MCA >>systems! > >Hmmm, I'm sure all them folks with RS/6000 systems would be a little surprised >by that comment. Oh would they? RS/6000s use 3Com boards for Ethernet the last time I looked. 3C523s. They are DOGS. I have worked with one, and it did something like 150KB/second of real throughput doing real work (ie: serving up an FTP file). That's terrible! Sorry, but 15% of the cable bandwidth doesn't cut it folks! Considering that a Sun Sparcstation can do something like 400KB/sec, and a "real workstation" like a MIPS Magnum does something like 600KB/sec (again, these are "real world" numbers at the file transfer level) the MCA bus systems that I've seen (of which the RS/6000 is one) leave a lot to be desired. I've seen servers (ie: MIPS 3260) hit something close to 750K/sec, which is 75% of the cable bandwidth and a darn good performance. Not coincidentally, user response times are in the "gawd that's fast" arena. >It depends on who built the boards, of course. The only >Ethernet boards available now for the A3000 are Zorro II boards, which of >course are slow, like ISA boards. Yep. And as long as the makers are more interested in cost than performance, it will stay that way. For a fileserver, this is NOT an acceptable tradeoff! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 808-7300], Voice: [+1 708 808-7200] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
daveh@cbmvax.commodore.com (Dave Haynie) (01/08/91)
In article <139982@pyramid.pyramid.com> telam@pyrps5.pyramid.com (Thomas Elam) writes: >In article <17084@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>That's hardly the only issue, though, if you're also considering running >>something like UNIX on this system. Assume a basic 1.5 MB/s SCSI drive. On >>the ISA bus, any PC is going to spend at least 40% of any given transfer >>period fetching data from the SCSI bus. That's assuming a fully buffered, >>interrupt driven SCSI controller that funnels the 8 bit SCSI data into 16 bit >>data for the ISA bus transfer. >Why is this, Dave? Because you are talking about a non-DMA design? >Could the ISA bus-based PC spend less than the 40% by using a DMA design? That's a rough figure based on what most PCs actually do these days. They use the host CPU, which it typically between 8MHz and 33MHz and has fast memory to talk to. At the high end, there is no real difference between DMA and non-DMA as long as the ISA bus is run at the standard 4MHz. You calculate the effective bandwidth in terms of bus crossings. For a true DMA device, you have one bus crossing per word, so that's an effective 4MB/s over the ISA bus. That's 37.5% of the available bus bandwidth, assuming a 1.5 MB/s SCSI device, plus you add in a little CPU time anyway to set up and service the DMA, so I rounded it up to 40%. Real DMA on the ISA bus is weird, and apparently there are lots of problems with it. I don't know all the details; some companies use it, some don't, and a few both use it and warn against using it (Chips and Technologies seems to fall into this last category). In any case, a fast 32 bit processor won't do much worse with a programmed I/O SCSI device, assuming of course it buffers and funnels the 8 bit SCSI data into 16 bit ISA bus data. Using a good block move operation, the '386 will get very close to the ideal of 1 bus crossing per word you get with DMA. It'll read two 16 bit words over the ISA bus, write one 32 bit word to its very fast memory on its private 32 bit bus. You can't get any better than the 37.5% of the ISA bus with ideal DMA, but you can get close. Exactly the same principles apply on the Amiga -- DMA devices are all under 50% of the bus bandwidth, but on a 68000 based system, non-DMA devices can come too close to using all 100% of the bus bandwidth. Replace the 68000 with a fast 68030 with 32 bit memory, and all of a sudden, the difference between true Zorro II DMA and programmed I/O drops to near insignificance. That is, until you add in real 32 bit DMA on a faster bus, which is just what we did in the A3000. And the same thing that happens when you use EISA, MCA, or a private 32 bit bus for DMA on a PC. You can grab DiskSpeed 3.1, set it up for CPU intensive operation or run a CPU time monitor as a separate task, and see the effect of this, spelled out in black and while (or color) for you, on different Amiga systems. And you'll also notice the difference in common use. Unfortunately, under MS-DOS, as long as you keep up with the disk drive, you aren't going to see any difference between a good and bad disk interface. In fact, it's possible to make a bad one that goes faster than a good one, simply by running pure polled I/O rather than using interrupts and hardware buffering (some companies do this on the Amiga too -- I call these "parasitic" controllers). So most companies don't supply you with a good hard disk interface on a PClone, simply because the additional cost and effort doesn't show up until you add UNIX or OS/2 or some real OS. >>If you were just running MS-DOS or something, the two approaches would give >>you the same performance, >Because MS-DOS (or at least the non-interrupt-driven processing) just >initiates the transfer then just spins in a loop waiting for the >transfer to complete? Is that the way the PC's BIOS works? I don't know, but that's not the reason. The reason is that you're single tasking. On the Amiga, even if a single I/O operation is done synchronously, causing that particular task to block for the duration of the I/O operation, other tasks are free to run, and you'll generally notice the overall performance increase. If all your other tasks froze for a second or two whenever a disk operation happened, you'd notice it, believe me. On a single tasking system, you don't have the option of asynchronous I/O, of course, and since the one task must block until the data it needs is loaded, the preceived performance of the whole system, same as that of the one task, is based on the disk speed, not the transfer efficiency. Macs, at least up until the IIfx, work much the same way, concentrating on single task efficiency. >If so, I guess a getc() (get character) function would have to wait for a >whole block to be read before returning a single character, correct? I would expect so. >> but the former is going to >>drastically bog down under UNIX, especially if you get into much paging >>activity. >Because it couldn't do its normal thing of scheduling another process, >right? Well, in any multitasking OS, one task blocking for I/O should, if anything, free up CPU time for the other competing tasks. If your whole system blocks, then for the time it takes the I/O operation to complete, you are effectively a single tasking system. In simple terms, a 6 MIPS fully blocking '386 or Mac system would get no work done during a 1 second I/O operation, while a 6 MIPS A3000 would get about 5,640,000 average instructions executed. I mention UNIX specifically, since [a] it pages, so system throughput can be much more diskbound than nonpaging systems, and [b] its large, especially in it's latest V.4 incarnation with all the bells and whistles running (X, Open Look, NFS, etc), so it tends to page lots unless you have enough real memory. >>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" >I really appreciate your explanations, Dave. If I could get you to >answer these questions I have, I would feel almost enlightened! I like to explain some of these important but more esoteric hardware related issues, because I rarely seem them explained correctly in print or much elsewhere. In that most PCs in use are singletasking, programmed I/O, and often only 16 bit, these issues are often glossed over. >Tom Elam -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
daveh@cbmvax.commodore.com (Dave Haynie) (01/08/91)
In article <1991Jan07.054805.13284@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >In article <17091@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1990Dec25.234322.836@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >>>NEITHER the Amiga 3000 or the ISA machine will make a good server. For that >>>you need a real system bus, such as VME. >>The A3000 bus, like EISA and MCA, isn't all that slower than full 32 bit VME. >Ah, but it depends on how good of a job you can do interfacing with that >bus. The VME people have a lot of experience with it, and they do a hell of >a job. The "PC" people, whether ISA, EISA, MCA or Amiga, all seem to be >more interested in shaving $5.00 off the price of the card than they do >performance. That tends to be true. You do get good Zorro II bus designs for the Amiga, but since that bus is so slow, it's no big deal. Same with the basic ISA bus, I imagine. VME has been around for a long time, and the mere existence of PCs has forced the performance of VME devices up the scale of things, both in performance and cost. And PCs have only recently grown 32 bit multiple mastered buses, while most VME systems have been doing that for some time. So sure, VME (and Multibus, etc) are more mature. They pretty much have to be, at those prices. >>Hmmm, I'm sure all them folks with RS/6000 systems would be a little surprised >>by that comment. >RS/6000s use 3Com boards for Ethernet the last time I looked. 3C523s. >They are DOGS. I have worked with one, and it did something like >150KB/second of real throughput doing real work (ie: serving up an FTP >file). That's terrible! Sorry, but 15% of the cable bandwidth doesn't cut >it folks! As I recall, the Personal Workstation folks seemed quite impressed by the I/O capabilities, if not the CPU speed claims, on the RS/6000. Its SCSI, on the MCA bus, was one of the fastest they've tested. I thought the Ethernet was too. It depends alot on your Ethernet load, too. We have days around here where the VAXen and big MIPS machines on our network have trouble hitting 15KB/second in ftp. Other days they move along quite fine, though Ethernet's never as efficient as the Apollo network, even with those little 68020 based Apollos. You don't need much CPU power to have a fast network, just a good network design and a good network implementation. >Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "Don't worry, 'bout a thing. 'Cause every little thing, gonna be alright" -Bob Marley
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/08/91)
How can someone say that the Amiga running ethernet can't perform well? I did a benchmark on an Amiga network running AmigaNet software and Hydra systems ethernet boards. The network had 7 Amiga workstations (2500/30) banging on a single 2500/30 file server and the performance is outstanding. I assembled a 10000 line source file on both a local and remote hard disk partition. The assembler generated over 200K of code and 300K of listing file. The assembly took 17 seconds to local hard disk and 18 across the network. When you consider that the Amiga is not specially designed to work as a file server as most server-type machines are, the performance is quite good. As a matter of fact, I seriously doubt that you can match this performance with many other machines. Just how much can you do on a Sparc in 15 seconds, especially to a remote hard disk? In a word, the Amiga screams! mykes
leblanc@eecg.toronto.edu (Marcel LeBlanc) (01/10/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Jan07.054805.13284@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: ... >>RS/6000s use 3Com boards for Ethernet the last time I looked. 3C523s. >>They are DOGS. I have worked with one, and it did something like >>150KB/second of real throughput doing real work (ie: serving up an FTP >>file). That's terrible! Sorry, but 15% of the cable bandwidth doesn't cut >>it folks! Then show us a machine that can do better. (Relax, the LAST thing I want to do is defend IBM or the RS/6000.) >As I recall, the Personal Workstation folks seemed quite impressed by the >I/O capabilities, if not the CPU speed claims, on the RS/6000. Its SCSI, >on the MCA bus, was one of the fastest they've tested. I thought the Ethernet >was too. It depends alot on your Ethernet load, too. We have days around >here where the VAXen and big MIPS machines on our network have trouble >hitting 15KB/second in ftp. >... You don't need much CPU power to have a fast network, >just a good network design and a good network implementation. Having spent the last 2 years researching ways of improving the speed of network interfaces, I can safely say that implementation is extremely important. 150KByte/s at the application level is really very good. You are paying a performance penalty because of the fact you are running UNIX. Incoming packets are copied multiple time as they go from the Ethernet hardware to kernel buffers, and eventually to user space. The limiting factor with the current (poor) BSD TCP/IP implementation is most often memory speed (especially in this case, where maximum packet size will be used). I doubt that IBM has spent much time optimizing their implementation since researchers have only come to realize in the past few years where the real protocol processing bottlenecks are. Only now that people are locating the real bottlenecks can _great_ network interfaces be designed. >>Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" Marcel A. LeBlanc -- Electrical Eng. Computer Group, Univ. of Toronto ----------------------------------------------------------------------- leblanc@eecg.toronto.edu else: uunet!utcsri!eecg!leblanc
peterk@cbmger.UUCP (Peter Kittel GERMANY) (01/11/91)
In article <dhansen.5282@amiganet.UUCP> dhansen@amiganet.UUCP (Dave Hansen) writes: >I don't believe you are comparing oranges to oranges when you compare the >AmigaNet FTP to standard TCP/IP FTP. The AmigaNet is not a standard file >transfer protocal. Hmm, there are already many different net protocols available for the Amiga. And Commodore has already announced officially the AS225 software which definitely IS TCP/IP. I should know, because I recently had to proofread the German translation of the manual. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/12/91)
In article <725@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <dhansen.5282@amiganet.UUCP> dhansen@amiganet.UUCP (Dave Hansen) writes: >>I don't believe you are comparing oranges to oranges when you compare the >>AmigaNet FTP to standard TCP/IP FTP. The AmigaNet is not a standard file >>transfer protocal. > >Hmm, there are already many different net protocols available for >the Amiga. And Commodore has already announced officially the >AS225 software which definitely IS TCP/IP. I should know, because >I recently had to proofread the German translation of the manual. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk First: I am comparing Amiga on ethernet with similar to unix features to what unix uses. Second: AmigaNet 2.0 is under development and they claim that under 2.0 you will be able to use the same ethernet board to run Novell, TCP/IP, and AmigaNet at the same time. So the Amiga could theoretically be on multiple networks from different vendors at the same time. Also you should be able to run X under AmigaDos environment. Sounds too good to be true to me!
danb20@pro-graphics.cts.com (Dan Bachmann, SubOp) (01/13/91)
In-Reply-To: message from leblanc@eecg.toronto.edu
I at first thought the A3000 was a waste, but after a careful look, it
is a worthwhile thing.
I have an A500, and (in a year or two) want to upgrade to an A2000,
5MB, A2630 (68030 accelerator), SCSI card & drive, and a Bridgeboard. Now with
the A3000 I get all of that without wasting space except for the Bridgeboard
(does anyone know if a Bridgeboard works in an A3000 yet? How about the '386
one).
As far as all the stuff that does not work right on the A3000... it is
mostly games so that is no major concern for my and as far as hardware... it's
RAM boards and SCSI cards... but that is on the motherboard of the A3000, so
why bother anyway?
So, in short, the A3000 is definitely worth it for some one in my
position, but it would be good for many A2000 owners to be able to get the 2.0
Kickstart ROM also.
-------------------------------------------------------------------------
ProLine: danb20@pro-graphics ***************************
UUCP: ...crash!pro-graphics!danb20 * Dan Bachmann *
ARPA/DDN: pro-graphics!danb20@nosc.mil * Raritan Valley College *
Internet: danb20@pro-graphics.cts.com ***************************
P-Link: DanB20 <-- I only read PLink once a mo. use Internet
U.S.Mail: 509 StonyBrook Drive, Bridgewater, NJ 08807