On Sun, Jun 14, 1998 2:20 PM, Hauke Fath
<mailto:hauke@Espresso.Rhein-Neckar.DE> wrote:
> At 8:54 Uhr +0200 12.06.1998, Vincent BARAT wrote:
> >Bruce Anderson wrote:
> >>
> >> Your Centris 650 has a 16MHz I/O bus and no L2 cache.
> >> compair that with a 486 mother board I have laying about
> >>  64-256K L2 and I/O bus speed of 16 to 50MHz.
> 
> Not quite. The NuBus, if you are referring to that, is a 32Bit wide

I was  referring to the I/O bus.
(See <A HREF="http://developer.apple.com/techpubs/hardware/
Developer_Notes/Macintosh_CPUs-68K_Desktop/
Mac_Centris_Quadra_800.pdf">Quadra 800</A>
Chapter 2: "Architecture" page 14 (page 26 of 96) paragraph three.)

> synchronous bus clocked with 10 MHz. An extension named "NuBus90" that
> doubles the clock rate and is present in the Quadra class machines is
> available to extension cards but not used by the motherboard itself.
> But this is not relevant for the benchmark in question, as all the
> components that are needed (CPU, memory, SCSI interface) are on-board
> and
> more-or-less running with CPU speed.
> 
> I wouldn't expect too much from a second level cache, either: The Q700 I
> run came with a Radius 128k 2nd level cache, and according to
> Speedometer 4
> tests the gain is in the 0..10% range - not impressive.
> 
> >Don't you think it could be interesting to know bytemark results
> >of a few of our machines ?
> >
> >You could download it and view Linux PC results at:
> >
> >http://www.silkroad.com/bass/linux/
> 
> Here we go... The machine in question is a Quadra 700 clocked with 33MHz
> (true 68040/33), 128K 2nd level cache, 68MB RAM, 2MB VRAM, 4GB IBM
> DCAS
> disk. Rather top range as m68k Macintoshes go.

[SNIP ]

> 
> 
> Some annotations:
> 
> o  Results are qualitative, at best. Running single-user, the box lost 10
> min (that's "ten minutes") against the wall clock during the benchmark. I
> did not see the issue discussed on the web page; even systems with higher
> prioritized clock interrupts than ours run at splhigh() sometimes.
> 
> o  Some tests ("Execl throughput") were extremely sensitive to
> optimization
> levels. I wouldn't expect to see any effect in real life applications.
> 
> o  This is a 1.3B kernel. -current kernels with _vfork14() and Chuck
> Cranor's VM system may well do better.
> 
> o  Looking at the list, the box comes out shortly behind 486DX2/66
> machines. Disk I/O is rather weak in spite of the fast disk -- we don't
> have busmaster DMA. Integer arithmetics are fine, mostly.
> 
> 	hauke
> 
> 
> --
> "It's never straight up and down"     (DEVO)
> 
> 
> 
>