xenon@tcr.UUCP (Chris Hanson) (03/12/91)
Background: I am a salesperson at The Computer Room, in Denver, CO. We've
had 3000UX's since day 1, and in fact, it appears we were one of the first
stores to get them for retail. We have Beta3j software right now. These are
some of my questions/consternations.
1) Why Black & White XWindows? The 3000, and indeed all Amiga models, is/
are capable of 4096 colors, 16 at a time in the most useful resolutions. But
yet the top-of-the-line, most expensive, flagship computer of the Amiga line
has software limiting it to 2-color. (Or shall I say, 2 pre-selected shades
of grey, namely BLACK and WHITE). GfxBase has shown (with their Amiga
XWindows terminal system) that it is quite possible to do a snappy 16-color
X display. With the Amiga's reputation for excellent graphics, it is a real
injury to step down to this Mac-Plus-Wannabe mode to use XWindows. I have
heard that color X will not be available without the A2410 board. If so, why?
Is this some sort of sick marketing move to drum up support for the 2410? I'd
already love to have a 2410, and I don't think this sort of tactic is
necessary.
2) I understand that AT&T has defined Open Look to be the standard window
manager for System V Release 4. Fine by me, I've ignored dumb standards
before in favor of better solutions, and so has most of the rest of the
world. (We bought Amiga, didn't we? Lose that MS-DOS standard.) When can I
perhaps expect Motif 1.x (preferably 1.1, please! ;) to be available? I have
seen such notes on this network tht say that German developers have a
preliminary version operating, but that Commodore-Amiga is saying nothing
concerning when or even IF this will be available. My essential question is
this: Should I start the port myself, or is there a reasonable possibility
that it will be done by Commodore-Amiga?
3) Much the same question applies to X11R4. I have heard it stated
unofficially on the net that the version 2.0 of Amiga Unix will include X11
Release 4. Is this true? (Is anyone listening to me? ;)
4) Carrying on the Unix version 2.0 thread, it has also been said that
version 2.0 will allow the user to rebuild the kernal, like any other self-
respecting Unix package. Is this reasonably close to being fact?
5) When will the wonderous 2.0 release be available? (If in fact it is
more than a net-myth.) Please don't say "soon", because your idea of soon, my
idea of soon, and in fact, the Dali Lama's idea of soon are probably
seperated by a large margin of difference. Besides, I can't sell ANYBODY a
3000UX if the only promise I can make of solving their doubts is "A new
version will be available ...soon... that fixes feature z..."
6) We're running Unix on a 4 fast/2 chip A3000/25 with 100 meg drive and
320 meg external. I know Unix is _expected_ to be a real memory-pig, but by
the time the system comes up and allows me to login to the ksh, I am already
paging about 2 megabytes. Is this normal?
7) I have also run a rough benchmarking program (that supposably computed
drystones per second) on the 3000UX/25, an 030 NeXT, and a DTK 80386/25
running ESIX SysV R3.2.2. The NeXT averaged about 9000, the 386 about 12000,
and the 3000 got about 3200. For comparison, the 3200 reading was from code
compiled with the AT&T cc compiler. Compiling the same source with the GNU
gcc compiler netted us a figure of over 6500. Much better, but still not
fantastic. You figure. Is this normal? The program is not a memory intensive
benchmark, so swapping should not have been a real problem. Can someone
perhaps post benchmarks/benchmark programs to the contrary?
8) The 3000 (and UX) both have a very slick memory-processor
architecture (Thank you, Dave Haynie!), but I have long wondered why a
off-processor cache system was not implemented. The 68030's internal cache is
too small to be of much use in Unix, and it's duty in AmigaDOS seems to be to
point fingers at those game programmers who used self-modifying code. ;) I
know that a cache can be implemented via the high-speed CPU slot, but it
seems like it would have been better integrated into the system from the
start. Would a, say 256k SRAM cache significantly improve performance?
Now, please don't read this posting wrong. This is not a flame, or a
ragging, or whatever. I've used Commodore machines since the VIC-20, and I
love 'em. I've always liked Unix, and I think the 3000UX is a nice machine.
It is still overcoming a few of it's birthrights though. I also realize that
NONE of you Commodore-Amiga tech people and engineers can actually officially
say anything. But I'm left high 'n dry here in Denver without some real info.
Answer, if you will, with your opinions, or perhaps refer me to someone
official who I _really_ can pester. ;>
Note: AT&T, Unix, NeXT, Amiga, Commodore, AmigaDOS, Mac, XWindows, OpenLook,
Motif, and probably many other words I've used, are trademarks, copyrights,
or some other form of license. Rest assured that I am using them WITHOUT
permission of their owners, and frankly, I don't care. What a rebel am I.
Thank you for allowing me this blatent mis-use of your ASCII bandwidth.
We now return you to your regularly-scheduled drivel. And remember, Quantum
Leap is on Wednesdays now, and trash pickup has moved to Tuesdays.
Chris - Xenon
#define chris@kessner.denver.co.us Chris_Hanson|Lord_Xenon|Kelson_Haldane
(303)/762-0849 Home, (303)/696-8973 Work, 1-976-DEV-NULL for flames.
For quick fun, do "worms | tee | mail root" and let it run for 30-40 secs...cpetterb@es.com (Cary Petterborg) (03/13/91)
In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: > 2) I understand that AT&T has defined Open Look to be the standard window > manager for System V Release 4. Fine by me, I've ignored dumb standards > before in favor of better solutions, and so has most of the rest of the Dumb Standards? Motif is, IMHO, not as good as OpenLook. I use a system running Motif for more than 8 hours a day. I also use OpenLook applications. I have also read in great detail the Style Guides for both. So I am not ignorant of the issues. If you want Motif, go ahead and port it! > world. (We bought Amiga, didn't we? Lose that MS-DOS standard.) When can I > perhaps expect Motif 1.x (preferably 1.1, please! ;) to be available? I have > seen such notes on this network tht say that German developers have a > preliminary version operating, but that Commodore-Amiga is saying nothing > concerning when or even IF this will be available. My essential question is > this: Should I start the port myself, or is there a reasonable possibility > that it will be done by Commodore-Amiga? > > 3) Much the same question applies to X11R4. I have heard it stated > unofficially on the net that the version 2.0 of Amiga Unix will include X11 > Release 4. Is this true? (Is anyone listening to me? ;) X11R4 gives you at two advantages and falls sort in at least two from OpenWindows (NeWS/X11). The advantages it has are slightly better performance on most (but not all) platforms, and a smaller executable (freeing up some memory). It doesn't have postscript support and the font technology that NeWS/X11 has. Those two things are at the top of the list for the next release of X11. So why not take advantage of having it today. Or do you want to go back to programming BASIC too? ;-) My $0.02. Cary -- _______________ Cary Petterborg (801)582-5847 x6446 Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 USENET: utah-cs!esunix!cpetterb INTERNET: cpetterb@esunix.es.com
brett@visix.com (Brett Bourbin) (03/14/91)
In article <CPETTERB.91Mar13105501@mickey.es.com> cpetterb@es.com (Cary Petterborg) writes: >In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: > > >> 2) I understand that AT&T has defined Open Look to be the standard window > >Dumb Standards? Motif is, IMHO, not as good as OpenLook. I use a ^^^^^^^^ >system running Motif for more than 8 hours a day. I also use OpenLook >applications. I have also read in great detail the Style Guides for >both. So I am not ignorant of the issues. If you want Motif, go ahead >and port it! > >X11R4 gives you at two advantages and falls sort in at least two from >OpenWindows (NeWS/X11). The advantages it has are slightly better ^^^^^^^^^^^^^^^^^^^^^^ Commodore is not shipping OpenWindows with the NeWS/X11 server, they are shipping a X11 server based on the OPEN LOOK spec. It does not have the NeWS postscript extensions, it does not have the server enhancements, it is a different product from the SUN OpenWindows. With that said, I too work with Motif, but work with OPEN LOOK since our products have both Look-N-Feels. They both have their merits and their pitfalls. I like the idea of push-pins for menus and dialogs from the OPEN LOOK spec, but the "zoom" effect for notices is a pain to work with if your server does not have shape extensions. The spec gets around this by saying you can not pop-up a dialog or any type of window when one of these "zoom" notices is on the screen. (OpenWindows actually grabs the server with is against the OPEN LOOK spec.) The end results should be, IMHO, "Let the user decide". If they wish to get the Motif package, then Commodore should be willing to supply them with such. If they want an OPEN LOOK environment, the same. X application developers, such as Visix, are starting to ship software that will allow users to pick their Look-N-Feel. Sorry about the plug. 8^) >Cary Petterborg (801)582-5847 x6446 -- __ Brett Bourbin \ / /(_ /\/ 11440 Commerce Park Drive ..!uunet!visix!brett \/ / __)/ /\ Reston, Virginia 22091 brett@visix.com Software Inc (703) 758-2733
cpetterb@es.com (Cary Petterborg) (03/14/91)
In article <1991Mar13.232504.6947@visix.com> brett@visix.com (Brett Bourbin) writes: > The end results should be, IMHO, "Let the user decide". If they wish to get > the Motif package, then Commodore should be willing to supply them with such. > If they want an OPEN LOOK environment, the same. > > X application developers, such as Visix, are starting to ship software that > will allow users to pick their Look-N-Feel. Sorry about the plug. 8^) > > __ > Brett Bourbin \ / /(_ /\/ 11440 Commerce Park Drive > ..!uunet!visix!brett \/ / __)/ /\ Reston, Virginia 22091 > brett@visix.com Software Inc (703) 758-2733 I just heard about LookingGlass' Motif/OL switch yesterday from our accounts rep. I whole heartedly applaud the user being able to choose between which system they want to use. Afterall, the user interface should "empower the user". If he works better in one environment, let him use it. My comments to which Brett was responding may have sounded like I feel that Open Look is the only way to go. I don't think it is the only way to go, but that if I had to choose one or the other, I would choose Open Look. But, then, alas, the choice was made for me to use Motif. Way to go VISIX! May the force be with you guys. And, let everyone else know how to do what you are doing! Cary -- _______________ Cary Petterborg (801)582-5847 x6446 Evans & Sutherland Computer Corp. Simulation Division SLC, UT 84108 USENET: utah-cs!esunix!cpetterb INTERNET: cpetterb@esunix.es.com
jet@karazm.math.uh.edu ("J. Eric Townsend") (03/15/91)
In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: >I know Unix is _expected_ to be a real memory-pig, but by Unix is *not* a memory pig by definition. Vendors who want to add everything under the sun to the kernel are the "memory pigs". -- J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2120 Skate UNIX or bleed, boyo... (UNIX is a trademark of Bell Laboratories).
daveh@cbmvax.commodore.com (Dave Haynie) (03/15/91)
In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: > 7) I have also run a rough benchmarking program (that supposably computed >drystones per second) on the 3000UX/25, an 030 NeXT, and a DTK 80386/25 >running ESIX SysV R3.2.2. The NeXT averaged about 9000, the 386 about 12000, >and the 3000 got about 3200. For comparison, the 3200 reading was from code >compiled with the AT&T cc compiler. Compiling the same source with the GNU >gcc compiler netted us a figure of over 6500. I think they typically get something like 8000 Dhrystone 2.1's per second under AmigaOS using the SAS C compiler. Are you sure you have the same version of Dhrystone on these systems? I could believe some extra software overhead in UNIX, but not that much, unless you're sitting around paging, or the compilers are abysmal. Also, the A3000 and '030 NeXT are very similar in hardware terms. With the same benchmark and same GNU compiler, I would expect them to produce very similar results. Either that '386 compiler has one of these "Dhrystone detect features", or you're using a Dhrystone 1.1 and/or a Dhrystone-sized cache on the thing. That's the largest number I have ever seen for a 25MHz '386 system. In fact, that would be pretty good for a 33MHz '386 in MS-DOS/take over the machine mode. > 8) The 3000 (and UX) both have a very slick memory-processor >architecture (Thank you, Dave Haynie!), but I have long wondered why a >off-processor cache system was not implemented. Same reason its not on the NeXT -- cost. The A3000 does have a place to put a cache board, or, if you'd rather, a 68040 board. These aren't available yet, but I would expect to see something at least from the third parties (two 68040 boards for the A3000 are already announced but not shipping) sometime this Spring. >The 68030's internal cache is too small to be of much use in Unix, Actually, it helps out quite a bit, believe it or not. The internal cache isn't large, but it is efficient. Since the 68030 has separate internal data and instruction paths, when both caches hit, you wind up doing fetches in parallel where the pipeline permits. When one hits, you may wind up hiding some or all of a fetch to the main CPU bus by the other cache/fetch unit. This sized cache isn't going to hold entire programs, but it's not bad on program inner loops, or function calls (if you UNIX folks still push stuff on the stack, call a function, and then pop it off). >and it's duty in AmigaDOS seems to be to point fingers at those game >programmers who used self-modifying code. ;) Actually, it speeds things up considerably. Keep in mind that the caches aren't simply just caches, but they work with the 68030's burst/prefetch mechanism. So you load quadlongwords twice as fast with the cache being used versus without it, even if you just manage to hit the 4 longwords in that burst. >Would a, say 256k SRAM cache significantly improve performance? Sure would. External cache isn't as effective as internal cache, but it's in general a good idea. The cost police made an option. Also, taking a careful look at the A3000 motherboard, if you find a place for it, I'll keep it in mind for the next generation :-). >#define chris@kessner.denver.co.us Chris_Hanson|Lord_Xenon|Kelson_Haldane -- 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.denver.co.us (David Kessner) (03/15/91)
In article <19887@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >I think they typically get something like 8000 Dhrystone 2.1's per second >under AmigaOS using the SAS C compiler. Are you sure you have the same version >of Dhrystone on these systems? I could believe some extra software overhead >in UNIX, but not that much, unless you're sitting around paging, or the >compilers are abysmal. Also, the A3000 and '030 NeXT are very similar in >hardware terms. With the same benchmark and same GNU compiler, I would expect >them to produce very similar results. Either that '386 compiler has one of >these "Dhrystone detect features", or you're using a Dhrystone 1.1 and/or a >Dhrystone-sized cache on the thing. That's the largest number I have ever >seen for a 25MHz '386 system. In fact, that would be pretty good for a 33MHz >'386 in MS-DOS/take over the machine mode. I am the owner of the 386/25 mentioned in Chris Hanson's original artical, so here is my two cents worth... The same Dhrystone program was used on all of these machines. They were compiled with the standard GNU compilers on the NeXT and A3000UX, and with GCC Version 1.36 on the 386/25. On the A3000 and 386/25 the only compiler option specified was "-O". I dont know what options were used on the NeXT, as a friend did it for me. I know that this is an Amiga group, but perhapse some of my 386 UNIX experiance is worthwhile. The 386/25 has a 64K external cache-- which is larger than the dhrystone program. This test was ran under UNIX and MS-DOS. Under MS-DOS, it got 8000 dhrystones/sec which can be attributed to the 16 bit regesters and added instructions that REAL 386 code can use. In the magazines "UNIX World", "UNIX Review", and "Personal Workstation" they rate several machines and include dhrystone figures. It is intersting to note that all of their figures are consistant. They rate most 386/25's (cached) at 12,000/sec and 030/25 at 8000 (give or take 500/sec). >Same reason its not on the NeXT -- cost. The A3000 does have a place to put a >cache board, or, if you'd rather, a 68040 board. These aren't available yet, >but I would expect to see something at least from the third parties (two >68040 boards for the A3000 are already announced but not shipping) sometime >this Spring. My machine (the 386/25) can accomodate 64K or 256K cache. The version with 256K was rated as best price/performance UNIX workstation by "Personal Workstation" for quite some time (until the 486's came along). FYI, the upgrade to 256K cache is $350. I think that C= could have made an external cache more accessable-- especally for the UNIX machine. In that market, the extra $300-400 for a decent cache would not be missed... >>The 68030's internal cache is too small to be of much use in Unix, > >Actually, it helps out quite a bit, believe it or not. The internal cache >isn't large, but it is efficient. Since the 68030 has separate internal data >and instruction paths, when both caches hit, you wind up doing fetches in >parallel where the pipeline permits. When one hits, you may wind up hiding >some or all of a fetch to the main CPU bus by the other cache/fetch unit. >This sized cache isn't going to hold entire programs, but it's not bad on >program inner loops, or function calls (if you UNIX folks still push stuff >on the stack, call a function, and then pop it off). The internal cache has trouble keeping up with multitasking operating systems such as UNIX (and to some extent AmigaDOS). I would not be suprised to see the cache effectively dumped when an intterupt is serviced. In addition, hand optimizing a loop to fit in the cache is rarely done on UNIX, where it is almost standard under AmigaDOS. >>and it's duty in AmigaDOS seems to be to point fingers at those game >>programmers who used self-modifying code. ;) > >Actually, it speeds things up considerably. Keep in mind that the caches >aren't simply just caches, but they work with the 68030's burst/prefetch >mechanism. So you load quadlongwords twice as fast with the cache being >used versus without it, even if you just manage to hit the 4 longwords in >that burst. Yes-- however, a well designed external cache can also use the many burst modes that todays DRAM support (page mode, static column, or even 64 bit wide data paths). Granted, all this costs-- but I'd pay for it. >>Would a, say 256k SRAM cache significantly improve performance? > >Sure would. External cache isn't as effective as internal cache, but it's >in general a good idea. The cost police made an option. Also, taking a >careful look at the A3000 motherboard, if you find a place for it, I'll keep >it in mind for the next generation :-). FYI, there are 486 motherboards that can handle 512K of cache. That would be nice! :) >>#define chris@kessner.denver.co.us Chris_Hanson|Lord_Xenon|Kelson_Haldane >-- >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 K -- David Kessner - david@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);
ford@amix.commodore.com (Mike "Ford" Ditto) (03/16/91)
xenon@tcr.UUCP (Chris Hanson) writes: > 1) Why Black & White XWindows? Because we thought some people might find it useful. It was fairly easy to port the MIT monochome driver, and allowed us to get X running fairly quickly for our internal development. So, we have included it on our last several releases, figuring that someone could make use of it while the TIGA and multi-bitplane drivers were being developed (essentially from scratch; MIT and AT&T don't provide those). Now that the TIGA driver is working quite nicely, and X11R4 is ported, the X folks don't have much left to do besides the multi-bitplane driver. Well, I guess there's always optimization. -=] Ford [=- "The number of Unix installations (In Real Life: Mike Ditto) has grown to 10, with more expected." ford@amix.commodore.com - The Unix Programmer's Manual, uunet!cbmvax!ditto 2nd Edition, June, 1972. ford@kenobi.commodore.com
dltaylor@cns.SanDiego.NCR.COM (Dan Taylor) (03/16/91)
>In the magazines "UNIX World", "UNIX Review", and "Personal Workstation" they >rate several machines and include dhrystone figures. It is intersting to note >that all of their figures are consistant. They rate most 386/25's (cached) at >12,000/sec and 030/25 at 8000 (give or take 500/sec). Additional info on caching: Motorola VME system, 25MHz '030, 256K Cache, 12,000 Dhrystones, (VME141, V.3). I ran it; caches REALLY make a difference on a multitasking machine. Why else have the mini- and main-frame makers been doing it? To waste money? BTW, when do we get some real SYSTEM throughput numbers (SPECmarks), instead of just compiler/program-size dependent things like Dhrystones? Dan Taylor
jesup@cbmvax.commodore.com (Randell Jesup) (03/16/91)
In article <19887@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: > >> 7) I have also run a rough benchmarking program (that supposably computed >>drystones per second) on the 3000UX/25, an 030 NeXT, and a DTK 80386/25 >>running ESIX SysV R3.2.2. The NeXT averaged about 9000, the 386 about 12000, >>and the 3000 got about 3200. For comparison, the 3200 reading was from code >>compiled with the AT&T cc compiler. Compiling the same source with the GNU >>gcc compiler netted us a figure of over 6500. The AT&T cc in SysVr4 has no optimization stage, I believe. GCC is far preferable currently. Also, things like inlining string routines can make a major difference in dhrystone (1000's), registerized parameters, 16 bit ints, etc. >>The 68030's internal cache is too small to be of much use in Unix, > >Actually, it helps out quite a bit, believe it or not. The internal cache >isn't large, but it is efficient. Since the 68030 has separate internal data >and instruction paths, when both caches hit, you wind up doing fetches in >parallel where the pipeline permits. >This sized cache isn't going to hold entire programs, but it's not bad on >program inner loops, or function calls (if you UNIX folks still push stuff >on the stack, call a function, and then pop it off). Turning off the caches on my 3000 causes a particular make (entirely from ram:, compiler resident, etc) to go from 170 seconds to 250. It helps. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (03/16/91)
In article <1991Mar15.063527.595@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >I know that this is an Amiga group, but perhapse some of my 386 UNIX >experiance is worthwhile. The 386/25 has a 64K external cache-- which is >larger than the dhrystone program. This test was ran under UNIX and MS-DOS. >Under MS-DOS, it got 8000 dhrystones/sec which can be attributed to the 16 >bit regesters and added instructions that REAL 386 code can use. Dhrystone is very susceptible to 64K+ caches, since it ALL gets sucked into the cache. Also, note that Dhrystone 1.1 is quite susceptible to compilers "over"-optimizing it. You should use dhyrstone 2.x to get reasonable measurements (1.1 numbers can show a massive skew on some compilers/ machines, I thikn up to 50% faster than the "should"). See comp.benchmarks for more info (and source code for 2.x). >My machine (the 386/25) can accomodate 64K or 256K cache. The version with >256K was rated as best price/performance UNIX workstation by "Personal >Workstation" for quite some time (until the 486's came along). FYI, the >upgrade to 256K cache is $350. Once people start making them, cache should be easy to add (that 200 pin connector is made for it (and other things)). Cache boards aren't really complex, though testing them can be (and you have be very timing-concious). >I think that C= could have made an external cache more accessable-- especally >for the UNIX machine. In that market, the extra $300-400 for a decent cache >would not be missed... There's also the board space issue. Look at an A3000 motherboard sometime: it's quite packed. It owuld have been very tough to fit it. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
david@kessner.denver.co.us (David Kessner) (03/17/91)
In article <19928@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Mar15.063527.595@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: > Dhrystone is very susceptible to 64K+ caches, since it ALL gets sucked >into the cache. Also, note that Dhrystone 1.1 is quite susceptible to >compilers "over"-optimizing it. You should use dhyrstone 2.x to get >reasonable measurements (1.1 numbers can show a massive skew on some compilers/ >machines, I thikn up to 50% faster than the "should"). See comp.benchmarks >for more info (and source code for 2.x). I honestly dont know what Dhrystone version I was using, but would assume 1.1. When trying several variations of compilers and optimizing, the LOWEST value I got was about 10,000-- using the AT&T compiler and no optimization. I'll try to find dhrystone 2.x... Also, under a multitasking OS a large external cache is more useful when the system is loaded-- and it keeps SEVERAL "loops" from several programs in the cache. Here is where the small internal cache of the 030 fails... > Once people start making them, cache should be easy to add (that 200 >pin connector is made for it (and other things)). Cache boards aren't really >complex, though testing them can be (and you have be very timing-concious). > > There's also the board space issue. Look at an A3000 motherboard >sometime: it's quite packed. It owuld have been very tough to fit it. I think C= could have spent more time developing UNIX on the Amiga-- perhapse designing a separate hardware platform for it. The UNIX software is obviously "not quite ready"-- with the B&W X11R3 and all. It is too bad, since this is C= first shot at UNIX and everyones first impression is very important-- and I want C= to succeed... While it is true that there isnt much space on the A3000 motherboard-- it also shows that the A3000(UX) was not designed as a UNIX machine from the start. But it is adiquate. I think that C='s next attempt at a UNIX machine ought be a 68040 in a tower case-- with a stronger power supply, more drive bays, more slots, several serial/parallel ports on the motherboard (with a REAL UART), and an external cache (even with the 040's internal cache). That would be a nice UNIX machine! >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup -- David Kessner - david@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);
david@twg.com (David S. Herron) (03/17/91)
In article <392@tcr.UUCP> xenon@tcr.UUCP (Chris Hanson) writes: > 3) Much the same question applies to X11R4. I have heard it stated >unofficially on the net that the version 2.0 of Amiga Unix will include X11 >Release 4. Is this true? (Is anyone listening to me? ;) From "Amiga Unix Tech Notes" volume 1 number 1: X11R4, with your choice of window managers. (Gee.. does that mean they know I want to use `gwm' & will bundle that with v2.0 Just For Meee!?!?) > 4) Carrying on the Unix version 2.0 thread, it has also been said that >version 2.0 will allow the user to rebuild the kernal, like any other self- >respecting Unix package. Is this reasonably close to being fact? From the Tech notes: An expanded and user selectable installation and configuration program. Might or might not be what you suggest. > 6) We're running Unix on a 4 fast/2 chip A3000/25 with 100 meg drive and >320 meg external. I know Unix is _expected_ to be a real memory-pig, but by >the time the system comes up and allows me to login to the ksh, I am already >paging about 2 megabytes. Is this normal? The generic advice is: Unix + X11 requres 8 Megs. 2 megs of swapping sounds reasonable then. Especially since people (Dave Haynie I think) have said that on an Amiga Unix > 1 meg of chip memory is a waste since it only uses the 1, and that it is unavailable to the OS. > 7) I have also run a rough benchmarking program (that supposably computed >drystones per second) on the 3000UX/25, an 030 NeXT, and a DTK 80386/25 >running ESIX SysV R3.2.2. The NeXT averaged about 9000, the 386 about 12000, >and the 3000 got about 3200. For comparison, the 3200 reading was from code >compiled with the AT&T cc compiler. Compiling the same source with the GNU >gcc compiler netted us a figure of over 6500. Much better ... gcc is a better compiler than AT&T's. gcc is PARTICULARLY good with 68000 family processors. From the Tech notes: new GCC-compiled kernel and utilities. Since gcc give twice the performance of AT&T's compiler (as you mentioned above) this should make the machine MUCH faster. To boot, X11R4 is much much much faster than R3. Remember, compiler differences are very important when comparing Dhrystones. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
jesup@cbmvax.commodore.com (Randell Jesup) (03/18/91)
In article <1991Mar16.214414.1802@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >> There's also the board space issue. Look at an A3000 motherboard >>sometime: it's quite packed. It owuld have been very tough to fit it. > >I think C= could have spent more time developing UNIX on the Amiga-- perhapse >designing a separate hardware platform for it. The UNIX software is obviously >"not quite ready"-- with the B&W X11R3 and all. It is too bad, since this is >C= first shot at UNIX and everyones first impression is very important-- and I >want C= to succeed... I'd say commodore spent quite a while on the unix - it's been in the works (at one level or another) ever since I joined the company 3 years ago. Also, look at the comparisons with other SysVr4 machines that someone posted here, as to what state they're in, etc. >While it is true that there isnt much space on the A3000 motherboard-- it also >shows that the A3000(UX) was not designed as a UNIX machine from the start. >But it is adiquate. I think that C='s next attempt at a UNIX machine ought >be a 68040 in a tower case-- with a stronger power supply, more drive bays, >more slots, several serial/parallel ports on the motherboard (with a REAL >UART), and an external cache (even with the 040's internal cache). That >would be a nice UNIX machine! The point is that since they can use a machine (mostly) designed for the AmigaDos market, they (as a group) don't have to justify or pay for the amount of engineering to build a new machine (which is considerably non-trivial). As for what will be released in the future: no comment (yet). ;-) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
david@kessner.denver.co.us (David Kessner) (03/18/91)
In article <19933@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > I'd say commodore spent quite a while on the unix - it's been in the >works (at one level or another) ever since I joined the company 3 years ago. >Also, look at the comparisons with other SysVr4 machines that someone posted >here, as to what state they're in, etc. Well. Perhapse. But people like SCO can get away with that. Other than that there are several 386 UNIX makers that have a SysVr4 working quite nicely but have not released it yet-- because they have some "piddly" little things that need to be cleaned up... All in all, the Amiga UNIX gives me the impresseion that it is not complete and has been rushed. It is just barely out the door and there are already talk of the next verson! Damn, sounds like the Macs System 7. > The point is that since they can use a machine (mostly) designed for >the AmigaDos market, they (as a group) don't have to justify or pay for >the amount of engineering to build a new machine (which is considerably >non-trivial). Yes. I view Amiga UNIX as an _OPTIONAL_ OS for a good system. But if I want a UNIX system then I will buy a _UNIX_ system-- like one of the new SPARC clones that I saw at COMDEX. To improve the A3000UX to the point that it can compete with the SPARCs would put it into the price range of them... I guess that I am just annoyed at all the folks that are thinking that the A3000UX is the ultimate workstation-- I gotta unsubscribe to comp.sys.amiga.advocacy! > As for what will be released in the future: no comment (yet). ;-) It's what we expect! >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup -- David Kessner - david@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);
skrenta@amix.commodore.com (Rich Skrenta) (03/19/91)
david@kessner.denver.co.us (David Kessner) writes: > Well. Perhapse. But people like SCO can get away with that. Other than that > there are several 386 UNIX makers that have a SysVr4 working quite nicely > but have not released it yet-- because they have some "piddly" little things > that need to be cleaned up... > All in all, the Amiga UNIX gives me the impresseion that it is not complete > and has been rushed. It is just barely out the door and there are already > talk of the next verson! Of course there's a next version! I've never heard a developer say there's not going to be another release--unless the product is dead. Our release 2.0 is going to have some major improvements, including a kernel and libraries built with a different compiler. And of course we keep polishing it as we go. Would you rather we held up the release for "piddly" cosmetic problems? > To improve the A3000UX to the point that it > can compete with the SPARCs would put it into the price range of them... It's not a fair comparison to sit a 3000UX down next to a $15,000 workstation. Amiga Unix is stable and a great value for the money. Rich -- skrenta@amix.commodore.com
jesup@cbmvax.commodore.com (Randell Jesup) (03/19/91)
In article <1991Mar18.051407.4163@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <19933@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >> I'd say commodore spent quite a while on the unix - it's been in the >>works (at one level or another) ever since I joined the company 3 years ago. >>Also, look at the comparisons with other SysVr4 machines that someone posted >>here, as to what state they're in, etc. > >Well. Perhapse. But people like SCO can get away with that. Other than that >there are several 386 UNIX makers that have a SysVr4 working quite nicely >but have not released it yet-- because they have some "piddly" little things >that need to be cleaned up... Well, the Unix group was at that point 8 or 9 months ago, when a load of machines were sent to VPI for all their CS students. I think they were the first of the r4 porters to get networking up, for example (they had it at some show around a year ago in NYC, if I remember right). >All in all, the Amiga UNIX gives me the impresseion that it is not complete >and has been rushed. It is just barely out the door and there are already >talk of the next verson! Damn, sounds like the Macs System 7. There's nothing really wrong with keeping improving the product. Certain things were left off for the initial release (like an easy way to relink with different device drivers, etc), but that doesn't mean that it will be a long while before 2.0 is available. X11R4 is running here, and has been for a while. Also, if you get a chance take a look at the documentation, man pages, etc. A lot of work was put in by the Unix group to make the package a really well-done setup, with good documentation (the best I've seen for a unix box, though I admit I haven't seen all that many (Sun, Ultrix, 3B1)). >I guess that I am just annoyed at all the folks that are thinking that the >A3000UX is the ultimate workstation-- I gotta unsubscribe to >comp.sys.amiga.advocacy! I wouldn't call it the ultimate workstation. I would call it a good workstation at a really good price, with a very complete OS. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
david@kessner.denver.co.us (David Kessner) (03/19/91)
In article <1426@amix.commodore.com> skrenta@amix.commodore.com (Rich Skrenta) writes: >Of course there's a next version! I've never heard a developer say there's >not going to be another release--unless the product is dead. Our release 2.0 >is going to have some major improvements, including a kernel and libraries >built with a different compiler. And of course we keep polishing it as we go. >Would you rather we held up the release for "piddly" cosmetic problems? I would not buy a system that is "stagnent"-- that is not adjusting to the times. But I wonder about a system that is as new a Amiga UNIX and yet has so much talk about the next version... It is just an indicator of the first versions status. >> To improve the A3000UX to the point that it >> can compete with the SPARCs would put it into the price range of them... > >It's not a fair comparison to sit a 3000UX down next to a $15,000 workstation. >Amiga Unix is stable and a great value for the money. Comparing the current lineup of UNIX workstations ($8000 Sparcs, 030 NeXTs, 386/486 UNIX Boxes) to the A3000UX is a little lop-sided. All of these have higher CPU performance (ok, the 386 is arguably faster), and better X-Windows with higher resolutions. Adding a faster CPU, the U of L 34010 board, an external cache, and a comparable monitor (16" 1280x1024 multisync monitor) would put it into the same price range as the new Sparc clones that DTK, CompuAdd (yuck), and several others are comming out with this year. These SPARC machines include 8Meg RAM, 1280x1024x256 X11r4, 200+ hard drive, eithernet, 16" monitors, and run SUN OS 4.x (soon to be SysVr4). The cost of these are to be in the neighborhood of $8000, $5000 for monochrome... For the basic A3000UX(D), it is a good system (assuming version 2) for the cost-- and is quite useable. But I suppose my point is that for a few thousand dollars more there are other UNIX machines that are much more capable. If the extra cost is within budget then the A3000UX cannot compete. I am at the point where I'd find the extra money to buy a SPARC/NEXT/486 rather than getting a A3000UX-- but I think I'm just used to the higher performance of these machines (ie, I'm spoiled)... >Rich >skrenta@amix.commodore.com -- David Kessner - david@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);
daveh@cbmvax.commodore.com (Dave Haynie) (03/20/91)
In article <1991Mar16.214414.1802@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >I think C= could have spent more time developing UNIX on the Amiga-- perhapse >designing a separate hardware platform for it. The UNIX software is obviously >"not quite ready"-- with the B&W X11R3 and all. Well, hey, they've been working on it since '87 or so. I don't think they possibly could have spent more time on it. Better a B&W X that's solid than a flakey color X or some-such. This is, at the very least, a solid, complete UNIX. Bells and whistles later.... >While it is true that there isnt much space on the A3000 motherboard-- it also >shows that the A3000(UX) was not designed as a UNIX machine from the start. The A3000 was designed from the ground up as a high performance multitasking personal computer. That is something different than a high performance single tasking computer, like your typical '386/'486 system, or most Macs. It is also something different than a medium performance workstation, such as a HP 9000/3xx, or the new HP '040 machines. The closest analog, from a system design point of view, would be the 68030 based NeXT system, except for the fact that the A3000 allows cache memory to be added as an option (a large cache would put it in the HP 9000 performance league). What constitutes a UNIX machine, on the other hand, is a matter of opinion. Some people used to think a PDP-11 or a VAX 11/750 made a perfectly acceptable UNIX machine. Other people won't be happy without an HP Snake on their desktop or a Cray or something in the back room. Since some kind of UNIX-like OS runs on just about anything, you can't define "UNIX machine" as a single class of computer. The A3000 will run UNIX as efficiently as the best personal computers around, overall (UNIX performance is subject to more than the Dhrystone benchmark as a measure), and can certainly be upgraded to workstation performance levels. >I think that C='s next attempt at a UNIX machine ought be a 68040 A 68040 system would certainly be a good thing... >in a tower case-- with a stronger power supply, more drive bays, more slots, >several serial/parallel ports on the motherboard You want something else, fine. But at present, desktop UNIX machines are way popular. If you want a floor standing tower machine, no problem. But you have to realize that the desktop version is far more popular, costs less, and generally gets priority over the tower version. I don't see any problem with both, as long as Commodore want 'em both. >(with a REAL UART), So what would ya be wantin'? You got a real UART. You're sayin' you want a faster UART, that's a valid request. "Real UART" ain't. >and an external cache (even with the 040's internal cache). That would be a >nice UNIX machine! Nice AmigaOS machine too. I figure Commodore has to get into the $4000 computer business before it can tackel the $6000 computer business, and so on up the scale. Success in one is a good indication that they'll let us do the next level. There's no lack of desire here, belive me. >David Kessner - david@kessner.denver.co.us | do { -- 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.denver.co.us (David Kessner) (03/20/91)
In article <19986@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >Well, hey, they've been working on it since '87 or so. I don't think they >possibly could have spent more time on it. Better a B&W X that's solid than a >flakey color X or some-such. This is, at the very least, a solid, complete >UNIX. Bells and whistles later.... How much would have color X delayed the A3000UX? Five or six months would be my guess-- but I've never ported UNIX or X... >The A3000 was designed from the ground up as a high performance multitasking >personal computer. That is something different than a high performance single >tasking computer, like your typical '386/'486 system, or most Macs. Please elaborate. My 386 UNIX box does quite well being a "High performance single tasking computer". Actually the typical 386/486 has two things agenst it: Graphic speed (which can always be solved by a $600 34010 board), and Microsoft. I/O speeds are not really a problem since only very high-end disk drives get more than 2meg/sec of the 8mhz I/O bus, and since I run mine at 12mhz there is no shortage of bandwidth. We can solve the Microsoft problem by not using MS-DOS or OS/2... >What constitutes a UNIX machine, on the other hand, is a matter of opinion. Yes. IMHO, if the Amiga had been designed as a UNIX machine from the start they would have taken out much of the custom chips since sound and much of the blitter is of no use under UNIX. They would have added a SIMPLE video display, perhapse text only, or a one-bitplane X choosing to rely on the 34010 board for most of the X Windows. A larger case would be used, with more drive slots for more hard drives and internal tape backups. A larger power supply would also be added for the extra drives. A cache would be a nice addition, as would more serial ports-- but these are optional. I realize, of course, that is C= ever did this _FOR_IT'S_FIRST_UNIX_BOX_ that it'd go over about as well as the PS/1 did. C= needs a larger UNIX market share before it can afford to put up the capital to do this type of thing. >The A3000 will run UNIX as efficiently as the best personal >computers around, overall (UNIX performance is subject to more than the >Dhrystone benchmark as a measure), and can certainly be upgraded to workstation >performance levels. The Dhrystone benchmark works bes when comparing CPU's of the same family with the same compiler. Ie, comparing the Apollo, HP, NCR, and NeXT 030 based machines with eachother. It tends to show up little differences among them. 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-- and shows that it should be looked into further (ie, it isnt conclusive). If soneone wants to mail me the Specmarks benchmark I'd be happy to run it... The A3000UX can be upgraded to "workstation performance levels", but then puts it into "workstation prices". Once your in that range, then the question is, "Why dont we just buy a workstation?" >You want something else, fine. But at present, desktop UNIX machines are >way popular. If you want a floor standing tower machine, no problem. But you >have to realize that the desktop version is far more popular, costs less, and >generally gets priority over the tower version. I don't see any problem with >both, as long as Commodore want 'em both. Keeping the general UNIX theology: Make It An Option! All that you'd really need is a redesigned case and maybe a power supply. I'm sure some third party has thought of this... >>(with a REAL UART), > >So what would ya be wantin'? You got a real UART. You're sayin' you want a >faster UART, that's a valid request. "Real UART" ain't. Sorry. I was in that C-64 mode for a sec there. You remember, where the CPU was practically resonsible for shifting in the bits in from the user port. I should say a faster UART, perhapse with a FIFO. Like the 16550... >Nice AmigaOS machine too. I figure Commodore has to get into the $4000 >computer business before it can tackel the $6000 computer business, and so on >up the scale. Success in one is a good indication that they'll let us do the >next level. There's no lack of desire here, belive me. I dont want to sound negative here-- although I KNOW that it's how I am comming across as. While I like the idea of C= being on the cutting edge, and UNIX is a natural progression, I think that the inital release of Amiga UNIX lacked the sparkle to launch it into the market. Having used UNIX machines for some time (anyone want to buy a used PDP-11?) I have cone to expect more-- and the A3000UX did not fill my expectations. Not that it is a bad machine, but it is not what I would expect from a UNIX machine. I see Amiga UNIX as an option for 030 based Amigas (be it the 3000, or another with an 030 accelerator). I dont see it making a dent in the current workstation market. With that in mind, C= might have been smarter to not bother with the UX, but sell UNIX for the Amiga on tape or CD-ROM. But then again-- I'm no marketing GURU... >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy -- David Kessner - david@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);
eachus@aries.mitre.org (Robert I. Eachus) (03/20/91)
I almost directed followups to comp.sys.amiga.advocacy, but what the hey... In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: In article <19986@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >Well, hey, they've been working on it since '87 or so. I don't think they >possibly could have spent more time on it. Better a B&W X that's solid than a >flakey color X or some-such. This is, at the very least, a solid, complete >UNIX. Bells and whistles later.... How much would have color X delayed the A3000UX? Five or six months would be my guess-- but I've never ported UNIX or X... But why delay at all? I'm sure that if the choice was X11R3 on Sys5R4 or X11R4 on Sys5R3 in the same time frame, Commodore made the right choice. (The choice may have been exactly that, if I was doing the X ports, I would insist on doing one update at a time, and I don't think it was possible to do both in the time available.) It shold be easy to upgrade X, and there is every indication that will happen soon, but moving from Sys5R3 to Sys5R4 would be no picnic for the users. That seems to be why Commodore decided not to release Sys5R3, but to keep it in beta. >The A3000 was designed from the ground up as a high performance >multitasking personal computer. That is something different than >a high performance single tasking computer, like your typical >'386/'486 system, or most Macs. Please elaborate. My 386 UNIX box does quite well being a "High performance single tasking computer". Actually the typical 386/486 has two things agenst it: Graphic speed (which can always be solved by a $600 34010 board), and Microsoft. I/O speeds are not really a problem since only very high-end disk drives get more than 2meg/sec of the 8mhz I/O bus, and since I run mine at 12mhz there is no shortage of bandwidth. We can solve the Microsoft problem by not using MS-DOS or OS/2... The "typical" '386 or '486 system with an AT bus is not designed for multiple bus masters, and in particular will allow disk DMA to choke off the main CPU. The Microchannel bus and some of the other "top of the line" busses fix this problem. Note that the problem is more one of jerkiness than of throughput...it is very disconcerting if keystrokes are not echoed promptly because of background paging, and in fact this is more noticable with faster disks and controllers. >What constitutes a UNIX machine, on the other hand, is a matter of opinion. Yes. IMHO, if the Amiga had been designed as a UNIX machine from the start they would have taken out much of the custom chips since sound and much of the blitter is of no use under UNIX. They would have added a SIMPLE video display, perhapse text only, or a one-bitplane X choosing to rely on the 34010 board for most of the X Windows. A larger case would be used, with more drive slots for more hard drives and internal tape backups. A larger power supply would also be added for the extra drives. A cache would be a nice addition, as would more serial ports-- but these are optional. Let's see the custom chips are probably the cheapest way for Commodore to do video because they already manuafacture them, since the chips are designed and in production, there is no cost savings to be had by designing them out. If you want a simple B/W video display, get yourself a B/W monitor. If you want a bigger B/W display, the 3000 (and the custom chips in it) already support one, and in fact that is what Dave Haynie prefers to use. I don't, but then again you get your chioce. If you would prefer a tower case, well Commodore announced the 3000T in Germany last week. Commodore currently sells additional serial ports as an option for the 3000, I suspect however that you will have to wait for the next Unix release to use them. There are no cache boards for the 3000 yet, but the box was designed to support them. However, I suspect that the first cache boards for the 3000 will have a 68040 too. I realize, of course, that is C= ever did this _FOR_IT'S_FIRST_ _UNIX_BOX_ that it'd go over about as well as the PS/1 did. C= needs a larger UNIX market share before it can afford to put up the capital to do this type of thing. Why bother? Commodore can stay in the "personal" market (including workstations) which seems quite large enough. Leave the mainframe market (which is rapidly shrinking) to the established players. I think Commodore's strategy is a good one, the workstation vendors are climbing upscale, and there is still a large market where 3-8 MIPS is more than sufficent (look at all the Sun-3's still being used). This leaves an opening where Commodore can quickly become a large player. The provision for upgrading with a 68040 (or 68050 down the road), should avoid worries about future upgrades. >The A3000 will run UNIX as efficiently as the best personal >computers around, overall (UNIX performance is subject to more >than the Dhrystone benchmark as a measure), and can certainly be >upgraded to workstation performance levels. The Dhrystone benchmark works bes when comparing CPU's of the same family with the same compiler. Ie, comparing the Apollo, HP, NCR, and NeXT 030 based machines with eachother. It tends to show up little differences among them. 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-- and shows that it should be looked into further (ie, it isnt conclusive). If soneone wants to mail me the Specmarks benchmark I'd be happy to run it... I think that there are two factors here. First, Dhrystone 1.1 should not be used to benchmark anything. There are too many compilers which literally cheat (calculate incorrect values) on this particular program. Dhrystone 2.1 is much better at measuring something other than the cleverness of the compiler writers. Second, the compilers, and the operating system itself, in the first release of Amiga Unix worried more (much more) about correctness and reliability than speed. Again this is the "right" decision for the intended market. The speed demons will all buy SPARCstation 2's while dreaming about Silicon Graphics. A customer who would be happy with a 3 MIPS machine, won't mind that with the first OS release, the compiler only gives him 4 MIPS of performance when number crunching from a 7 MIPS box. However, the excellent throughput of the stuff outside the main CPU means that people like me, who hate to wait for a screen update, will be very happy. (In fact, a one point I would rlogin to a Sun workstation in my office from my Amiga, because I could pop up a new shell window faster on the Amiga. I still do that, but I don't have the Sun in my office any more.) The A3000UX can be upgraded to "workstation performance levels", but then puts it into "workstation prices". Once your in that range, then the question is, "Why dont we just buy a workstation?" Huh? You lost me somewhere. A suitably equipped Amiga meets any definition of a workstation I've ever heard, including some that rule out 90% of the workstations in use today. (Actually that is not quite true, someone once tried to tell me that a workstation today HAD to have a RISC processor...He was upset that we had ust run some benchmarks which showed the Amiga was faster than a MIPS workstation. (Flame retardant: This was an R2000 based machine, and the numbers were fairly close, with the MIPS faster on floating point intensive stuff, and the Amiga faster on scalars, and much faster on memory intensive programs.) >You want something else, fine. But at present, desktop UNIX >machines are way popular. If you want a floor standing tower >machine, no problem. But you have to realize that the desktop >version is far more popular, costs less, and generally gets >priority over the tower version. I don't see any problem with >both, as long as Commodore want 'em both. Keeping the general UNIX theology: Make It An Option! All that you'd really need is a redesigned case and maybe a power supply. I'm sure some third party has thought of this... And as I pointed out above, so has Commodore. I don't think Dave can "announce" things which Commodore has announce only in Europe, but I don't work for Commodore. Note that the 3000T has the same motherboard but more slots. >>(with a REAL UART), > >So what would ya be wantin'? You got a real UART. You're sayin' >you want a faster UART, that's a valid request. "Real UART" >ain't. Sorry. I was in that C-64 mode for a sec there. You remember, where the CPU was practically resonsible for shifting in the bits in from the user port. I should say a faster UART, perhapse with a FIFO. Like the 16550... Again, huh? If you want Ethernet speeds, use Ethernet. There were problems with the AmigaDOS serial port driver which made it tough to go 19200 baud, but I believe both that that is fixed, and that the multiport serial cards can run 38400 baud with no problem. Again, that's AmigaDOS, but I have never seen the UART's as the limiting factor. >Nice AmigaOS machine too. I figure Commodore has to get into the >$4000 computer business before it can tackel the $6000 computer >business, and so on up the scale. Success in one is a good >indication that they'll let us do the next level. There's no lack >of desire here, belive me. I dont want to sound negative here-- although I KNOW that it's how I am comming across as. While I like the idea of C= being on the cutting edge, and UNIX is a natural progression, I think that the inital release of Amiga UNIX lacked the sparkle to launch it into the market. Having used UNIX machines for some time (anyone want to buy a used PDP-11?) I have cone to expect more-- and the A3000UX did not fill my expectations. Not that it is a bad machine, but it is not what I would expect from a UNIX machine. I see Amiga UNIX as an option for 030 based Amigas (be it the 3000, or another with an 030 accelerator). I dont see it making a dent in the current workstation market. With that in mind, C= might have been smarter to not bother with the UX, but sell UNIX for the Amiga on tape or CD-ROM. But then again-- I'm no marketing GURU... See above. I don't think Commodore is trying to crack the "current" 10 MPIS+ workstation market with the 3000UX, but to play in the field that the current big boys are leaving behind. In this market I suspect that price (as long as it is less than $10000) is less of a factor than convenience, support, and the ability to "plug and play." If you look at what Commodore is doing, they seem to think so too. I don't have any experience with '386 Unix boxes, but I have to believe that Commodore is doing a lot better job of minimizing the work required of a systems administrator responsible for a lot of machines than Sun has ever done. Knocking a couple thousand a year per seat off of support costs would far outweigh any slight difference in price. The reality of the NeXT cubes at MITRE has been that they are a "hackers only" box. Even where the user is capable of doing his own support, we have a lot of them gathering dust, because the user doesn't have the time to devote to the care and feeding of his workstation Even if NeXT does a wonderful job with the new machines, they may never dispell this impression. And it is really a software issue anyway. >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy David Kessner - david@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); -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
peter@ficc.ferranti.com (Peter da Silva) (03/21/91)
In article <1991Mar19.003209.6819@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: > I would not buy a system that is "stagnent"-- that is not adjusting to the > times. But I wonder about a system that is as new a Amiga UNIX and yet has > so much talk about the next version... It is just an indicator of the first > versions status. The NeXT was released with rev 0.9 of the O/S. At some point you have to shoot the developers and ship something. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
eachus@aries.mitre.org (Robert I. Eachus) (03/21/91)
In article <1991Mar20.211652.3247@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes:
My point is: Would it have been better for C= to wait an extra 6
months to get a Color X going-- BEFORE releasing Amiga UNIX? I'm
no marketing GURU, but my gut feeling is that C= will get bad
market perception for releasing UNIX and then UPGRADING it so
soon...
Hmmm. I've never experienced that "jerkiness" that you speak of-- but most
of my work is CPU bound rather than disk bound... All in all, I like the
386 system (again, minus the VGA X11r3's speed). We have put three people
on it without any problems-- with a mix of X-windows, GCC, RN, and VI. I
would have tried more, but I ran out of serial ports...
I thought your system didn't have an XT bus? The problems "only"
occur when DMA can choke the CPU by taking over the bus.
Unfortunately, most PC compatable '386 machines currently have XT
busses.
I mentioned using a 1-bit-plane X display strictly for COST-- I
dont like them myself. But you missed (glossed over) my comment
saying, "instead relying on a 34010 board for X-Windows" (somewhat
paraphrased).
No, I was speaking about other alternatives. As far as I know, the
ULowell board will only be required for color X.
It's not that this is a "mainframe"-- but rather a machine trimmed
for UNIX work. There is nothing to say that it cannot be put in a
slim-line case (with a tower case option, of course :).
My point was that there is no point to spending the money to take
these features out, the savings in hardware cost wouldn't come close
to covering the development overhead and the added manufacturing costs
of an additional product line.
Hmmm. I remember all those Sun-3 users that were complaining about
the speed of their computers... Of course, all of them also got
spoiled by the SPARCStations sitting next to them...
I have been complaining about the user percieved speed of the
Sun-3's since back when SPARC was a glimmer in Sun's eye. The problem
has been that a display interface that was not a bottleneck with a
68010 based Sun-2 is a real pain in the neck on a Sun-3. My 2500/30
happens to be faster than most of the Sun-3 around here, but not the
factor of ten that the relative display speeds will convince you is
the case.
This "lower" market is something to pay atention to, true. Here,
of course, C='s competition is the NeXT (yuck), and several SPARC
clones-- all of which are in the A3000UX's $7000 (non-educational)
price tag. If someone is looking for a UNIX workstation then
they'd buy a SPARC (given it's similar price), but if they also
want the Amiga's abilities (Running with AmigaDOS) then they'd buy
a A3000.
And I think Commodore is figuring that people who have to support a
lot of machines will much prefer the Amiga, due to a much better
support level, and less set-up time, etc. I expect to get in some
SPARCstations in the next month, I'll time how long it takes to set
them up, last time it was 6 hours/machine, (Ouch!) but I hope to
remember some of the gotchas for next time. The 3000U is shiped plug
and play.
Argh. Fine! So mail me the Dhrystone 2.1 code. Or better yet,
the Specmark program. I'll test the machines and post the results.
I dont think that it'd change things much, but I'll entertain the
thought...
Also, you missed the point of my message completely! I'm saying
that the Dhrystone numbers differed by SO MUCH that FURTHER
INVESTIGATION IS REQUIRED! And dont give me any "cleverness of the
compiler writers" stuff since GCC and the AT&T compiler were used
on both machines with similar results.
But not the same code generators! The cheats for Dhrystone (as opposed to
optimizations) were all in the code generators.
If you read the above paragraph closely you will read: You are
correct about the pitfalls of the benchmarks I ran, but in the
context of the "grand scheme of things" they probably indicate
something important. Further testing is required before conclusive
results are produced.
If you read between the lines of what I wrote, you might see that I
expect that the Dhrystone speeds for the next relase of Amiga Unix to
be somewhat higher (but not higher than the comparable AmigaDOS
numbers). The biggest improvement in the next release may be that the
system is compiled with a better compiler.
The term "workstation performance levels" came from something that
Dave H said. I took it to mean "performance similar to the current
workstation lineup of SPARCS/RISC/etc machines"-- about 3-5 times
the performance of the current A3000UX.
I think that you and I are looking at two different types of
performance. Robert Silverman here at MITRE uses distributed networks
of workstations to factor large prime numbers. He cares about raw
(integer) speed, but most of the people at MITRE do mostly text
processing, and for this the Amiga (with 8 Meg at least for emacs on X
:-), is faster than most of the SPARCstations. Flipping instantly
between screens instead of rooting through windows is easy to get
addicted to (and actually makes smaller displays preferable).
Therefore, when I said what is quoted above, It was refering to the
cost of adding a 040 board, a 34010 board, a 16-17" monitor, and a
few other bells and whistles.
All these are available or are in the pipe, and modulo what I said
above about large displays, I expect that such a machine will list for
about what a color SPARCstation does. (But no one will pay list for
either.)
I seriously doubt the A3000UX's ability to do 38400 baud, and 19200
is questionable (this is under UNIX, ya know)...
I'll let Dave Haynie or one of the third party board manufacturers
reply to this, but I will note that the message that arrived
immediately after this one was from someone running his (Amiga Unix)
serial port at 38400 and wanting to turn on CSD.
For the A3000UX to go anywhere they need to be cheaper than the
current lineup of $7000-9000 UNIX Workstations. Cheaper than $5000
is a good place to be (please, none of that educational pricing
thing). Unless they can do that, then they are in the price range
of the "10MIPS+ workstation market". (note: this is based on the
$7000 tag on the A3000UXD)
As I said, the market they are playing in seems to have a "real"
prices in the $5 to $10K range. By going third party for disks and
memory, I can set up a color SPARCstation for about $15K. (Flame
retardant: The system hardware is less than half of that, additional
network plant adds about $1 to 2K and the rest is software.) If I can
get a comparable Amiga with Unix for less than $10K, I'm happy. For
$15K I expect that I will be able to get the system you describe
above. (Again, less than $10K for hardware...)
The plug and play ability is not so much of a factor in UNIX.
Since C= needs to write UNIX drivers for everything. What doesnt
need a driver is probably also useable on other workstations also.
In addition, there is a lot of third party workstation "devices"
available-- they are just not advertised a lot in the mainstream
computer magazines.
Again, you lost me. I wasn't talking about such things as third
party devices (like Exabyte tapes :-), I was talking about the time to
get the basic system configured, up, and running. I am always
appalled by the fact that configuring NFS under AmigaDOS (with a
Ameristar card and software) took less time than hooking up the cable,
while similar installation or changes on a Sun are a nightmare. And
Sun invented NFS!
The bottom line is: Why should I buy a A3000UX?
Cost? Not unless the price goes below $5000 (i'm
talking UXD here).
I don't think I'll ever see a Unix workstation with a real cost
below $5000, but the Amiga does come close.
Proformance? Not when compard to machines in it's price range
(ie. $5000-$9000).
I don't know beans about Proformance :-), but the performance seems
to compare nicely to machines in its price range. ('386 boxes with a
decent bus and disk controller.) I don't count the low end
SPARCstations, because the initial cost is sky high. They only
compete when you already have an active Sun network. you might be
able to put together a ten box system for under $10K per seat, but
quantity one will kill you.
Availability? The dealers here in town cant even get a demo!
I can't help you with dealers in Denver, but there are several good
dealers in NH and Massachusetts.
Spiffy Features? It runs AmigaDOS :)
And you can take it out of the box, plug it in, turn it on, and get
a login prompt. And then log in again and again without X-windows.
:-)
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...david@kessner.denver.co.us (David Kessner) (03/21/91)
In article <EACHUS.91Mar20111051@aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes: >I almost directed followups to comp.sys.amiga.advocacy, but what >the hey... Yea. Your not kiddin'... > But why delay at all? I'm sure that if the choice was X11R3 on >Sys5R4 or X11R4 on Sys5R3 in the same time frame, Commodore made the >right choice. (The choice may have been exactly that, if I was doing >the X ports, I would insist on doing one update at a time, and I don't >think it was possible to do both in the time available.) It shold be >easy to upgrade X, and there is every indication that will happen >soon, but moving from Sys5R3 to Sys5R4 would be no picnic for the >users. That seems to be why Commodore decided not to release Sys5R3, >but to keep it in beta. My point is: Would it have been better for C= to wait an extra 6 months to get a Color X going-- BEFORE releasing Amiga UNIX? I'm no marketing GURU, but my gut feeling is that C= will get bad market perception for releasing UNIX and then UPGRADING it so soon... > Please elaborate. My 386 UNIX box does quite well being a "High > performance single tasking computer". Actually the typical 386/486 > has two things agenst it: Graphic speed (which can always be solved > by a $600 34010 board), and Microsoft. I/O speeds are not really a > problem since only very high-end disk drives get more than 2meg/sec > of the 8mhz I/O bus, and since I run mine at 12mhz there is no > shortage of bandwidth. We can solve the Microsoft problem by not > using MS-DOS or OS/2... > > The "typical" '386 or '486 system with an AT bus is not designed >for multiple bus masters, and in particular will allow disk DMA to >choke off the main CPU. The Microchannel bus and some of the other >"top of the line" busses fix this problem. Note that the problem is >more one of jerkiness than of throughput...it is very disconcerting if >keystrokes are not echoed promptly because of background paging, and >in fact this is more noticable with faster disks and controllers. Hmmm. I've never experienced that "jerkiness" that you speak of-- but most of my work is CPU bound rather than disk bound... All in all, I like the 386 system (again, minus the VGA X11r3's speed). We have put three people on it without any problems-- with a mix of X-windows, GCC, RN, and VI. I would have tried more, but I ran out of serial ports... > Let's see the custom chips are probably the cheapest way for >Commodore to do video because they already manuafacture them, since >the chips are designed and in production, there is no cost savings to >be had by designing them out. If you want a simple B/W video display, >get yourself a B/W monitor. If you want a bigger B/W display, the 3000 >(and the custom chips in it) already support one, and in fact that is >what Dave Haynie prefers to use. I don't, but then again you get your >chioce. If you would prefer a tower case, well Commodore announced >the 3000T in Germany last week. Hmmmm. If you took out the custom chips, leaving only DMA to "fast ram", added a TEXT ONLY display (which is VERY cheap), then the savings would be more noticeable in cost, and board space (since there isnt a "chip ram" bus). The actual $$$ cost benifit of this is subject to C's price on sand, the phase of the moon, etc... I mentioned using a 1-bit-plane X display strictly for COST-- I dont like them myself. But you missed (glossed over) my comment saying, "instead relying on a 34010 board for X-Windows" (somewhat paraphrased). > I realize, of course, that is C= ever did this _FOR_IT'S_FIRST_ > _UNIX_BOX_ that it'd go over about as well as the PS/1 did. C= > needs a larger UNIX market share before it can afford to put up the > capital to do this type of thing. > > Why bother? Commodore can stay in the "personal" market (including >workstations) which seems quite large enough. Leave the mainframe >market (which is rapidly shrinking) to the established players. I >think Commodore's strategy is a good one, the workstation vendors are >climbing upscale, and there is still a large market where 3-8 MIPS is >more than sufficent (look at all the Sun-3's still being used). This >leaves an opening where Commodore can quickly become a large player. >The provision for upgrading with a 68040 (or 68050 down the road), >should avoid worries about future upgrades. It's not that this is a "mainframe"-- but rather a machine trimmed for UNIX work. There is nothing to say that it cannot be put in a slim-line case (with a tower case option, of course :). Hmmm. I remember all those Sun-3 users that were complaining about the speed of their computers... Of course, all of them also got spoiled by the SPARCStations sitting next to them... This "lower" market is something to pay atention to, true. Here, of course, C='s competition is the NeXT (yuck), and several SPARC clones-- all of which are in the A3000UX's $7000 (non-educational) price tag. If someone is looking for a UNIX workstation then they'd buy a SPARC (given it's similar price), but if they also want the Amiga's abilities (Running with AmigaDOS) then they'd buy a A3000. > I think that there are two factors here. First, Dhrystone 1.1 >should not be used to benchmark anything. There are too many >compilers which literally cheat (calculate incorrect values) on this >particular program. Dhrystone 2.1 is much better at measuring >something other than the cleverness of the compiler writers. Second, >the compilers, and the operating system itself, in the first release >of Amiga Unix worried more (much more) about correctness and reliability >than speed. Argh. Fine! So mail me the Dhrystone 2.1 code. Or better yet, the Specmark program. I'll test the machines and post the results. I dont think that it'd change things much, but I'll entertain the thought... Also, you missed the point of my message completely! I'm saying that the Dhrystone numbers differed by SO MUCH that FURTHER INVESTIGATION IS REQUIRED! And dont give me any "cleverness of the compiler writers" stuff since GCC and the AT&T compiler were used on both machines with similar results. If you read the above paragraph closely you will read: You are correct about the pitfalls of the benchmarks I ran, but in the context of the "grand scheme of things" they probably indicate something important. Further testing is required before conclusive results are produced. > Again this is the "right" decision for the intended market. The >speed demons will all buy SPARCstation 2's while dreaming about >Silicon Graphics. A customer who would be happy with a 3 MIPS >machine, won't mind that with the first OS release, the compiler only >gives him 4 MIPS of performance when number crunching from a 7 MIPS >box. However, the excellent throughput of the stuff outside the main >CPU means that people like me, who hate to wait for a screen update, >will be very happy. Again. If you want a UNIX machine-- buy a _UNIX_ machine. If you want a UNIX machine that also runs AmigaDOS (or vis-versa) then the A3000 is it. My personal opinion is that this is the market for AmigaUNIX and that it will never penetrate the "UNIX only workstation market" unless they create more UNIX optimized machine (which would be nice, but I dont think they will). > The A3000UX can be upgraded to "workstation performance levels", > but then puts it into "workstation prices". Once your in that > range, then the question is, "Why dont we just buy a workstation?" > > Huh? You lost me somewhere. A suitably equipped Amiga meets any >definition of a workstation I've ever heard, including some that rule >out 90% of the workstations in use today. The term "workstation performance levels" came from something that Dave H said. I took it to mean "performance similar to the current workstation lineup of SPARCS/RISC/etc machines"-- about 3-5 times the performance of the current A3000UX. Therefore, when I said what is quoted above, It was refering to the cost of adding a 040 board, a 34010 board, a 16-17" monitor, and a few other bells and whistles. Otherwise, in the practical sense of the work, the A3000UX IS a workstation. > And as I pointed out above, so has Commodore. I don't think Dave >can "announce" things which Commodore has announce only in Europe, but >I don't work for Commodore. Note that the 3000T has the same >motherboard but more slots. Not bad, I have to see this thing... I am waiting for the day that Apple comes out with a Tower Mac. Now I'm not a Mac fan (they are the ones that ported UNIX SystemVr2!) but they know how to make a sharp looking case. Too bad they are not black... > Again, huh? If you want Ethernet speeds, use Ethernet. There were >problems with the AmigaDOS serial port driver which made it tough to >go 19200 baud, but I believe both that that is fixed, and that the >multiport serial cards can run 38400 baud with no problem. Again, >that's AmigaDOS, but I have never seen the UART's as the limiting >factor. I seriously doubt the A3000UX's ability to do 38400 baud, and 19200 is questionable (this is under UNIX, ya know). The limiting factor here is the ability of the OS to grab a character from the UART before the next character comes in. If the OS cannot get it in time (ie, intterupt latency) then that character is lost. A buffered UART (like the 16550) has a 16 byte buffer than can capture several characters during the intterupt latency period. UNIX can be quite bad about servicing intterupts of this nature. In addition, a buffered UART can decrease the overhead in servicing a serial port-- since it can use one intterupt for every 10 or so ccharacters rather than an intterupt for each character. On a 386 system running ONE port at a sustained 38400 baud (output only, on a normal UART) the system load would be near 30%. When a buffered UART is used, the load drops to below 10%. Keep in mind that 38400 baud is a realistic rate on a UNIX system-- where high speed modems are the norm. Todays 9600 baud modems have V.42bis that can do 4:1 compression on text-- requiring that you lock the modem's baud rate at 38400 baud... Then you throw V.42bis with V.32bis and you have a bigger nightmare... > See above. I don't think Commodore is trying to crack the >"current" 10 MPIS+ workstation market with the 3000UX, but to play in >the field that the current big boys are leaving behind. In this >market I suspect that price (as long as it is less than $10000) is >less of a factor than convenience, support, and the ability to "plug >and play." If you look at what Commodore is doing, they seem to think >so too. For the A3000UX to go anywhere they need to be cheaper than the current lineup of $7000-9000 UNIX Workstations. Cheaper than $5000 is a good place to be (please, none of that educational pricing thing). Unless they can do that, then they are in the price range of the "10MIPS+ workstation market". (note: this is based on the $7000 tag on the A3000UXD) The plug and play ability is not so much of a factor in UNIX. Since C= needs to write UNIX drivers for everything. What doesnt need a driver is probably also useable on other workstations also. In addition, there is a lot of third party workstation "devices" available-- they are just not advertised a lot in the mainstream computer magazines. The bottom line is: Why should I buy a A3000UX? Cost? Not unless the price goes below $5000 (i'm talking UXD here). Proformance? Not when compard to machines in it's price range (ie. $5000-$9000). Availability? The dealers here in town cant even get a demo! Spiffy Features? It runs AmigaDOS :) C= Loyalty? Perhapse for some folks. AT&T Conformance? Like we are not used to 20 types of UNIX's? > Robert I. Eachus - David K -- David Kessner - david@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);
peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/21/91)
In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <19986@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > > A larger case would be used, with more drive slots >for more hard drives and internal tape backups. A larger power supply >would also be added for the extra drives. A cache would be a nice addition, as >would more serial ports-- but these are optional. You'll get the bigger case, the A3000T (for tower) was just shown publicly on CeBIT. And our A2232 card with seven serial ports works nicely in most of our Amiga UNIX boxes. >All that you'd really need is a redesigned case and maybe a power supply. See above. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
david@kessner.denver.co.us (David Kessner) (03/21/91)
In article <EACHUS.91Mar20181104@aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes: > I thought your system didn't have an XT bus? The problems "only" >occur when DMA can choke the CPU by taking over the bus. >Unfortunately, most PC compatable '386 machines currently have XT >busses. I have the standard "PC AT" bus which is called the ISA bus, for Industry Standaed Arch. Then there is MCA or Microchanel-- where IBM clames that you cannot do 'multitasking' without it (and only thet have it!). There is also EISA, for Extended ISA-- wich is like MCA, but isnt owned by IBM and is compatable with normal ISA cards. I have the ISA bus, but have never experienced the jerkyness that you describe... > No, I was speaking about other alternatives. As far as I know, the >ULowell board will only be required for color X. Yes, but Amiga UNIX V2 will support color on the standard hardware! :) > My point was that there is no point to spending the money to take >these features out, the savings in hardware cost wouldn't come close >to covering the development overhead and the added manufacturing costs >of an additional product line. Yes, as long as Amiga UNIX has a small/piddly market share in the 'typical UNIX shop'. Once/if it gets a larger market share, it might be cost effective to make such a machine. That's one of the reasons that I said C= would be foolish to actually build a machine like that. In addition, it would look just like any other 030/040 based UNIX box out there (with the exception of the NeXT, which is stange in its own way). > I have been complaining about the user percieved speed of the >Sun-3's since back when SPARC was a glimmer in Sun's eye. The problem >has been that a display interface that was not a bottleneck with a >68010 based Sun-2 is a real pain in the neck on a Sun-3. My 2500/30 >happens to be faster than most of the Sun-3 around here, but not the >factor of ten that the relative display speeds will convince you is >the case. Yes. Percieved speed is another issue. But more on that in a sec... > And I think Commodore is figuring that people who have to support a >lot of machines will much prefer the Amiga, due to a much better >support level, and less set-up time, etc. I expect to get in some >SPARCstations in the next month, I'll time how long it takes to set >them up, last time it was 6 hours/machine, (Ouch!) but I hope to >remember some of the gotchas for next time. The 3000U is shiped plug >and play. C='s UNIX market is on a 'lower level' than your typical SUN user. That is to say that they have less knoledge of UNIX than most SUN users/sys-admins. Given that, C= needs to do a little more "hand holding" to keep their customers happy. Some companies are realizing this, like Apple shipping Mac UNIX already installed on a hard drive. There are other companies that are doing this as well-- or will be soon. I installed UNIX on my 386 from 40+ 1.2 meg floppies. You though 6 hours was long! I dont think that set-up time is as important to those UNIX guru's. But it is obviously important to someone... > But not the same code generators! The cheats for Dhrystone (as opposed to >optimizations) were all in the code generators. These results are consistent with EVERY dhrystone test I have seen, including those in UNIX Review, where they list 1.1 results as well as 2.x. > If you read between the lines of what I wrote, you might see that I >expect that the Dhrystone speeds for the next relase of Amiga Unix to >be somewhat higher (but not higher than the comparable AmigaDOS >numbers). The biggest improvement in the next release may be that the >system is compiled with a better compiler. The same Dhrystone program when compiled with Lattice C under AmigaDOS (with the 030 optimization turned on) got 7600 dhry/sec. I would not expect any Dhrystone program (1.1 or 2.x) to get more than 8500 using any compiler. I would not expect the Dhrystone results to get better with Amiga UNIX v2, but OS overhead will improve signifigantly. I've hinted enough: DOES ANYONE HAVE DHRYSTONE 2.X OR SPECMARK CODE???? (and now back to the normally schedualed program...) > I think that you and I are looking at two different types of >performance. Robert Silverman here at MITRE uses distributed networks >of workstations to factor large prime numbers. He cares about raw >(integer) speed, but most of the people at MITRE do mostly text >processing, and for this the Amiga (with 8 Meg at least for emacs on X >:-), is faster than most of the SPARCstations. Flipping instantly >between screens instead of rooting through windows is easy to get >addicted to (and actually makes smaller displays preferable). For me, the raw CPU power is important since I do a lot of CPU bound tasks. Disk I/O is also important, but to a lesser extent. I also have 12 meg of RAM, so swapping is not a problem. All of the terminals (one local, another via 9600 V.42bis modem) are connected via 38400 baud connections and are not a bottle-neck themselves. All in all, I am only I/O bound when I get a large Netnews batch-- but that has to do with the 28ms drives I have... FYI, I have found a BIG case for text only displays. On the 386, I can 'cat' a 80K text file in about 6 seconds. It even supports ten virtual terminals. It makes X windows look snail'ish... > Therefore, when I said what is quoted above, It was refering to the > cost of adding a 040 board, a 34010 board, a 16-17" monitor, and a > few other bells and whistles. > > All these are available or are in the pipe, and modulo what I said >above about large displays, I expect that such a machine will list for >about what a color SPARCstation does. (But no one will pay list for >either.) I expect all of these to be available for the A3000-- but I too expect it to cost as much as a "mainstream" workstation which is the original point. If you spend this much for a fast Amiga, why not just get a SPARC Clone or comparable machine? In terms of proce/performance there is little reason- there is only "AmigaDOS" and "set-up time" that may/may-not be a factor (depending on what brand you get). Another FYI: Do you know why God made <insert your favorite type of person here>? Someone has to pay list price? > As I said, the market they are playing in seems to have a "real" >prices in the $5 to $10K range. By going third party for disks and >memory, I can set up a color SPARCstation for about $15K. (Flame >retardant: The system hardware is less than half of that, additional >network plant adds about $1 to 2K and the rest is software.) If I can >get a comparable Amiga with Unix for less than $10K, I'm happy. For >$15K I expect that I will be able to get the system you describe >above. (Again, less than $10K for hardware...) Judging buy what I saw at the FALL COMDEX, there are a dozen or so new SPARC Clones that should be in the $8000-9000 range for 16" color, 200 meg HD, 8meg RAM, and eithernet. The ones I saw ran Sun OS 4.? but I would not be suprised to see System Vr4 in the bunch. Some of these systems are available now (like the Mars/Tatung system), while others should be available this summer (like Goldstar, DTK, and Compuadd). > Again, you lost me. I wasn't talking about such things as third >party devices (like Exabyte tapes :-), I was talking about the time to >get the basic system configured, up, and running. I am always >appalled by the fact that configuring NFS under AmigaDOS (with a >Ameristar card and software) took less time than hooking up the cable, >while similar installation or changes on a Sun are a nightmare. And >Sun invented NFS! Ahhh... You mean something more like "Working right out of the box." That is another story. I agree that something needs to be done here (I still dont have my eithernet working correctly). I have not played too much with AmigaUNIX on this part-- but would assume that once you get off the "standard configuration" that things are pritty much the same as typical UNIX systems. Am I wrong to assume this? > Cost? Not unless the price goes below $5000 (i'm > talking UXD here). > > I don't think I'll ever see a Unix workstation with a real cost >below $5000, but the Amiga does come close. I can configure a 386 UNIX system in the $4000-4500 range. Add $1000 for a 486/25 system. Here is what I base this on: $1500 Bare bone 386/25 (one floppy, keyboard, case, 200 watt PS) 400 8 Meg RAM 400 150 meg HD 100 HD/Floppy controller 600 800x600x256 SVGA card and monitor 1500 UNIX System (unlimited users, development, X/Motif, manuals) 400 Math Co-processor (not needed, but a good idea) 100 Mouse (a damn good mouse, since most cost $65). --------------------------- 3500 Total Add to this $1000 worth of add-ons. Perhapse a 34010 board for $600. Eithernet for $125. Tape backup for $400. A Telbit T2500 at $950. Etc.. The usuall price difference between a 386/25 and a 486/25 is about $1000, but this changes daily... As you see, the 386 system is some real competition. At the $3500 base price, there are a lot of changes that you can add-- 34010 boards and caching disk controllers are near the top of the list. I wont say that a 386 system is better-- just damn attractive. > Robert I. Eachus - David K -- David Kessner - david@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);
jac@gandalf.llnl.gov (James A. Crotinger) (03/22/91)
eachus@aries.mitre.org (Robert I. Eachus) writes: > (integer) speed, but most of the people at MITRE do mostly text > processing, and for this the Amiga (with 8 Meg at least for emacs on X > :-), is faster than most of the SPARCstations. Flipping instantly > between screens instead of rooting through windows is easy to get > addicted to (and actually makes smaller displays preferable). Huh? I haven't used an A3000UX, but my experience is that emacs seems infinitely faster on Sun 4's (sparcs) than on the Sun 3/80 I used to have (which, I believe, uses a 20 MHz '030). And this "smaller displays preferable" stuff sounds like Hamburger B syndrome. 8-). > Therefore, when I said what is quoted above, It was refering to the > cost of adding a 040 board, a 34010 board, a 16-17" monitor, and a > few other bells and whistles. > All these are available or are in the pipe, and modulo what I said > above about large displays, I expect that such a machine will list for > about what a color SPARCstation does. (But no one will pay list for > either.) But doesn't this bother you. The sparc has a lot more horsepower than an A3000UX, so the A3000UX with similar display hardware ought to be quite a bit cheaper in order to compete. (And, as I mentioned in an earlier message, Sun's discount pricing seems much more aggressive than CBM's, with 40% discounts for large institutions.) > As I said, the market they are playing in seems to have a "real" > prices in the $5 to $10K range. By going third party for disks and > memory, I can set up a color SPARCstation for about $15K. (Flame > retardant: The system hardware is less than half of that, additional > network plant adds about $1 to 2K and the rest is software.) If I can > get a comparable Amiga with Unix for less than $10K, I'm happy. For > $15K I expect that I will be able to get the system you describe > above. (Again, less than $10K for hardware...) I guess I'm missing something. Sun's IPC *lists* for $10K (our price, $6K) and is every bit as complete as the A3000UX, coming with 16" color monitor, ethernet, 200 Meg hard drive, 8 Meg ram, SunOS 4.1 and OpenWindows (which includes a lot of stuff that CBM's OPEN LOOK software doesn't have). What additional software do you have to buy for this that you wouldn't have to buy for the Amiga? (And is the software you want even available on the Amiga). If you don't want color, Sun's SLC *lists* for $5K (but you do need to get a disk and software for it if you want to run it standalone). That certainly is cheaper than the A3000UX + A2024. Furthermore, the IPC is more-or-less "plug and play". The software is preinstalled. You turn it on, answer some questions, create yourself an account, and you're ready to go. There is room for improvement, however, since Sun doesn't currently have any graphically oriented sysadmin tools for non-UNIX experts. (Does the Amiga?) > I don't think I'll ever see a Unix workstation with a real cost > below $5000, but the Amiga does come close. Why? I predict that Sun or some Sparc clone will have such a beast in 1-2 years. > I don't count the low end > SPARCstations, because the initial cost is sky high. They only > compete when you already have an active Sun network. you might be > able to put together a ten box system for under $10K per seat, but > quantity one will kill you. Why do you say this? What do you need that isn't included with Sun's IPC? -- ----------------------------------------------------------------------------- James A. Crotinger Lawrence Livermore Natl Lab // The above views jac@moonshine.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not (415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL
jac@gandalf.llnl.gov (James A. Crotinger) (03/22/91)
david@kessner.denver.co.us (David Kessner) writes:
You just don't have a fast enough machine 8-). From an xterm on my Sparc 1:
gandalf:jac(make-3.59)> ls -l ChangeLog
-rw-r--r-- 1 jac 164432 Nov 28 19:53 ChangeLog
gandalf:jac(make-3.59)> time cat ChangeLog
[164432 characters deleted 8-)]
0.030u 0.160s 0:15.88 1.1% 0+82k 0+0io 0pf+0w
^^^^^^^ wall clock time
While this is not quite as quick as your 386's console, I think it is
quite acceptable. And if I cat the same file from a disk on a remote
machine (where xterm is running on the remote machine, a 490), I get
0.010u 0.120s 0:09.32 1.3% 0+55k 0+2io 0pf+0w
So X on a Sparc can display characters quite quickly.
[And this is Sun's xnews running on a machine with 8 bit graphics
but without Sun's GX board. The figures would almost certainly be
faster running MIT's X server]
[From psterm, which does the rendering in NeWS (PostScript), the time
was 16.22 seconds to cat the local file with a locally running psterm,
and 14.87 seconds to cat the remote file with a remotely running
psterm]
[BTW, I don't think I've ever seen anything display characters as
quickly as the old AMIX windowing system. Man, it blasted them
characters up there!]
Jim
--
-----------------------------------------------------------------------------
James A. Crotinger Lawrence Livermore Natl Lab // The above views
jac@moonshine.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not
(415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNLpeter@ficc.ferranti.com (Peter da Silva) (03/22/91)
In article <1991Mar20.211652.3247@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: > Keep in mind that 38400 baud is a realistic rate on a UNIX system-- where > high speed modems are the norm. Todays 9600 baud modems have V.42bis that > can do 4:1 compression on text-- requiring that you lock the modem's baud rate > at 38400 baud... Then you throw V.42bis with V.32bis and you have a bigger > nightmare... I don't get it. Why put compression on the modem, when the UNIX box can do a better job at it (after all, it's got the whle file to examine), and put all this interrupt handling on the UNIX box when the modem is better at it? Doesn't make sense to me. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
eachus@aries.mitre.org (Robert I. Eachus) (03/22/91)
In article <IP4ABRB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
The NeXT was released with rev 0.9 of the O/S. At some point you have to
shoot the developers and ship something.
Don't know about you, but the first (and I hope only) NeXT
machines we got were running 0.8. 0.9 was a big improvement, and we
now have 2.0 installed. Acording to John Kordash in the Research
Computer Network support center here, Mach 2.0 on a 68040 (upgraded
motherboard in a cube) feels to the user somewhere between a Sun-3/60
and and original SPARCstation. To me that is really damning with
faint praise.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...bgribble@jarthur.Claremont.EDU (Bill Gribble) (03/22/91)
Just a few notes to add fuel to the fl- uh, discussion. [Please don't misinterpret this as a wholehearted endorsement of Amiga Unix: I still have doubts. But I am concerned with what appears to be misinformation or misconception.] About getting a high-resolution display, and the concern that doing so would put the 3000ux into high end pricing: if you don't really care about color (I know, that's not valid for everybody) the A2024 monitor has been available for some time with (I think) 1280x800, 4 grey scale. This is as good as your typical low end SPARC or NeXTstation. And a quick check to the price list reveals that the A2024 is the same price as the 1950, and is (if I'm not mistaken) swappable with the 1950 in any unix bundles. About the I-like-386i-unix guy's assertion that text-only virtual terminals are pretty hip: Commodore agrees wholeheartedly. That's why you can get up to [I think] 20 of them on the current release of Amiga Unix without ever even thinking about X. About the 3000ux as a viable competitor in the lowend workstation market: [this is entirely conjecture, so don't believe a word of it] I think the 3000ux's main competitor right now is the NeXTstation, and, frankly, the ux is losing right now, The lack of available 040 cards is what does it. But a 3000ux + A2024 + 040 = NeXTstation + 100meg of disk + expansion potential. The expansion capability is an unquantifiable benefit, but if I can get a 040-based 3000ux running sys5 I would definitely overlook a fair-sized price differential in the NeXT's favor, especially since this computer will be mine (and the only one I have) rather than the school's or the company's and I don't want to stick myself with a NeXTstation with absolutely NO way to make it any better. Honestly, at this point, I really don't know what's going to happen with Amiga Unix. But I give them a lot more credit than most people on this group seem to. ************************************************************************* ** Bill Gribble Harvey Mudd College, Claremont, CA ** ** bgribble@jarthur.claremont.edu Never heard of it? You're stupid. ** *****************************************************************************
daveh@cbmvax.commodore.com (Dave Haynie) (03/22/91)
In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <19986@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>The A3000 was designed from the ground up as a high performance multitasking >>personal computer. That is something different than a high performance single >>tasking computer, like your typical '386/'486 system, or most Macs. >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: >I/O speeds are not really a problem since only very high-end disk drives get >more than 2meg/sec of the 8mhz I/O bus, and since I run mine at 12mhz there >is no shortage of bandwidth. 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. >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. >All that you'd really need is a redesigned case and maybe a power supply. >I'm sure some third party has thought of this... 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... >Sorry. I was in that C-64 mode for a sec there. You remember, where the CPU >was practically resonsible for shifting in the bits in from the user port. 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. >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... >David Kessner - david@kessner.denver.co.us | do { -- 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
jesup@cbmvax.commodore.com (Randell Jesup) (03/22/91)
In article <1991Mar20.211652.3247@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >My point is: Would it have been better for C= to wait an extra 6 months to >get a Color X going-- BEFORE releasing Amiga UNIX? I'm no marketing GURU, but >my gut feeling is that C= will get bad market perception for releasing UNIX and >then UPGRADING it so soon... Most OS's I've known that were released for the first time (from a company/for a machine) were reved relatively soon thereafter. Witness MSDOS, AmigaDos 1.0 vs 1.1, etc, etc. >Hmmmm. If you took out the custom chips, leaving only DMA to "fast ram", >added a TEXT ONLY display (which is VERY cheap), then the savings would be more >noticeable in cost, and board space (since there isnt a "chip ram" bus). The >actual $$$ cost benifit of this is subject to C's price on sand, the phase of >the moon, etc... > >I mentioned using a 1-bit-plane X display strictly for COST-- I dont like them >myself. But you missed (glossed over) my comment saying, "instead relying on >a 34010 board for X-Windows" (somewhat paraphrased). Note 1-bitplane X doesn't mean 1-bitplane text. In any case, the cost of the Amiga custom chips is the cost of sand. They're old (3+ micron NMOS), we own our own foundry, and they're paid for. Also, there was essentially $0 cost for HW engineering (not really 0, but essentially mimimal) when compared to the amount for doing a variant motherboard (different casework/PS/etc would have really upped the engineering cost). Essentially, the Unix group is "leeching" off the AmigaDos hardware designs, getting machines for close to 0 HW engineering cost. If the Unix group does well, it may make sense for us to do a (semi) custom machine for Unix (still leveraging off our existing silicon/cases/etc). >Otherwise, in the practical sense of the work, the A3000UX IS a workstation. Note that the term "workstation" has a highly variable meaning depending on who is using it. It means something different to a cash-strapped student than to a random software engineer to a hardware engineer to a chip engineer to a scientist doing simulations. >> And as I pointed out above, so has Commodore. I don't think Dave >>can "announce" things which Commodore has announce only in Europe, but >>I don't work for Commodore. Note that the 3000T has the same >>motherboard but more slots. A slight correction: the machine shown at CEBIT has a variant of the same motherboard. It has more slots (and they're on the main motherboard), and some other small differences in the motherboard (uses ZIPs for chip ram, etc). You can see some of this in the A3000 schematics in a box labelled "if 3500" or some such. Note that I am not (and could not) announce such a machine - that's done by the sales companies of the respective countries, as is pricing and whether they carry it, warantee's, etc, etc, etc. I know it was shown in Hannover, I don't know what the German sales company said about it. As usual, this is NOT any sort of official statement by commodore, I could be having delusions, this could be a forgery, etc, etc. :-) >I seriously doubt the A3000UX's ability to do 38400 baud, and 19200 is >questionable (this is under UNIX, ya know). The limiting factor here is >the ability of the OS to grab a character from the UART before the next >character comes in. If the OS cannot get it in time (ie, intterupt latency) >then that character is lost. A buffered UART (like the 16550) has a 16 >byte buffer than can capture several characters during the intterupt latency >period. UNIX can be quite bad about servicing intterupts of this nature. There are solutions to this. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
david@kessner.denver.co.us (David Kessner) (03/22/91)
In article <11342@jarthur.Claremont.EDU> bgribble@jarthur.Claremont.EDU (Bill Gribble) writes: >About getting a high-resolution display, and the concern that doing so > would put the 3000ux into high end pricing: if you don't really care > about color (I know, that's not valid for everybody) the A2024 monitor > has been available for some time with (I think) 1280x800, 4 grey scale. > This is as good as your typical low end SPARC or NeXTstation. And a > quick check to the price list reveals that the A2024 is the same price > as the 1950, and is (if I'm not mistaken) swappable with the 1950 in > any unix bundles. I've only seen Amiga UNIX running at 640x400 (or was it 480) on a one-bitplane bitmap and on the U of L board. I was under the impression that the current version of the X software could only deal with one bit-plane image (using the standard video). Now, Assuming that this is so... I'd like to rephrase the sediments of Chris Hanson (who started this line of messages/flames, and has remained silent, heh, heh... That's chris@kessner.denver.co.us! :)... "OpenLook is ugly. But a B&W (not even gray scale) Openlook is doubly so!" (paraphrased) >About the I-like-386i-unix guy's assertion that text-only virtual terminals > are pretty hip: Commodore agrees wholeheartedly. That's why you can > get up to [I think] 20 of them on the current release of Amiga Unix without > ever even thinking about X. Hmmm. I would not think of my comments as "text-only...[is] pritty hip." But there is definately a benifit there. I personally would rather use X windows with it's cut/paste and be able to look at several windows at the same time-- but that is my own preference. Text-only displays are very efficent for many of todays applications, especally on a very text oriented system like UNIX. They take up little memory (for buffering) and have minimal overhead-- scrolling a 4K screen is easier than scrolling a 800x600 screen (512K). However, machines that have a graphic accelerator can make up the speed difference... Here is a question for those C= folk: Does the Amiga UNIX use the blitter for ANYTHING? I know that it is not used for X-- but what about scrolling the "text-only" virtual terminals? Also, can someone set me straight on exactly what video modes X will support on the 3000UX (without the U of L board). - David K -- David Kessner - david@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);
scotte@applix.com (Scott Evernden) (03/22/91)
In article <11342@jarthur.Claremont.EDU> bgribble@jarthur.Claremont.EDU (Bill Gribble) writes: < <About getting a high-resolution display, and the concern that doing so < would put the 3000ux into high end pricing: if you don't really care < about color (I know, that's not valid for everybody) the A2024 monitor < has been available for some time with (I think) 1280x800, 4 grey scale. > This is as good as your typical low end SPARC or NeXTstation. ... Ya but isn't this the display which updates only 10 or 15 times a second? -scott
david@kessner.denver.co.us (David Kessner) (03/22/91)
In article <20030@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Mar20.100122.1717@kessner.denver.co.us> david@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@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);
kris@tpki.toppoint.de (Kristian Koehntopp) (03/22/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >The NeXT was released with rev 0.9 of the O/S. At some point you have to >shoot the developers and ship something. Look at the old dos.library code and BCPL. You want this to happen again? Kristian Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 .sig (Heute ohne Sepp)
zerkle@iris.ucdavis.edu (Dan Zerkle) (03/22/91)
In article <9K5AC+2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >I don't get it. Why put compression on the modem, when the UNIX box can do >a better job at it (after all, it's got the whle file to examine), and put >all this interrupt handling on the UNIX box when the modem is better at it? >Doesn't make sense to me. Notice that when the modems are doing compression, EVERYTHING goes faster, not just file transfer. You have probably noticed that using a full screen editor is much nicer at 9600bps vs 2400bps. Also, it's nice to have it done automatically by the modem, instead of transforming your file n times, you get to do it n-2 times (one less compression, one less de-compression). It can save time in this manner. Finally, modems with compression also usually have correction built in. With your editor again, this means no annoying line noise. Also, on-the-fly error correction via the modem is a little bit more efficient than the usual programmed error correction. However, all of this is pointless if your site has no budget from the legislature this year because the last governer was a bozo and all the funds got cut and your fees are going up and there's no way in Hell the computer center can afford error correcting modems so your modem might as well be the kind that cost noticably less than the one you did buy. But then again, that's life. Dan Zerkle zerkle@iris.eecs.ucdavis.edu (916) 754-0240 Amiga... Because life is too short for boring computers.
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/23/91)
In article <9K5AC+2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991Mar20.211652.3247@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >> Keep in mind that 38400 baud is a realistic rate on a UNIX system-- where >> high speed modems are the norm. Todays 9600 baud modems have V.42bis that >> can do 4:1 compression on text-- requiring that you lock the modem's baud rate >> at 38400 baud... Then you throw V.42bis with V.32bis and you have a bigger >> nightmare... > >I don't get it. Why put compression on the modem, when the UNIX box can do >a better job at it (after all, it's got the whle file to examine), and put >all this interrupt handling on the UNIX box when the modem is better at it? >Doesn't make sense to me. >-- >Peter da Silva. `-_-' peter@ferranti.com >+1 713 274 5180. 'U` "Have you hugged your wolf today?" You are quite right, UNIX already compresses news, for example, and the big problem with UUCP right now is the fact that it handshakes each file (at a minimum), meaning that lots-o-little files (email) take a while whether you use compression or not. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
skank@iastate.edu (Skank George L) (03/23/91)
In article <1991Mar19.003209.6819@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <1426@amix.commodore.com> skrenta@amix.commodore.com (Rich Skrenta) writes: >>Of course there's a next version! I've never heard a developer say there's >>not going to be another release--unless the product is dead. Our release 2.0 >>is going to have some major improvements, including a kernel and libraries >>built with a different compiler. And of course we keep polishing it as we go. >>Would you rather we held up the release for "piddly" cosmetic problems? > >I would not buy a system that is "stagnent"-- that is not adjusting to the >times. But I wonder about a system that is as new a Amiga UNIX and yet has >so much talk about the next version... It is just an indicator of the first >versions status. This would bother me, but, for instance, Microsoft has the same problem. The first releases of many Microsoft titles were buggy and didn't perform up to developer expectations, to that end I think Commodore has far exceeded Microsoft in how well the initial release of the software works, especially considering the *huge* size of the project. Microsoft (for a while at least) started to develop a reputation for buggy initial releases, it was so bad that the president set a company goal to improve the quality of future titles' initial releases. It happens to all the big companies, so why shouldn't it happen to Commodore too? (this is just to keep things in perspective, I don't like unfinished software anymore than the next person) --George
david@kessner.denver.co.us (David Kessner) (03/23/91)
In article <1991Mar23.090026.29503@news.iastate.edu> skank@iastate.edu (Skank George L) writes: >>I would not buy a system that is "stagnent"-- that is not adjusting to the >>times. But I wonder about a system that is as new a Amiga UNIX and yet has >>so much talk about the next version... It is just an indicator of the first >>versions status. > > This would bother me, but, for instance, Microsoft has the same problem. >The first releases of many Microsoft titles were buggy and didn't perform up >to developer expectations, to that end I think Commodore has far exceeded >Microsoft in how well the initial release of the software works, especially >considering the *huge* size of the project. Microsoft (for a while at least) >started to develop a reputation for buggy initial releases, it was so bad that >the president set a company goal to improve the quality of future titles' >initial releases. It happens to all the big companies, so why shouldn't it >happen to Commodore too? (this is just to keep things in perspective, I >don't like unfinished software anymore than the next person) > > --George This implies that we like Microsoft. The same folks that brought us MS-DOS, Windows, and OS/2. The folks that made BASIC for the Amiga that would not run on 020's and 030's. The people that made TWO versions of an operating system (MS-DOS 4.0 and 4.1) that is IGNORED by 90% of the IBM clone market. Their idea of a UNIX development system is Microsoft C ("tuned for a 386"). The company that is PROUD to have Bill "the 286 makes a ideal multi-media computer" Gates. ... and now we return you to your regularly schedualed flame ... > It happenes to all the big companies, so why shouldn't it happen to C= too? EXXON (EXXOFF?) dumped oil in Alaska, should TEXACO do the same? Shipping buggy software is not the way to run a busness, and I will never buy that software. We should not put up with that type of quality-- and should NEVER think of it as the norm. Now, I do not know of any "bugs" in Amiga UNIX-- just huge omissions in the software (we are still running the Beta3j version and awaiting version 1.1). Most of these-- the lack of sar and imake to name two-- I expect to be solved with version 1.1. Others, like the lack of COLOR X11r4 will not be working untill version 2.0 (with the standard video). Availability of OSF/Motif 1.1 has not been 'announced' but it would be a big boon to those of us that relate Openlook with Multifinder. The current B&W (not even grayscale) X11r3 is not adiquate for a lot of applications. So, the real "issue" with Amiga UNIX is two fold: Why buy a A3000UXD over similarly configured competitor? The answer here is not PRICE/PERFORMANCE, since the $7000 tag puts it in the same ballpark as other FASTER machines. The answer here is in C= loyalty, the ability to run AmigaDOS, and differences in service/setup (which may be an issue, depending on who you are and who you buy from). ...and... Is Amiga UNIX satisfactory (software wise)? Depends on what you expect. My biggest complaint is color X11r4 with higher resolutions, and a DIFFERENT window manager (I'd use UWM over Openlook, but uwn is not available to my knoledge). I'd like Motif, but wont hold it agenst C=. There are big ommisions in Beta3j, that BETTER be fixed in 1.1. You cannot configure it as an NFS SERVER (hey C=, what's the scoop on this?). Otherwise it seems like a normal system-- average, but nothing that stands out. Now, some of these wont have an effect on some (I myself dont use NFS) so they may not be an issue... On a whole-- I'm glad Microsoft didnt have a hand in Amiga UNIX! :) -- David Kessner - david@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);
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/24/91)
In article <20039@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Mar20.211652.3247@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >>My point is: Would it have been better for C= to wait an extra 6 months to >>get a Color X going-- BEFORE releasing Amiga UNIX? I'm no marketing GURU, but >>my gut feeling is that C= will get bad market perception for releasing UNIX and >>I seriously doubt the A3000UX's ability to do 38400 baud, and 19200 is >>questionable (this is under UNIX, ya know). The limiting factor here is >>the ability of the OS to grab a character from the UART before the next >>character comes in. If the OS cannot get it in time (ie, intterupt latency) >>then that character is lost. A buffered UART (like the 16550) has a 16 >>byte buffer than can capture several characters during the intterupt latency >>period. UNIX can be quite bad about servicing intterupts of this nature. > > There are solutions to this. Also, don't forget that most UNIX machines have major problems with baud rates above 19200 when using a direct-interrupt scheme. Most multi-port solutions these days have co-processors, hardware SILO's, etc, etc, etc... even so it is still possible to overrun the buffer capability on most UNIX boxes, especially loaded down ones. The simple solution for the amiga is to use the A2232, 7 port serial card (assuming all the bugs get fixed). I haven't used the internal serial port for anything except Enforcer (I have a plug in the port that wires pin 2 to pin 3). While the card is unable to do 38.4, it can do 19.2, which is good enough for me. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >The compiler runs >Like a swift-flowing river >I wait in silence. (From "The Zen of Programming") ;-) -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/24/91)
In article <1991Mar21.085254.5325@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >In article <EACHUS.91Mar20181104@aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes: >> I thought your system didn't have an XT bus? The problems "only" >>occur when DMA can choke the CPU by taking over the bus. >>Unfortunately, most PC compatable '386 machines currently have XT >>busses. > >I have the standard "PC AT" bus which is called the ISA bus, for Industry >Standaed Arch. Then there is MCA or Microchanel-- where IBM clames that >you cannot do 'multitasking' without it (and only thet have it!). There is >also EISA, for Extended ISA-- wich is like MCA, but isnt owned by IBM and is >compatable with normal ISA cards. > >I have the ISA bus, but have never experienced the jerkyness that you >describe... The fact is, doing DMA on an ISA bus is *SLOWER* than doing it with a CPU. Same goes with the EISA bus. The reason is due to the way arbitration works. That plus the fact that the overall backplane speed is, well, snails pace, and you get a real mess. Even accelerated busses don't fix the problems... they're just accelerated slow busses. The only reason PC's are able to claim any performance at all is because their main memory isn't anywhere near that bus! This is a great idea, but also exasperates the speed difference between memory and IO. While you may not necessarily see any jerkiness, overall performance is easily cut in half during disk io, or worse. PC based UNIX platforms never work well for performance seekers and the faster procssors (33MHz 486) only make the differences worse --- you are going on at a fine clip but the moment you go to disk, POOF, the machine stops. The moment you start to page, the thing becomes jerky. I haven't looked at the MCA spec, but from what I've heard IBM is more mouth than brain in terms of its capabilities. >> But not the same code generators! The cheats for Dhrystone (as opposed to >>optimizations) were all in the code generators. > >These results are consistent with EVERY dhrystone test I have seen, including >those in UNIX Review, where they list 1.1 results as well as 2.x. > >The same Dhrystone program when compiled with Lattice C under AmigaDOS (with >the 030 optimization turned on) got 7600 dhry/sec. I would not expect >any Dhrystone program (1.1 or 2.x) to get more than 8500 using any compiler. > >I would not expect the Dhrystone results to get better with Amiga UNIX v2, >but OS overhead will improve signifigantly. > >I've hinted enough: DOES ANYONE HAVE DHRYSTONE 2.X OR SPECMARK CODE???? >(and now back to the normally schedualed program...) A 25MHz 68030 without a cache, as in the A3000, will get 6000-8000 Drys. With a 16K cache you can get 9000-12000. Most high-end 386 boxes have at least a 16K cache and this is why they generally get 8000-9000 drystones, it has NOTHING to do with the processor. >For me, the raw CPU power is important since I do a lot of CPU bound >tasks. Disk I/O is also important, but to a lesser extent. I also have >12 meg of RAM, so swapping is not a problem. All of the terminals (one >local, another via 9600 V.42bis modem) are connected via 38400 baud >connections and are not a bottle-neck themselves. All in all, I am only >I/O bound when I get a large Netnews batch-- but that has to do with the >28ms drives I have... > >FYI, I have found a BIG case for text only displays. On the 386, I can >'cat' a 80K text file in about 6 seconds. It even supports ten virtual >terminals. It makes X windows look snail'ish... Well, a 386 ISA/EISA isn't a bad choice if all you are looking for is raw CPU power, assuming the thing doesn't have to go to disk you are O.K. I.E. as long as you don't need to do a lot of disk IO and have enough RAM so you don't have to page, you are ok. > - David K >-- >David Kessner - david@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); -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
dillon@overload.Berkeley.CA.US (Matthew Dillon) (03/24/91)
In article <990@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >>In article <19986@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >> >You'll get the bigger case, the A3000T (for tower) was just shown publicly >on CeBIT. And our A2232 card with seven serial ports works nicely in most ^^^^^ >of our Amiga UNIX boxes. > >>All that you'd really need is a redesigned case and maybe a power supply. > >-- >Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... >Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk most ? -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
jesup@cbmvax.commodore.com (Randell Jesup) (03/24/91)
In article <990@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: >You'll get the bigger case, the A3000T (for tower) was just shown publicly >on CeBIT. And our A2232 card with seven serial ports works nicely in most >of our Amiga UNIX boxes. In fact, Unix was one of the main reasons for building the serial card. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (03/24/91)
In article <1991Mar22.053324.8867@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >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.) That's because it's via a DMA controller on the motherboard, and it (like the CPU) has to read a byte, then write a byte, over the bus. In a single-tasking machine, it doesn't help any since it costs about the same number of transfers on the bus, and even the CPU is usually faster than the IO device, and ends up waiting on the port most of the time. In a multitasking machine, the CPU often has something better to do. >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... These are probably "bus-mastering" (also called "first-party") dma controllers. >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. Note that 80x86's are do better on dhrystone than they do on larger or more general benchmarks: dhrystone is heavily string oriented, and the strings don't match real-world characteristics, but do match the string functions of '86's (or so I'm told, I'm no expert, and I don't do 80x86's). SPECmark (particularily for Unix) is a _FAR_ better benchmark. As for your request for source, ask in comp.benchmarking - it's an entire tape's worth (gcc is just one of the tests). BTW, as for the '040 vs '486 vs SPARC: all at 25Mhz, all 128K cache, the '040 gets 11.8 SPECmarks (12.9 integer, 11.0 FP); the '486 gets 8.8 SPECmarks (13.3 integer, 6.6 FP); and SPARC gets 11.8 (12.3 integer, 11.6 FP). (SPECmarks are essentially VUPS: Vax 11/780 units of performance.) (Source: Feb 20 Microprocessor review, also posted by the author in comp.arch.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
bruce@cs.su.oz (Bruce Janson) (03/24/91)
David, In article <1991Mar23.115254.13902@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >.. >Now, I do not know of any "bugs" in Amiga UNIX-- just huge omissions in the >software (we are still running the Beta3j version and awaiting version 1.1). >.. And I look forward to reading your first impressions of your non-beta distribution when it arrives. >.. You cannot >configure it as an NFS SERVER (hey C=, what's the scoop on this?). .. The following works: $ uname -a UNIX_System_V jake 4.0 Beta3j Amiga m68020 $ $ cd /etc/init.d $ ./nfs start $ cd /etc/dfs $ share -F nfs -d / / blah $ jake's root fs may then be NFS-mounted from "basser" (a MIPS RS3230). Cheers, bruce. Bruce Janson Email: bruce@cs.su.oz.au Basser Department of Computer Science Phone: +61-2-692-3272 University of Sydney, N.S.W., 2006, AUSTRALIA Fax: +61-2-692-3838
david@kessner.denver.co.us (David Kessner) (03/25/91)
In article <20073@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <1991Mar22.053324.8867@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >>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.) > > That's because it's via a DMA controller on the motherboard, and it >(like the CPU) has to read a byte, then write a byte, over the bus. In a >single-tasking machine, it doesn't help any since it costs about the same >number of transfers on the bus, and even the CPU is usually faster than the >IO device, and ends up waiting on the port most of the time. In a multitasking >machine, the CPU often has something better to do. Hmmm. I depends on how the cache is designed. I a well designed system the system should allow DMA while the CPU is accessing the cache, and perhapse allowing the CPU to pause DMA and 'burst reload' the cache. I doubt that the current lineup of ISA based 386/486's do this, however. FYI: In the current issue of PC MAg they review 486/33 ESIA machines. They range in price from $5700 with a 200 Meg HD, Mini-Tower case, 128K cache, up to 96Meg on the MB, also includes SVGA of sorts, but I dont know the RAM/Video configuration for the price mentioned... > These are probably "bus-mastering" (also called "first-party") dma >controllers. I would not say that... I would call it "pathetically simple DMA". > Note that 80x86's are do better on dhrystone than they do on larger >or more general benchmarks: dhrystone is heavily string oriented, and the >strings don't match real-world characteristics, but do match the string >functions of '86's (or so I'm told, I'm no expert, and I don't do 80x86's). >SPECmark (particularily for Unix) is a _FAR_ better benchmark. As for your >request for source, ask in comp.benchmarking - it's an entire tape's worth >(gcc is just one of the tests). BTW, as for the '040 vs '486 vs SPARC: >all at 25Mhz, all 128K cache, the '040 gets 11.8 SPECmarks (12.9 integer, >11.0 FP); the '486 gets 8.8 SPECmarks (13.3 integer, 6.6 FP); and SPARC gets >11.8 (12.3 integer, 11.6 FP). (SPECmarks are essentially VUPS: Vax 11/780 >units of performance.) (Source: Feb 20 Microprocessor review, also posted >by the author in comp.arch.) I have found a source of other benchmarks, like whetstone, linpack, etc. I'm still looking for the SPECmark. I'll check comp.benchmarking. The only CONCLUSIVE evidence that the dhrystone has told us is that the 386 can compute dhrystones faster than the 030 at the same clock speed. However, this may indicate that there are some applications that the 386 will run signifigantly faster. I'll post results from other benchmarks as become available. Re: 486vs040... Initial figures for the 040 are scarse and contain a lot of marketing hype. The 486, however, has a bit more information. It's integer UNIT is a tad more than twice as fast as the 386, and floating point is three times as gast as the 387-- which brings it up to about 1.5 MFLOPS. All reports that I have seen suggest that the 040 is roughly equal to the the 486 in integer, and a lot faster in floating point. Your figures agree with this. AND IT"S ABOUT TIME. (assuming that the 386 is signifigantly faster than the 030) It is sad that a less-than-optimum design [the 386] could be faster than a clener-better-designed cpu [the 680x0]. I wondered why the 030 was slower, and am encouraged by the inital performace figures of the 040. The 386 is a decent CPU, as is the 486-- but GOD knows that IBM wans os/2 extentions in the next generation 80x86's so its future is unknown (unless you want os/2)... I'll stop ranting now... >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup -- David Kessner - david@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);
skrenta@amix.commodore.com (Rich Skrenta) (03/25/91)
david@kessner.denver.co.us (David Kessner) writes: > There are big ommisions in Beta3j, that BETTER be fixed in 1.1. You cannot > configure it as an NFS SERVER (hey C=, what's the scoop on this?). NFS works fine in Beta3j. Rich -- skrenta@amix.commodore.com
peterk@cbmger.UUCP (Peter Kittel GERMANY) (03/25/91)
In article <dillon.5449@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: >In article <990@cbmger.UUCP> peterk@cbmger.UUCP (Peter Kittel GERMANY) writes: > >>You'll get the bigger case, the A3000T (for tower) was just shown publicly >>on CeBIT. And our A2232 card with seven serial ports works nicely in most > ^^^^^ >>of our Amiga UNIX boxes. > > most ? Sorry, that must be again my bad English: I was talking about *real life*, those boxes we are running cbmnet on. And as I don't know all of those installations from own sight, I can only guess that they also ("most" of them) use an A2232 in them as we do here. That was NO speculation about the A2232 perhaps not working in some special Amiga UNIX setup. There shouldn't be any problems on any Amiga UNIX machine. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
kent@swrinde.nde.swri.edu (Kent D. Polk) (03/25/91)
In article <20072@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > In fact, Unix was one of the main reasons for building the serial >card. How does this fit in with the 2 user license? Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
dlb5404@tamuts.tamu.edu (Daryl Biberdorf) (03/26/91)
In article <jac.669575661@sundance> jac@gandalf.llnl.gov (James A. Crotinger) writes: > I guess I'm missing something. Sun's IPC *lists* for $10K (our >price, $6K) and is every bit as complete as the A3000UX, coming with >16" color monitor, ethernet, 200 Meg hard drive, 8 Meg ram, SunOS 4.1 >and OpenWindows (which includes a lot of stuff that CBM's OPEN LOOK >software doesn't have). What additional software do you have to buy >for this that you wouldn't have to buy for the Amiga? (And is the >software you want even available on the Amiga). Assuming the 3000UX ships with an ANSI C compiler, that's one thing you wouldn't have to buy! I find it totally ludicrous that an established, respected workstation vendor like Sun still doesn't give me a full ANSI compiler. Someone correct me if I'm wrong on this, but I still can't find a way to get a statement like "char filename[]="data.dat"" to compile without an illegal aggregate initialization error on the new Sun 4/4xx we have here. It works fine under the xlc compiler under IBM's AIX, however. Kinda odd that you have to use gcc if you want an ANSI compiler on the Sun.... --Daryl Biberdorf, dlb5404@{tamuts,rigel}.tamu.edu Texas A&M University
raz@picowatt.Eng.Sun.COM (Stephen Berry) (03/26/91)
In article <jac.669575661@sundance> jac@gandalf.llnl.gov (James A. Crotinger) writes: >eachus@aries.mitre.org (Robert I. Eachus) writes: >> I don't count the low end >> SPARCstations, because the initial cost is sky high. They only >> compete when you already have an active Sun network. you might be >> able to put together a ten box system for under $10K per seat, but >> quantity one will kill you. > Why do you say this? What do you need that isn't included with Sun's IPC? I swear, no money changed hands here... ;-) Seriously, you can get a color IPC for $9995 as Mr. C describes. You could also get a 7K monochrome system, which from what I have been seeing quoted in this news group is the same price as the 3000UX. I know which one I would choose if I needed an inexpensive UNIX box... but I may be biased. >James A. Crotinger Lawrence Livermore Natl Lab // The above views Thanks for the plug! -- ------ Stephen Berry IPC Project Engineer - Sun Microsystems raz@Eng.sun.com
kholland@hydra.unm.edu (Kiernan Holland) (03/26/91)
Does anyone know how much UNIX for the 3000 will cost on student deal? I'm fixing to get an 16/50 Amiga 3000. After that I'll be working on getting a 68040 board which is planned to be out soon.
peter@ficc.ferranti.com (Peter da Silva) (03/27/91)
In article <2988@tpki.toppoint.de> kris@tpki.toppoint.de (Kristian Koehntopp) writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > >The NeXT was released with rev 0.9 of the O/S. At some point you have to > >shoot the developers and ship something. > Look at the old dos.library code and BCPL. You want this to happen again? Hey, you have any idea how many victims were persuaded to buy Atari STs instead of Amigas because of how long it took them to start shipping boxes? If they hadn't shipped *something* we'd be running TOS now. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
eachus@aries.mitre.org (Robert I. Eachus) (03/28/91)
I said: > I don't count the low end SPARCstations, because the initial cost > is sky high. They only compete when you already have an active > Sun network. you might be able to put together a ten box system > for under $10K per seat, but quantity one will kill you. And lots of people tried to explain how they could get this system or that one for a "reasonable" price. First of all, this is not intended as a flame of Sun in any way. We have LOTS of Sun workstations here. HOWEVER, when we go to put a machine in a locked room disconnected from the corporate network (something we have to do from time to time), Sun's often become uncompetitive with other workstations which were designed to operate standalone. Now, YOU may be willing to operate in such an environment without a fast backup capability, but if we do that, we incur either lots of wrath if there is no recent backup, or the cost of someone sitting around while the machine is backed up. What we like to do is to be able to set the system up so that it can be backed up without operator intervention. Again, not a problem with Suns, but the configurations that we end up with cost between $10 and $15K (including basic software and first year maintenance) with a reasonable amount of disk. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
jac@gandalf.llnl.gov (James A. Crotinger) (03/28/91)
dlb5404@tamuts.tamu.edu (Daryl Biberdorf) writes: > Assuming the 3000UX ships with an ANSI C compiler, that's one thing > you wouldn't have to buy! > I find it totally ludicrous that an established, respected workstation > vendor like Sun still doesn't give me a full ANSI compiler. I certainly can't defend Sun's lack of an ANSI compiler. However it should be mentioned that said compiler is supposed to ship very soon. It will be a layered product, though. What compilers come with the A3000UX? I was under the impression that they were AT&T's pcc [non-ANSI] and gcc---the same things you can currently get on the sun [and for the same price--"free"]. Jim -- ----------------------------------------------------------------------------- James A. Crotinger Lawrence Livermore Natl Lab // The above views jac@moonshine.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not (415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL
kris@tpki.toppoint.de (Kristian Koehntopp) (03/28/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >Hey, you have any idea how many victims were persuaded to buy Atari STs >instead of Amigas because of how long it took them to start shipping >boxes? If they hadn't shipped *something* we'd be running TOS now. Well, at least _I_ have sold my A2000-A because I was fed up with - no ressource tracking - BPTR to [AC]PTR conversion - continuing crashes after pointer-int and pointer-pointer mismatches (Well, an Amiga is not exactly the friendliest environment for learning C!) - and the 2 minute boot time from disk/hdd, because the A2090 was not able to boot from hdd. - the hardware upgrade policy of cbm (A2000-B and C release, not way to upgrade, at least for me and my ser.no below 2700 A2000) Most of the above faults are due to the poor design of the dos.library and could have been easily avoided. I bought an 386 with XENIX instead. I know, most of this has changed today and perhaps I am going to buy an A3000 with UNIX (compares to an 386/25 with EISA, but is 8000 DM cheaper), but I will never ever touch a machine without ressource tracking and memory protection! Kristian Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 "Im uebrigen ist 'Z-NETZ-Sysops quaelen' auf Dauer weder lustig noch befriedigend." - sysop@infinet.zer.sub.org
david@twg.com (David S. Herron) (03/30/91)
In article <10422@exodus.Eng.Sun.COM> raz@picowatt.Eng.Sun.COM (Stephen Berry) writes: >Seriously, you can get a color IPC for $9995 as Mr. C describes. The new Sony laptop is also in that price range. It's MIPS R3000 based, comes with 8 megs of memory & 200 meg disk, and a ~1100x1000 LCD screen. -- $9900 list price. Oh, and it's expandable to 36 megs of memory and 600 megs of disk, all internal. Runs SysVr4 with X11R4 and Motif. -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
jseymour@medar.com (James Seymour) (03/30/91)
In article <EACHUS.91Mar20111051@aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes (in part): > > ... Actually the typical 386/486 > has two things agenst it: Graphic speed (which can always be solved > by a $600 34010 board), and Microsoft. ... > ... We can solve the Microsoft problem by not > using MS-DOS or OS/2... > Bzzzzzt. Wrong. Microsoft owns a fairly sizeable chunk of SCO unless I'm sorely mistaken (has happened before tho). Indeed, the SCO development system is basically a port of the Microsoft C compiler package (and it shows it). Now, as to benchmarks programs... > ... First, Dhrystone 1.1 >should not be used to benchmark anything. ... > > ... Dhrystone 2.1 is much better ... Huh. May be, but is it any more worthwhile for gleaning anything of any *real* usefulness? I'm quickly coming to the opinion that it belongs in the same category as your statement re: Dhrystone 1.1. I'll explain why. >In article <something_or_another> david@kessner.denver.co.us (David D. Kessner) writes (in part): >>Argh. Fine! So mail me the Dhrystone 2.1 code. Or better yet, the Specmark >>program. I'll test the machines and post the results. I dont think that it'd >>change things much, but I'll entertain the thought... >> >>Also, you missed the point of my message completely! I'm saying that the >>Dhrystone numbers differed by SO MUCH that FURTHER INVESTIGATION IS REQUIRED! >>And dont give me any "cleverness of the compiler writers" stuff since GCC and >>the AT&T compiler were used on both machines with similar results. >>In article <20073@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes (in part): >>> >>> Note that 80x86's are do better on dhrystone... [etc...] This *ought* to have pretty much said it all, but apparently not, so... [flame on - donning fire-retardant suit] David, you reply to Randall's statement with several statements that, in light of previous articles and Randall's statement, I'm surprised at. Among them: "The only CONCLUSIVE evidence that the dhrystone has told us is that the 386 can compute dhrystones faster than the 030 at the same clock speed." That was bad enough, but then you had to go and say: " ... (assuming that the 386 is significantly faster than the 030) It is sad that a less-than- optimum design [the 386] could be faster than a clener-better-designed cpu [the 680x0]. I wondered why the 030 was slower, ..." [Deep, disgusted sigh] There is ample evidence that these "hobbyist" benchmark programs are, at best, lots of fun to play with, but of questionable significance in the real world. This has been documented time and again in this thread and elsewhere. Evidence suggests these benchmark programs are of debatable value for comparisons even on identical hardware platforms using identical operating systems and compilers. This from personal experience, as follows: I purchased the SAS/C development system several months ago. To familiarize myself with the compiler package and for grins, I got ahold of several "popular" benchmark programs and played with them. In turn, again for grins, I ported this stuff to SCO Xenix, SCO UNIX, MS-DOS (a couple of flavours on several hardware platforms), Motorola UNIX, and OS/2. The results were nonsensical, to say the least. I'll give you examples of the most glaring inconsistencies. How about a disk performance benchmark that insisted that an ST-506 drive with a 28ms average access time was *significantly* faster than an ESDI drive with an access time of something like 20ms? Identical binary, identical releases of Xenix SysV, identical hardware platforms, the data sizes were large enough to defeat caching, it was tested when the systems were not busy (as well as when they were - same results), and the filesystems should have been roughly equally fragmented (I know, I know, bad assumption - but there was *quite* a difference in the times - too much to be blamed on fragmentation differences IMHO). From this I can assume that ST-506 systems are faster than ESDI systems? Next, the whole series of benchmarks (dhry, floating-point, and disk performance) were run on the SCO UNIX box as well. Again, same hardware, same binaries. The benchmarks *insisted* that the UNIX system was faster in all respects. Yet users that used both the SCO UNIX and Xenix systems on a regular basis had the very strong perception that the UNIX system was much slower than the Xenix systems - no matter what you were doing (i.e.: compiles that took much longer than previously, etc.). Since it was a fairly comprehensive test suite, from this I guess I can assume that SCO UNIX is faster overall, in spite of the larger and more complex kernel and in spite of user experiences. Lastly, my latest experience (Dave Haynie warned us all about this one - and he was right.) Just before upgrading my A3000 to 4mb of SCRAM, I ran the Dhrystone benchmark. When I ran it again after the RAM change, the benchmark indicated only a very minor performance increase, yet the system is obviously much faster than it had been. Compiles of even small files that didn't come close to exhausting RAM when I had only 2mb were even much faster. Still not convinced? Two of the benchmarks are floating-point intensive. One of them to the point of absurdity. My 25Mhz Amiga performs both of them with roughly the same performance (or better) than a 33Mhz ALR with 80387 and 64k zero-wait state cache. Even before the RAM improvement. Both were compiled to use the math coprocessor directly (in-line floating point) with the latest compiler offerings from SAS and Microsoft. From this I can surmise that the '386/'387 combination is a dog, right? I'd be happy to believe that, for what you're doing, a '386 box is the best solution for *you*. But the '030 is much slower than the '386??? Dave, you've been reading too much Byte Magazine. If you'd like, I'd be happy to dig up a real benchmark comparison between those processors and FAX it to you. What it shows is that the '030 is marginally faster than the '386 with the '030 on-board cache enabled. Other than that, they're about equal (and, btw, the National and AT&T 32-bit offerings way slower than both). Now, as to what can be said about the benchmark tests you've performed? You can say that the benchmarks you've run, compiled with the compilers you've compiled them with, run faster/slower on this machine than on that machine. That's it. If you want to stretch it, you can surmise maybe that the code produced by the compilers you used is more efficient for the '386 systems than that produced for the '030 systems. But implications about the relative performance of a hardware platform, or even the operating system running on it, based on these benchmarks is downright poor scientific method at best and, I suggest, are invalid. Period. And since I rarely use my machines to run benchmarks, their results are of little use to me. I apologize for the bandwidth, but I've been watching this benchmark thing go on for *far* too long. Admittedly, I don't have to read this newsgroup if I don't want to, but I do want to - I'm intensely interested in how CBM has done with their first UNIX offering (been curious ever since I saw the CBM ad for UNIXoid engineers a few years ago). I'd just like to see more facts and less misinformation. [flame off] >In article <a_subsequent_one> david@kessner.denver.co.us (David D. Kessner) writes (in part): >> >>EXXON (EXXOFF?) dumped oil in Alaska, should TEXACO do the same? >> Ha Ha Ha Ha Ha Ha Ha Ha choke gasp heh heh heh... I just about fell out of my chair. Thanks! And I entirely agree with the point you made. -- Jim Seymour | Medar, Inc. ...!uunet!medar!jseymour | 38700 Grand River Ave. jseymour@medar.com | Farmington Hills, MI. 48331 CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897
david@kessner.denver.co.us (David Kessner) (03/30/91)
In article <94@hdwr1.medar.com> jseymour@medar.com (James Seymour) writes: > >In article <EACHUS.91Mar20111051@aries.mitre.org> eachus@aries.mitre.org (Robert I. Eachus) writes (in part): >> >> ... Actually the typical 386/486 >> has two things agenst it: Graphic speed (which can always be solved >> by a $600 34010 board), and Microsoft. ... >> ... We can solve the Microsoft problem by not >> using MS-DOS or OS/2... >> > >Bzzzzzt. Wrong. Microsoft owns a fairly sizeable chunk of SCO unless I'm >sorely mistaken (has happened before tho). Indeed, the SCO development >system is basically a port of the Microsoft C compiler package (and it >shows it). Yes, but there are several other UNIX options. Interactive, ESIX, UHC, BSD, and Microport are just several. BTW, at last check, Microsoft owned 20% of SCO. >> ... First, Dhrystone 1.1 >>should not be used to benchmark anything. ... >> >> ... Dhrystone 2.1 is much better ... > >Huh. May be, but is it any more worthwhile for gleaning anything of any >*real* usefulness? I'm quickly coming to the opinion that it belongs in >the same category as your statement re: Dhrystone 1.1. I'll explain why. Fine! SO well use something like GCC as a benchmark? It doesnt matter to me. I dont hear you suggesting something better... We gotta start somewhere. >[flame on - donning fire-retardant suit] Yea. You and me buddy! :) >David, you reply to Randall's statement with several statements that, in >light of previous articles and Randall's statement, I'm surprised at. Among >them: "The only CONCLUSIVE evidence that the dhrystone has told us is that >the 386 can compute dhrystones faster than the 030 at the same clock speed." Well am I wrong? >That was bad enough, but then you had to go and say: " ... (assuming that >the 386 is significantly faster than the 030) It is sad that a less-than- >optimum design [the 386] could be faster than a clener-better-designed cpu >[the 680x0]. I wondered why the 030 was slower, ..." You mis-read me, please refer to the original artical for the exact context. Here, I take an assumption that the 386 is faster than the 030. For the sake of that paragraph IT DOESNT MATTER. What I am saying here is that the 030 is a cleaner design than the 386. Given the age of the Motorola line of CPU's (in comparison to the age of Intel's _32_bit_ CPU's) I'm suprised that the 030 doesnt blow the socks off the 386 (by that I mean 2-3 times faster, which it is clearly not). In different words: because of the 386's hodge-podge nature, I'm supprised it gets any performance at all-- much less performance that is comparable with the 030. >There is ample evidence that these "hobbyist" benchmark programs are, at >best, lots of fun to play with, but of questionable significance in the >real world. This has been documented time and again in this thread and >elsewhere. Evidence suggests these benchmark programs are of debatable >value for comparisons even on identical hardware platforms using >identical operating systems and compilers. This from personal experience, >as follows: Again. Can you offer something better? >How about a disk performance benchmark that insisted that an ST-506 drive >with a 28ms average access time was *significantly* faster than an ESDI >drive with an access time of something like 20ms? Identical binary, >identical releases of Xenix SysV, identical hardware platforms, the data >sizes were large enough to defeat caching, it was tested when the systems >were not busy (as well as when they were - same results), and the >filesystems should have been roughly equally fragmented (I know, I know, >bad assumption - but there was *quite* a difference in the times - too >much to be blamed on fragmentation differences IMHO). > >From this I can assume that ST-506 systems are faster than ESDI systems? There are many things that can influence the disk performance of a Unix/Xenix system. Some ESDI controllers do 35 to 17 sector translation for ST-506 compatability-- and this takes time. The ESDI drive could have been formatted at the wrong interleave. The XENIX ESDI drivers could be bad. In the case with the same binaries on equivalent machines (sans drives) there is no reason the benchmark would not be valid. It is my experience to look further and see exactly why the results were the way they were. With a little investigation, it can be quite easy to find the reasons for the results. The results of a benchmark should not be taken at blind faith. Unless you know WHY those results were generated, it is almost useless. With the Dhrystone 1.1 restults, we theorize several reasons. Lack of cache, 386 tends to run 'string based' programs faster, compiler optimized for dhrystone, need Dhrystone 2.x, the 386 is just faster, etc. I personally tend to believe the lack of cache, and 'string based 386' myself. The other reasons could be valid, so I am keeping my options open. >Next, the whole series of benchmarks (dhry, floating-point, and disk >performance) were run on the SCO UNIX box as well. Again, same hardware, >same binaries. The benchmarks *insisted* that the UNIX system was faster >in all respects. Yet users that used both the SCO UNIX and Xenix systems >on a regular basis had the very strong perception that the UNIX system >was much slower than the Xenix systems - no matter what you were doing >(i.e.: compiles that took much longer than previously, etc.). Here again, you could have investigated a little more. Because you said, "Yet the users...had the very strong perception that the UNIX system was slower...", I tend to think several things. Did you check to see WHY they thought it was faster? Was their terminals at a higher baud rate, to make aplications appear 'snappy'? Was the UNIX machine doing a larger number of background tasks (news, gateways, network stuff)? Were there more users on the XENIX system. All of these affect the 'apperent' performance of a machine. Since if a machine is processing news, everything else would be slower. A benchmark can measure only the actual CPU time used rather than the real time required, and they are usually ran under minimal system load (when there is not several people are logged in or news is not being processed). Additionaly, you were probably running the AT&T compiler on the UNIX macine and the Microsoft compiler on the XENIX machine. The Microsoft compiler is not known for speed. If you think compiles are slower then MEASURE IT. Do you remember the 'time' and 'timex' commands? While you are at it, learn the 'sar' command (not available on all machines. it reports CPU utilization). >Lastly, my latest experience (Dave Haynie warned us all about this one - >and he was right.) Just before upgrading my A3000 to 4mb of SCRAM, I ran >the Dhrystone benchmark. When I ran it again after the RAM change, the >benchmark indicated only a very minor performance increase, yet the system >is obviously much faster than it had been. Compiles of even small files >that didn't come close to exhausting RAM when I had only 2mb were even >much faster. That is why I'm all for using a different benchmark. I never claimed that the Dhrystone results were conclusive. >Still not convinced? > >Two of the benchmarks are floating-point intensive. One of them to the >point of absurdity. My 25Mhz Amiga performs both of them with roughly >the same performance (or better) than a 33Mhz ALR with 80387 and 64k >zero-wait state cache. Even before the RAM improvement. Both were >compiled to use the math coprocessor directly (in-line floating point) >with the latest compiler offerings from SAS and Microsoft. Benchmarks ran under MS-DOS are misleading at best. Often the results are half the speed as what is achieved under UNIX. My machine runs Dhrystones at 7500 under MS-DOS/Turbo-C++, but 11,900 under UNIX/GCC. This is due to the lack of 32 bit regesters/optimization, having to deal with 64K segments, and the early (pre-387) FPU's required the use of the FWAIT before each FPU instruction (it pauses the CPU till the FPU is done) and this slows things down dramatically. In addition, the 387 has trig instructions while MSC (microsoft C for those slow folks) does not utilize this. >From this I can surmise that the '386/'387 combination is a dog, right? No. From that you can surmise that: Because MS-DOS cannot deal with the advanced features of the 386/387, and that MSC produces code that runs under MS-DOS, the program was severly handicaped because it could not utilize the 386/387 to it's full extent. To take that a step further: MS-DOS is a dog. I dont think that anyone will dispute that. >I'd be happy to believe that, for what you're doing, a '386 box is the >best solution for *you*. But the '030 is much slower than the '386??? I never clamed that my results were conclusive. And I never said any blanket statement like, "The 030 is always slower than the 386". Every time I said something to the effect of "the 386 is faster", I mentioned the SOURCE of my facts and hope we are all men (women) enough to take it at face value. Since I have spent more time defending what I said, I can assume that we are not all men here. C'mon. Lets get back on the REAL ISSUE of: Why Should I Buy An A3000UXD? Every response to that question I have gotten HAVE NOT BEEN ON THE MERITS OF THE MACHINE ITSELF. It's always been "C= Support", "Setup Time", etc. Because of the $7000 price tag (back to the original topic posted by Chris Hanson) I expect more than C= is delivering with Amigs UNIX. Color X, and faster CPU speed are the top on the list. Better X resolutions, Motif, and an FIFO'd serial port are a little further down. Other machines in this price range do have these features are: 386/33 with 34010 board for about $6000. 486/33 for about $7000 486/33 EISA for about $8000 SPARC Clones for about $8000 <-- includes 16" color monitor. and the Color NeXT <-- 17" monitor, 16 bits/pixel While each of these machines have their plus's and minus's it is clear that the A3000UXD has some stiff competition. >Dave, you've been reading too much Byte Magazine. If you'd like, I'd be >happy to dig up a real benchmark comparison between those processors and >FAX it to you. What it shows is that the '030 is marginally faster than >the '386 with the '030 on-board cache enabled. Other than that, they're >about equal (and, btw, the National and AT&T 32-bit offerings way slower >than both). While I read Byte (and PC Mag for that matter), I do not put a lot of weight on their benchmarks-- since they are often wrong. In addition, they know nothing about testing UNIX computers. I am perfectly willing to say that the 030 is roughly equal to the 386 at the same clock speed. All of my results have shown that they are within 20-30% and that is not worth fighting over. It still doesnot take away any signifigance from the A3000UX's lackings... >Now, as to what can be said about the benchmark tests you've performed? >You can say that the benchmarks you've run, compiled with the compilers >you've compiled them with, run faster/slower on this machine than on that >machine. That's it. If you want to stretch it, you can surmise maybe >that the code produced by the compilers you used is more efficient for >the '386 systems than that produced for the '030 systems. Yes! Yes! That's it exactly! Damn. It took you 100+ lines to figure that out! Please take the benchmarks at face value, and dont read into them any more information than what is shown. Just because my machine weighs in at 11,900 dhrystones/sec and the A3000UX gets 6,500 does not mean that the 386 is faster. As I have said before, the only thing that this proves without a doubt is that the 386 runs dhrystones faster than the 030 (using GCC). If everyone would say exactly what you just said in the above paragraph (rather than the whole text), then we could get past the dhrystone thing and focus on the REAL, more relavent, issue of: How does the A3000UX stack up to it's competition. >But implications >about the relative performance of a hardware platform, or even the >operating system running on it, based on these benchmarks is downright >poor scientific method at best and, I suggest, are invalid. Period. >And since I rarely use my machines to run benchmarks, their results are >of little use to me. I have never made any 'implacations about the relative performance...[of the A3000UX]'. I stated what I found, and everyone else read their own interpretation of it. I've spent a whole lot of net-bandwidth trying to say that tactfully, now I have to do it in a less than ideal way. As in: Damn folks. It's not like I'm questioning your manhood. It's not the end of the world or something. etc, etc, etc... >I apologize for the bandwidth... Me too. I apologize. I would have replied to this via mail, but I took this particular artical rather personally. I felt that since the original artical is readable by all, the response should do likewise. Besides, I hope that some of what I said here will clear up exactly what was meant by the posted dhrystone results. >>In article <a_subsequent_one> david@kessner.denver.co.us (David D. Kessner) writes (in part): >>> >>>EXXON (EXXOFF?) dumped oil in Alaska, should TEXACO do the same? >>> > >Ha Ha Ha Ha Ha Ha Ha Ha choke gasp heh heh heh... I just about fell out of >my chair. Thanks! And I entirely agree with the point you made. Well... It is a reasonable statement since EXXON obviously has a problem with _FLOW_CONTROL_... >Jim Seymour | Medar, Inc. >...!uunet!medar!jseymour | 38700 Grand River Ave. >jseymour@medar.com | Farmington Hills, MI. 48331 >CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897 - David Kessner david@kessner.denver.co.us -- David Kessner - david@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);
peter@ficc.ferranti.com (Peter da Silva) (04/02/91)
In article <3043@tpki.toppoint.de> kris@tpki.toppoint.de (Kristian Koehntopp) writes: > peter@ficc.ferranti.com (Peter da Silva) writes: > >Hey, you have any idea how many victims were persuaded to buy Atari STs > >instead of Amigas because of how long it took them to start shipping > >boxes? If they hadn't shipped *something* we'd be running TOS now. > Well, at least _I_ have sold my A2000-A because I was fed up with [ basically, no MMU, no protection ] Can you buy another machine for $500 that provides a protected environment? This stuff has nothing to do with the operating system? The APTR/BPTR stuff is a pain, sure, but it's also a pretty minor part of the system: most programs don't need to know about it. Only stuff that wants to dig through DOS data structures, and most of those programs would have to be setuid programs that dug into /dev/kmem on UNIX. Other than that, you're not going to get better from a consumer machine, period. > Most of the above faults are due to the poor design of the dos.library and > could have been easily avoided. I bought an 386 with XENIX instead. OK, how much did it cost? -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
daveh@cbmvax.commodore.com (Dave Haynie) (04/03/91)
In article <1991Mar22.053324.8867@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >In article <20030@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1991Mar20.100122.1717@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >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). The reason is you're not talking about real DMA here. Read on... >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. Only the high end of PC bus controllers, usually SCSI things on a EISA or MCA bus, do real DMA. What you're thinking of is "DMA" using the standard PC DMA controller rather than the CPU. This DMA controller was faster than a busy PIO loop on an 8088 machine. Not because it ran bus cycles any faster; it didn't. But it pretty much eliminated the overhead of the PIO loop, since it could read from the disk controller, dump to memory, and loop, all without fetching instructions. Once you got to PC-AT level, the 80286 chip could do the PIO move faster than the DMA controller, so most '286 and '386 systems do just that. Neither is an acceptible method in a real multitasking OS. >and the developers of UNIX on a 386 may have done just that-- thinking that >DMA on a multi-tasking system is better... I doubt it. Using the DMA controller would still tie up the bus just as much as the '386 would, doing the move. The DMA controllers still run real slow. The way they address memory beyond 1MB, as I recall, is a kludge (or at least was in the original PC-AT implementation). No matter what, you still end up with two bus crossings, wait states, and no buffering. Most '386 systems use disk interfaces that, like the '386, probably go faster than the DMA controller. While I don't know what the UNIX folks do either, other than maybe pray you have a real DMA (eg, bus mastering) hard disk controller with FIFO or cache, I doubt they use the DMA controller, it is archaic. >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). That'll help performance on a system with a low performance non-DMA controller. It may actually hurt performance on a system like the A3000, though it's not obvious to everyone. Certainly a little bit of intelligent caching helps by eliminating extra seeks, on any system. But, as long as you have a DMA driven hard disk controller that runs bus cycles as fast as the host CPU (as on the A3000), a transfer from the hard disk controller is twice as fast as a CPU cache hit, ignoring cache detection time (which would increase the difference). >You could also go for a cached controller board (that has UNIX drivers). That's exactly what you want in the above fast DMA controller senario. With a slower hard disk interface, the host system needs to do the caching. The A3000 sits somewhere in the middle, caching can help out on the hard disk and to some extent in the host filesystem. >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. You shouldn't do that. That was an HP '030 workstation, the only one in the list, I'll wager, with an external cache. Many '030 systems: Mac IIs (except IIfx), Amigas, NeXT, some of the cheaper workstations in the Sony, Suns, and Apollo lines, have no external cache. Cache isn't the only architectural issue, either. Some of the old Sun video displays, for example, steal lots of time from the main memory bus. VGA isn't fast, but it doesn't intrude on purely CPU intensive benchmarks, either. >Keep in mind that there were for 030/25's in general rather than just the >A3000-- so most were cached... Don't count on it. >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. Actually, the fastest benchmarks you can get on a PC Clone are under MS-DOS with a DOS extender, where you run 32 bits wide but the benchmark has complete ownership of the system. >Hmmm. Can someone tell me what the latest news from CeBit is? I guess I >missed that one... A3000T. See the new AmigaWorld... >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? It might be 2MHz, I'm not sure. Not 4MHz, real production quantities of 4MHz 6502 compatible chips didn't exist back then. Greg Berlin, the designer of the 1581, also designed the A2232 serial card (with 3.56MHz 6502 compatible) and worked with me on the A3000 (he designed the Gary and RAMSEY chips). >David Kessner - david@kessner.denver.co.us | do { -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
jesup@cbmvax.commodore.com (Randell Jesup) (04/03/91)
In article <1991Mar30.090353.9749@kessner.denver.co.us> david@kessner.denver.co.us (David D. Kessner) writes: >Here, I take an assumption that the 386 is faster than the 030. For the >sake of that paragraph IT DOESNT MATTER. What I am saying here is that the >030 is a cleaner design than the 386. Given the age of the Motorola line >of CPU's (in comparison to the age of Intel's _32_bit_ CPU's) I'm suprised >that the 030 doesnt blow the socks off the 386 (by that I mean 2-3 times >faster, which it is clearly not). I wouldn't expect it to when the 386 isn't in MSDOS mode. Effectively, the 386 is a faster processor with a 286 in a corner (yeah, I know, it's not _really_ like that, though the 486 is fairly close to that). In general, Moto and Intel CPUs of the same general vintage are not too far apart (they've been getting closer: 68000 was about equal to 6Mhz 80286 - better in some cases, slower in other). Witness the '486 and the '040: last I saw, the '040 gets 11.8 specmarks, and the 486 gets 8.8. However, for integer operations (dhrystone is integer, though weighted to unusual strings), the '040 gets 12.9, and the '486 gets 13.3 (the '040 FP is 11.0 to 6.6 for the '486). Note that those were both with 128K of external cache, at 25Mhz. >need Dhrystone 2.x, the 386 is just faster, etc. I personally tend to believe >the lack of cache, and 'string based 386' myself. The other reasons could be >valid, so I am keeping my options open. If those 386 results are from a cached machine, I'm certain the '386 would be faster on dhrystone. dhrystone is a semi-cachebuster on an '030, but most of it fits easily in even a small external cache (4K/4K). >Benchmarks ran under MS-DOS are misleading at best. Often the results are >half the speed as what is achieved under UNIX. My machine runs Dhrystones >at 7500 under MS-DOS/Turbo-C++, but 11,900 under UNIX/GCC. This is due to >the lack of 32 bit regesters/optimization, having to deal with 64K segments, >and the early (pre-387) FPU's required the use of the FWAIT before each >FPU instruction (it pauses the CPU till the FPU is done) and this slows >things down dramatically. In addition, the 387 has trig instructions while >MSC (microsoft C for those slow folks) does not utilize this. Note that dhrystone has no FP stuff in it at all. Specmarks are FAR better for any sort of discussion like this. In 680x0 code, "small-model" code is usually faster/smaller than 32-bit code (though of course on a 680x0 you're not forced into either). This is one reason why AmigaDos compilers can produce better numbers than the Unix compilers do. Note the performance of the '486 on FP stuff under Unix in the SpecMarks above, also. > 386/33 with 34010 board for about $6000. > 486/33 for about $7000 > 486/33 EISA for about $8000 > SPARC Clones for about $8000 <-- includes 16" color monitor. > and the Color NeXT <-- 17" monitor, 16 bits/pixel One thing to remember to add: disk and unix itself. Amiga Unix has a 200Meg disk. I'm not certain things like diskless Sparcs include Unix tapes. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
swansonc@acc.stolaf.edu (Chris Swanson) (04/04/91)
First of all, b&w X is only temporary with Amix. Right now the engineers at C= are working on (and RSN will be shipping) a version of color X supporting all of the Amiga resolutions/colors that use the specialized Amiga graphics chips. Rumor has it that the color implimentation is about 4x faster than the current b&w. Also, if you want 1024x1024x8 colors, the 2410 will support that at a probable cost of any TIGA cards for other platforms (like ISA, if not cheaper). The current version of X has support for TIGA routines built in, so buy a TIGA card and away you go. You would have to buy a TIGA board for a ISA machine to get respectible X performance out of it anyway. As far as faster processor speeds, many vendors have anounced 25 MHz '040 cards for the 3000 that all run at or under $1000. Try and get a comprible upgrade for any of the machines you named for an equivelent price. -Chris -- Chris Swanson, Chem/CS/Pre-med Undergrad, St. Olaf College, Northfield,MN 55057 DDN: (CDS6) INTERNET: swansonc@acc.stolaf.edu UUCP: uunet!stolaf!swansonc AT&T: Work: (507)-645-4528 Home: (507)-663-6424 I would deny this reality, but that wouldn't pay the bills...
pegram@kira.UUCP (Robert B. Pegram) (04/04/91)
> Hey, you have any idea how many victims were persuaded to buy Atari STs > instead of Amigas because of how long it took them to start shipping > boxes? If they hadn't shipped *something* we'd be running TOS now. Doubt it. 8-) > -- > Peter da Silva. `-_-' peter@ferranti.com > +1 713 274 5180. 'U` "Have you hugged your wolf today?" ^Yup both of them 8-). Hey Peter, I bought my Atari for the crisp mono display and the 68K - the Ami of the day ('85) gave me a headache when viewing text. I didn't see why I needed multitasking - I learned! - and I didn't like the way workbench and Amiga apps looked. I also heard horror stories about the shell (shouldn't have listened to those 8-). Most all of this has been fixed now, send flames to .advocacy ok? In any case, I've had to do less to my Atari to keep current than I would have if I had gotten a 1000 - rather a sad commentary on Atari and Commodore both, for different reasons. When I consider upgrading, I get a headache still, since my options either lack software, and/or have architectural limitations that bug me. I have a list of them for the Amiga too, it's not just Ataris, Macs and especially IBM clones that are outdated and saddled with hardware or software decisions that aged too quickly. Trying to show the other side, Bob Pegram pegram@griffin.uvm.edu or ...!uvm-gen!pegram
po87553@korppi.tut.fi (Pasi 'Albert' Ojala) (04/05/91)
I haven't followed this newsgroup very tight so could someone gimme a short raport of following things: -Amiga Unix, is it stabile? -Is it available for an ordinary user -How much does it cost? -Where I can get it? -Hardware requirements (I've A2000 with 100 meg hard disk, A2620, 8 megs of RAM and flickerFixer). <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Pasi Ojala Pasbox v2.6 Why does my signature keep changing?? po87553@tut.fi C64 forever Am I doing something wrong? <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
peter@ficc.ferranti.com (Peter da Silva) (04/05/91)
In article <1991Apr3.231414.23689@uvm.edu> pegram@kira.UUCP (Robert B. Pegram) writes: > Most all of this has been fixed now, send flames to .advocacy ok? This isn't a flame... it's a simple statement of fact. The Atari ST was sufficiently compelling a product that people did buy them when it looked like the Amiga was stalled. I got an Atari ST from one such person when he finally got an Amiga. The point I was trying to make is simply that if Commodore hadn't shipped something there wouldn't have been *any* market left for them to sell Amiga 1000s to. And the phrase "victim" is entirely appropriate. My buddy and I were both victims of the "my god, Commodore, when ARE you going to ship" syndrome. If they hadn't shipped when they did, we'd be using TOS now. (luckily I had little enough invested in the Atari I could get an Amiga without cringing) > In > any case, I've had to do less to my Atari to keep current than I would > have if I had gotten a 1000 - rather a sad commentary on Atari and > Commodore both, for different reasons. My Amiga 1000 is still, as of today, "current". And I haven't done anything to it. I'll have to do the first upgrade, five years later, when 2.0 comes out. Not bad. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jesup@cbmvax.commodore.com (Randell Jesup) (04/05/91)
In article <3KHASM9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >My Amiga 1000 is still, as of today, "current". And I haven't done anything >to it. I'll have to do the first upgrade, five years later, when 2.0 comes >out. Not bad. You don't _have_ to. You could get a kickstart eliminator and plug an A2000 2.0 rom into it (I think it has two rom sockets, so you could pop a 1.3 in there too if you care). Other (software) solutions may be available if you have expansion memory (developers can use these tools today to run 2.0 betas on A1000's). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
peter@ficc.ferranti.com (Peter da Silva) (04/06/91)
In article <20384@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > In article <3KHASM9@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >My Amiga 1000 is still, as of today, "current". And I haven't done anything > >to it. I'll have to do the first upgrade, five years later, when 2.0 comes > >out. Not bad. > You don't _have_ to. You could get a kickstart eliminator and plug > an A2000 2.0 rom into it (I think it has two rom sockets, so you could pop > a 1.3 in there too if you care). That's the sort of thing I was referring to when I used the word "upgrade". When I say I haven't done anything to it, it doesn't have so much as a single chip that wasn't in it when it left the loading dock at Commodore. (I've already bought a 3000, back in August. Hey, what's the word on this new warranty for older "professional" Amigas? I'm getting mixed signals.) I would have preferred an official 1000 kickstart disk, though, if you don't mind a brief foray into fantasy mode... -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
jesup@cbmvax.commodore.com (Randell Jesup) (04/06/91)
In article <TFIA+=1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >I would have preferred an official 1000 kickstart disk, though, if you don't >mind a brief foray into fantasy mode... It's not technically impossible (though it still requires at least 256K of autoconfig ram, and a bunch of work on bryce's part). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup Disclaimer: Nothing I say is anything other than my personal opinion. Thus spake the Master Ninjei: "To program a million-line operating system is easy, to change a man's temperament is more difficult." (From "The Zen of Programming") ;-)
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/08/91)
In article <20429@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article <TFIA+=1@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>I would have preferred an official 1000 kickstart disk, though, if you don't >>mind a brief foray into fantasy mode... > > It's not technically impossible (though it still requires at least >256K of autoconfig ram, and a bunch of work on bryce's part). > >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. >{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup >Disclaimer: Nothing I say is anything other than my personal opinion. >Thus spake the Master Ninjei: "To program a million-line operating system >is easy, to change a man's temperament is more difficult." >(From "The Zen of Programming") ;-) Even though I don't use my A1000 much anymore (not w/ an A3000 on my desk), it seems to me that that is just making for unnecessary work. why not have an A1000 kickstart which kicks a dummy 1.3 OS which then does nothing more than load another 512K (2.0) off the floppy? As far as the user is concerned, it would LOOK the same (stick in a 2.0 kickstart and it goes), just take longer. The 512K could go into *normal* ram so it's contiguous. I guess you'd have to write off the WCS since, it seems, to leave it write-enabled also leaves the boot rom mapped. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
andy@cbmvax.commodore.com (Andy Finkel) (04/09/91)
In article <dillon.6209@overload.Berkeley.CA.US> dillon@overload.Berkeley.CA.US (Matthew Dillon) writes: > why not have an A1000 kickstart which kicks a dummy 1.3 OS which then > does nothing more than load another 512K (2.0) off the floppy? As far > as the user is concerned, it would LOOK the same (stick in a 2.0 > kickstart and it goes), just take longer. > > The 512K could go into *normal* ram so it's contiguous. I guess > you'd have to write off the WCS since, it seems, to leave it > write-enabled also leaves the boot rom mapped. > > -Matt We could do that; and then addmen the f80000 ram; however, since we needed to develop the technology to split the kickstart rom into two pieces anyway, for compatibility with some games, it might be better to put part of the kickstart in the kickstart WCS. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "To finish the project, all we need is a derranged programmer", said Master Li. "It is fortunate indeed that we are blessed with an overabundance." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.