Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long)

[David Kessner]

In article <20030 at cbmvax.commodore.com> daveh at cbmvax.commodore.com (Dave Haynie) writes:
>In article <1991Mar20.100122.1717 at kessner.denver.co.us> david at kessner.denver.co.us (David D. Kessner) writes:
>>Please elaborate.  My 386 UNIX box does quite well being a "High performance
>>single tasking computer".  
>
>That is exactly what I claimed.  I suspect you meant to say that it worked well
>as a high performance multitasking computer, and then go on to discuss I/O in
>a single tasking mindset:

Hmmm.  The term "High performance single tasking computer" is is quotes because
that is the exact words you used to describe the typical 386.  I fully intended
to use the words "UNIX" and the quoted "single tasking" in the same sentance
to contrast my experiance with your "single tasking" comment.  Oh well.  It 
doesnt really matter much, anyway...

>There certainly is if you're multitasking.  The typical PC bus disk interface
>is a PIO (programmed I/O), non-DMA, 16 bit device.  Since you can run at
>faster bus speeds in many cases, and have a cached high speed CPU to do the
>data moves, you don't use the bus resident DMA controller, and that's good. 
>You can probably transfer about 3-5 MB/s between the jazzed AT bus and main
>memory, depending on your memory and all.  Fine for single tasking, you are not
>going to find single hard disks that exceed that rate.  However, the CPU does 
>have to be involved in that transfer, and in many cases sits around in a 
>tight PIO loop for the duration of transfer of an entire block or more.  In the
>A3000, you get 32 bit wide fully buffered DMA from SCSI.  Again, your single 
>disk isn't likely to exceed 2 MB/s.  However, since after setting up a 
>transfer, the CPU doesn't get involved again, and since the hard disk DMA
>controller always runs full speed cycles at 20 MB/s, you use at most 10% of
>your machine's bandwidth in a full speed transfer.  This leaves 90% available
>for running other tasks, rather than the 0% available during a tight PIO loop.

Hmmm.  On the original AT, it was found that using a busy loop rather than 
DMA was faster (although I forgot the exact reason for this).  This was a 
reasonable thing on an MS-DOS machine, but isnt the greatest thing on a 
multi-tasking machine (BTW, an XT does use DMA on it's drives, but an AT 
does not.)  To the best of my knoledge, all controllers have the ability to
do DMA transfers, but the controller BIOS has ultamate say as to which method
is used.  To add further variables...  The first thing UNIX does when it boots
on a 386/486 machine is switches out the BIOS (since they do not run in the
native 386 mode that UNIX uses).  This "makes it possible to use DMA anyway", 
and the developers of UNIX on a 386 may have done just that-- thinking that DMA
on a multi-tasking system is better...

Of course, this is all speculation-- as I don't realy know what the 386 UNIX 
developers did.  (BTW, there are "smart" disk controllers that do use the
DMA to it's full potential but I have not seen UNIX drivers for them).  
Also, if ANYONE quotes the above paragraph in a 'followup' or 'reply'  PLEASE
include this paragraph in the SAME QUOTE.  During the course of this discussion
some of my remarks have been taken (unintentionally) out of context-- and I
want everyone to know that the above paragraph is SPECULATION and any
resemblance to any hardware (alive or dead) is purely coincidental...

On a whole I would say this about the 386's UNIX disk performance:  Average.
There is nothing spectacular here (based on both transfer speed AND 'multitask-
ability').  There is room for improvement-- but it is certainly acceptable to
put 10 people on a 386/33 UNIX box.  If disk speed becomes a problem, you
could always add four meg of RAM and increase the disk cache/buffers (you can
get away with this on a cheap system).  You could also go for a cached
controller board (that has UNIX drivers).  I wont say that it is an optimal
solution-- but it is a UNIX system for under $5000 and you get what you pay
for..

>>Comparing the 030 with the 386 might be seen as a little skwed, and it is.  
>>But when the A3000UX comes in at HALF the speed of the 386 then it raises 
>>more than an eyebrow...
>
>It is a foregone conclusion.  All things being externally equivalent, the 
>'030 and '386 are pretty comparable.  However, when you compare the uncached
>'030 (A3000 or NeXT) against a cached '386, using a cache-sized benchmark,
>you are kind of stacking the deck in favor of the '386.  Not that I have any
>problem with the idea of a cache, it certainly will help some.  What you get
>here is a best-case estimate of its utility.

There is another issue here...  The BEST CASE 030/25 machine I have seen (of 
any brand) gets no more than 9000 dhrystones/sec.  I came up with this
figure by looking at EVERY figure given to me via mail or magazines.  Most 
were in the high 7000's, but there were several (30%) in the 8500 range.  
giving the 030 the benifit of a doubt I'll say the best case was 9000.  I did
thow out one figure of an 030/25 doing approx 12,000 because it was only one
in a list of about 60 figures.   Keep in mind that there were for 030/25's 
in general rather than just the A3000-- so most were cached...

On the other side, none of the 386/25 (cached or not) figures I have seen (via
the same method/sources as the 030/25's) were under 10,500.  It was closer to
11,500 for cached systems.  This is all assuming that the 386 benchmark was not
running under MS-DOG, where  the speed would be HALF that.  

Now, this indicates a very strong trend-- to which the A3000UX and my 386/25 
fit in nicely.  We are not talking a trend of two or three systems, but more
like a few hundred.  Take any dhrystone figure-- be it hearsay, marketing, 
Dhrystone 1.1, or real tests-- and plot a bell graph of the results.  The 
030/25 systems will peak at about 7500-8000, and the 386/25's will be around
11,500.  Because my figures fit this trend so closely, I don't question them
a whole lot and want to move on to other benchmarks...

Several people sent me mail about benchmark code (no actual code however :( )
and I will be sifting through them in the next few days.  Thanks all!

>3rd party tower cases for the A2000 have been around for some time.  Though the
>latest news from CeBit might make the market for an A3000 tower case a bit
>less attractive...

Hmmm.  Can someone tell me what the latest news from CeBit is?  I guess I
missed that one...

>Actually, completely responsible.  The C64 has a software UART, plain and 
>simple.  One port line for transmit, one for receieve, more for handshaking
>and all.  Using all the available CPU power, you could run a reasonably good
>1200 baud VT100 emulation with it.  It did the floppy disk stuff the same 
>way, albeit via a software generated synchronous serial port.  

It's comming back to me now...  Ahh, drive music!  On another topic here,
someone was telling me that the 3.5" drive for the C64 (the 1581?) has a 
faster 6502 in it-- like 4mhz or something.  Is this true?  I sold my 64
before it came out.  If it is true, why?  Better fidelity with drive music?

>>I should say a faster UART, perhapse with a FIFO.  Like the 16550...
>
>FIFO would be a good idea.  I would really like to see the UART redesigned
>to use video line DMA, like the floppy does.  So you get a pretty much 
>unlimited buffer.  Convincing the chip designers may take awhile on that one...

The 16550 UART supports DMA transfers, although this goes largely unused on
PC's-- for compatability with the older UARTs.  Hayes makes a board that uses
the DMA ability of the chip-- which Wimdows uses because the 16 byte FIFO isnt
enough for it's "multitasking".  Wont it be nice when Microsoft gets hit with 
an anti-trust suit?  (but you didnt hear me say that)

>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
>   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
>	"What works for me might work for you"	-Jimmy Buffett

-- 
David Kessner - david at kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);