kiessig@sri-unix (07/21/82)
I'd like to stimulate some discussion on this list about people's experiences with UNIX on the 68000. Good or bad. Performance, reliability, viability in the commercial environment, etc. Measurements on Fortune's 32:16 (runs at about 5.6MHz) seem to put it about in a league with a PDP 11/34, performance-wise. This is with a DMA 5.25" Winchester as the root/swap media. If there are some benchmarks available generally, it would be interesting to run them on a variety of 68K-based machines. Rick
mark (07/29/82)
I have a question. I saw several claims in this newsgroup this morning that the 68000 does not allow reasonable paging, and that people should wait for th 68010. I have also seen claims by SMI and CadLinc that their SUN board behaves exactly like the 68010 memory-management-wise, so software will be plug compatible when the 68010 boards come out. Will someone please explain? Mark
grunwald (07/31/82)
#R:fortune:-16000:uiucdcs:23900002:000:356 uiucdcs!grunwald Jul 30 21:17:00 1982 What they mean is that their memory management will be able to handle the 68010 not that their boards will currently allow demand paging. As it stands, they point out that they can not handle this, and that you need to wait for the 68010 for full paging. The system can handle paging of either just data or instructions (I don't remember which) currently.
tjt (08/02/82)
68000 systems that use a second processor to handle page faults while the first processor is in a very long memory wait can (or should) be able to handle arbitrary page faults (i.e. there should be no reason why only data or only program references would work). The catch is that with the dual processor scheme, there is nothing else you can do during a page fault (except field interrupts -- provided the hardware allows the second processor to handle interrupts when the first processor is stalled). In particular, the first processor cannot run code for another process since the paging stunt depends on that processor hanging in a memory cycle. Depending on how independent the second processor is, you may be able to get other useful work out of it when it isn't handling a page fault (I believe that Apollo uses a second processor to handle the network and some graphics), but in order to do this effectively it would need some memory of its own (or else some very fast system memory). The problem is that a 68000 is basically a memory-limited machine (most internal clock cycles are used for memory cycles), and are often faster than system memory (i.e. wait states are required), so there isn't any extra bandwidth for a second processor to run without drastically interfering with the first. The limitation on page fault handling imposed by the second processor should not be too big a problem on a single user system, although ambititous UNIX users can easily generate several active processes (i.e. edit in foreground with a compilation in the background), but would obviously have a chilling effect on time sharing.