taab5@ccvax.iastate.edu (Marc Barrett) (01/29/91)
It has been discussed before (especially in comp.sys.amiga.hardware)
that, when a CPU card (such as a 68040 card) is added to the Amiga 3000,
the 68030 on the motherboard remains available as a coprocessor.
Unfortunately, neither AmigaOS nor UNIX SysVR4 support multiprocessing,
so although the 68030 remains available hardware-wise, it is unavailable
for use because of the system software.
My question is, would it be possible for Commodore to modify their
version of UNIX SysVR4 to support symmetric multiprocessing? Although
this version of UNIX does not support symmetric multiprocessing as it
is written, other companies -- including Solbourne, Sequent, Corollary,
Pyramid, Encore, ALR, and Compaq -- have successfully modified older
versions of AT&T UNIX System V to support symmetric multiprocessing.
If Commodore could do the same, and add symmetric multiprocessing
to Amiga UNIX, this would permit both of the processors to be used at
once in a multiprocessor Amiga 3000. More importantly, it would allow
Commodore to join only a handful of other companies that produce
multiprocessor UNIX workstation systems. Not only would Commodore have
a true multiprocessor workstation, but their could market this system
at less than 1/3 the price of other similar multiprocessor systems.
I hope someone at Commodore sees this, and investigates this idea.
Adding symmetric multiprocessing to Amiga UNIX would allow Commodore
to sell true multiprocessing systems at a price that is less than similar
single-processor systems. This would be the biggest advance to the
Amiga's multitasking capability since it was introduced back in 1985.
-MB-ken@dali.gatech.edu (Ken Seefried iii) (01/30/91)
In article <1991Jan29.024542.1@ccvax.iastate.edu> taab5@ccvax.iastate.edu (Marc Barrett) writes: > > It has been discussed before (especially in comp.sys.amiga.hardware) >that, when a CPU card (such as a 68040 card) is added to the Amiga 3000, >the 68030 on the motherboard remains available as a coprocessor. >Unfortunately, neither AmigaOS nor UNIX SysVR4 support multiprocessing, >so although the 68030 remains available hardware-wise, it is unavailable >for use because of the system software. Two problems with symmetric multiprocessing: The 68030 has something like a quarter of the horsepower the '040 has, making response time in an SM system erratic at best. Second, you need hardware support to do real SM, for things like cache coherency and resource locking (yes, I *know* I'm glossing over a lot of things...I'm tired). Does this little accellerator board support, say, shared memory between the '040 and the '030? Now, as long as the '040 and the '030 could interrupt one another, you could use the '030 as an I/O front end of some sort. That might make sense... -- ken seefried iii "A sneer, a snarl, a whip that ken@dali.cc.gatech.edu stings...these are a few of my favorite things..."
scott@texnext.gac.edu (Scott Hess) (01/30/91)
In article <1991Jan29.024542.1@ccvax.iastate.edu> taab5@ccvax.iastate.edu (Marc Barrett) writes: If Commodore could do the same, and add symmetric multiprocessing to Amiga UNIX, this would permit both of the processors to be used at once in a multiprocessor Amiga 3000. More importantly, it would allow Commodore to join only a handful of other companies that produce multiprocessor UNIX workstation systems. Not only would Commodore have a true multiprocessor workstation, but their could market this system at less than 1/3 the price of other similar multiprocessor systems. Actually, I don't know how worth it it would be to have symmetric multiprocessing with a 68040 and a 68030 working in tandem. The '040 is quite a bit better (this is sort of like an 8088/80286 team, or 68030/68000 team, though not quite _that_ bad). I think an easier, and more than likely faster, route would be to offload io processing to the 68030. This works well for many machines, and when you're running Unix, it's really an advantage. One problem with cheap (not as in flakey - cheap in $$) Unix systems is that they have cheap peripherals. And cheap peripherals means that the CPU is doing work on behalf of the peripheral to make up for lack of capability, in general. For example, look at all the cheap MSDOS-world hard drives - most are cheap because the controller's intelligence (as it were) looks much like a PC clone . . . :-). Having a second CPU to handle the disk drive requests and networking would be alot like having all the advantages of brains on the peripherals without actually having any brains there. With the '040's speed, I think that the '040 could easily keep the '030 busy, esp. if it was accelerated (>25Mhz). > -MB- Good post, though. -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Tried anarchy, once. Found it had too many constraints . . ." "Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by Richard Simmons . . ."
kent@swrinde.nde.swri.edu (Kent D. Polk) (01/30/91)
In article <20668@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >Now, as long as the '040 and the '030 could interrupt one another, you >could use the '030 as an I/O front end of some sort. Not only for an I/O front end (including tcp/ip), but for X11 graphics rendering, possibly? Kent Polk: Southwest Research Institute (512) 522-2882 Internet : kent@swrinde.nde.swri.edu UUCP : $ {cs.utexas.edu, gatech!petro, sun!texsun}!swrinde!kent
doug@ctc.contel.com (Doug Whitehead) (01/30/91)
In article <1991Jan29.024542.1@ccvax.iastate.edu> taab5@ccvax.iastate.edu (Marc Barrett) writes: If Commodore could do the same, and add symmetric multiprocessing to Amiga UNIX, this would permit both of the processors to be used at once in a multiprocessor Amiga 3000. And Scott Hess (scott@texnext.gac.edu) replies: Actually, I don't know how worth it it would be to have symmetric multiprocessing with a 68040 and a 68030 working in tandem. The '040 is quite a bit better (this is sort of like an 8088/80286 team, or 68030/68000 team, though not quite _that_ bad). I think an easier, and more than likely faster, route would be to offload io processing to the 68030. My embellishment: Hey why not use the 68030 exclusively for an X server! Some folks pay the cost of an AmigaUX just for an X server. This would be a KILLER X window system!!! Doug Whitehead Doug Whitehead (doug@ctc.contel.com)
ken@dali.gatech.edu (Ken Seefried iii) (01/30/91)
In article <994@swrinde.nde.swri.edu> kent@swrinde.nde.swri.edu (Kent D. Polk) writes: >In article <20668@hydra.gatech.EDU> ken@dali.gatech.edu (Ken Seefried iii) writes: >>Now, as long as the '040 and the '030 could interrupt one another, you >>could use the '030 as an I/O front end of some sort. >Not only for an I/O front end (including tcp/ip), but for X11 graphics >rendering, possibly? Keith Packard (the X Performance Man at MIT) has indicated that the best way to speed up an X server is to put it on a fast processer with good memory bandwidth and direct access to the frame buffer. The worst way is to try and stick it at arms length on some form of co-processor. Bottom line seems to be that if your concern is a fast X server, leave it on the '040. If you offload disk, net and serial traffic from the main CPU, I think you'll see a big win all the way around. 'Course, I'd want to get some empirical data before I bet the farm on it... -- ken seefried iii "A sneer, a snarl, a whip that ken@dali.cc.gatech.edu stings...these are a few of my favorite things..."
crs@convex.cl.msu.edu (Charles Severance (System Manager)) (01/30/91)
Just another idea for use of the spare '030 in the Amiga. There is a lot of CPU wasted to run the bit-mapped graphics display when running X-Windows, open-look, etc. The '030 could run dedicated display software and be sent messages about what is to be displayed. (almost like having the '030 acting like an X-terminal in the same box.) Then the '040 could do the actual work. Just an idea... -- Charles Severance internet: crs@convex.cl.msu.edu Michigan State University phone: (517) 353-2984 301 Computer Center fax: (517) 353-9847 East Lansing, MI 48824 bitnet: 20095CRS@MSU
bernie@metapro.DIALix.oz.au (Bernd Felsche) (01/31/91)
In <1991Jan29.024542.1@ccvax.iastate.edu> taab5@ccvax.iastate.edu (Marc Barrett) writes: > It has been discussed before (especially in comp.sys.amiga.hardware) >that, when a CPU card (such as a 68040 card) is added to the Amiga 3000, >the 68030 on the motherboard remains available as a coprocessor. True on the 25MHz motherboard. >Unfortunately, neither AmigaOS nor UNIX SysVR4 support multiprocessing, >so although the 68030 remains available hardware-wise, it is unavailable >for use because of the system software. Don't jump the gun, Marc. SYSVR4 does not *yet* support multi- processing. (Why do I feel that this thread is going to wind up in my kill file?) Please catch up with the news on UNIX, before you make outrageous comments. I'm sure that when you take delivery of the `040 coprocessor for your A3000UX, SYSVR4 multiprocessing will be a bit closer than just the horizon. If it is wise to do so, and other posters have already pointed out that merits may be dubious, SMP could be available for the Amiga, under UNIX, and maybe (earlier?) under AmigaDOS (Did I just hear CBM's software engineers scramble for the exit :-) ?). IMHO, the `030 is of far more use as an I/O processor, though the hardware requirements for making this work _really_ well, would be greater than a direct plug-in. (e.g. Most interrupt signals would have to be "masked" from the `040.) -- _--_|\ Bernd Felsche #include <std/disclaimer.h> / \ Metapro Systems, 328 Albany Highway, Victoria Park, Western Australia \_.--._/ Fax: +61 9 472 3337 Phone: +61 9 362 9355 TZ=WST-8 v E-Mail: bernie@metapro.DIALix.oz.au | bernie@DIALix.oz.au
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (02/04/91)
dvp@sequent.com (Dan Vander Ploeg) writes: > Marc Barrett: >> Although this version of UNIX does not support symmetric >> multiprocessing as it is written, other companies -- including >> Solbourne, Sequent, Corollary, Pyramid, Encore, ALR, and Compaq -- >> have successfully modified older versions of AT&T UNIX System V to >> support symmetric multiprocessing. > It was announced a few months ago that Sequent is working with AT&T to > add SMP to SYS V. And of course, the really interesting case is not the rather imbalanced '040/'030 pair, but the situation when several '040's are slotted in. There have already been successful experiments distributing graphics processing of the sort useful for multimedia work across networked cpu's. It would probably work a lot better to distribute similar tasks across a fast bus with common memory, instead. Anybody want to bring up Linda on the Amiga? ;-) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (02/05/91)
/y xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > > dvp@sequent.com (Dan Vander Ploeg) writes: >> Marc Barrett: > >>> Although this version of UNIX does not support symmetric >>> multiprocessing as it is written, other companies -- including >>> Solbourne, Sequent, Corollary, Pyramid, Encore, ALR, and Compaq -- >>> have successfully modified older versions of AT&T UNIX System V to >>> support symmetric multiprocessing. > >> It was announced a few months ago that Sequent is working with AT&T to >> add SMP to SYS V. > >And of course, the really interesting case is not the rather imbalanced >'040/'030 pair, but the situation when several '040's are slotted in. > >There have already been successful experiments distributing graphics >processing of the sort useful for multimedia work across networked >cpu's. It would probably work a lot better to distribute similar tasks >across a fast bus with common memory, instead. Well, i just recently recieved my 68040 users manual and designers handbook from motorola, and notice some interesting things. for instance it would be quite usable to have an 040/030 pair with the 040's bus snooping capabilites. the dual mmu's in the 040 would also make it easy to protect data memory, while allowing re-entrant code to function properly. they even give complete diagrams and pal coding for an adapter board to fit into an 030 system. > >Anybody want to bring up Linda on the Amiga? ;-) > >Kent, the man from xanth. ><xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
ford@amix.commodore.com (Mike "Ford" Ditto) (02/16/91)
david@twg.com (David S. Herron) writes: > You're right.. converting Unix to multi-processing isn't easy. There's > all those references to "u", and all those algorithms that don't lock > their data structures, etc etc ... "u" is not haphazardly referenced in SVR4 as it was in previous versions. Device driver and filesystem code is now much cleaner, receiving its parameters by function arguments. Locking is a bit better but still doesn't seem suitable for multithreaded use. Obviously, things like that will change for SVR4/SMP. BTW, I beleive AT&T says that both R4/ES ("Enhanced Security") and R4/SMP ("Symmetric MultiProcessing") will be ready for release in early 1992, and available to developers much sooner than that. -=] Ford [=- "Like a pizza in the rain, (In Real Life: Mike Ditto) no one wants to take you home." ford@amix.commodore.com - David Byrne, "Loco de Amor" uunet!cbmvax!ditto ford@kenobi.commodore.com