> >Again, are you absolutely sure? What's the point of interleaved RAM if the
>bus is slower than the 16-bit 25-33 MHz bus (50-66 MB/s) in a Quadra?

 I am absolutely sure as I have tested it using 3 different means.
 The best being a RAM disk and using ATTO's disk transfer tests.
 Also, GaugePro's RAM speed gives the same numbers.  In OS X, XBench's
 memory tests which test system RAM give the same number.

Um, that's not testing the system bus speed. that's testing the speed of a specific component connected to the system bus with a specific operation. And you don't even know what that operation is because you don't have access to the code.

The System Bus speed is MHz as set by the CPU card. The RAM throughput numbers are the closest way I know to measure how the hardware and OS can take advantage of the RAM/Bus/CPU throughput. If you have a better way to measure it, I'll be happy to test it. Other than that, it's all just theory. I'm trying to get a handle on the speed of those components of these Macs with tests I can do with dependable repeatability.


RAM throughput in Quadras as tested is about 16 MB/sec max (see LEM), so the PMacs are faster than the Quadras. The bigger step forward in RAM/bus throughput was with the better memory controller introduced with the Sawtooth G4. Apple really crowed about it when they were introduced. De-interleaving the RAM in the 7300-9600 Macs reduced the tested speed by 10% or less

> I'm
 convinced.  As for why it's not the theoretical maximum, no computers
 ever reach that, not even the PCs with their Rambus memory.

The problem is that's not only "not the theoretical maximum", it's further from the theoretical maximum than I've measured for any real computer. It's also suspicious that it's exactly the same as the bus speed, as if the test was deliberately reading single bytes with a stride designed to avoid any impact from the cache or interleave.

Finally, if you were really measuring bus bandwidth there you would expect
the RAM-disk test to give you no more than half the available bandwidth
because it's hitting the bus *twice* for each block, once to read it and
once to write it.

I have suspected as much as it makes sense to read data from one place (in RAM) and write to to another (the RAM disk). All the tests do the same as far as the documentation states: move data from one place in RAM to another, which would consist of one read and one write step, thus giving you a number which approached half the real memory bandwidth.


> Older
 Macs (before the Sawtooth G4s) has particuarly pathetic RAM speeds
 thanks to a rather outdated RAM chipset.  Just moving from a B&W G3
 (100 MHz bus speed) to the Sawtooth G4 (100 MHz Bus speed), the RAM
 speed went from 100 MB/sec to 250 MB/sec.  Same RAM.  Half of it is
 from a better memory controller and half of it is from the G4 chip.

Really? Can you explain why a component attached to the bus changes the bus bandwidth that much? Are you sure you're not measuring cache?

 PMac 9500:
 200 MHz 604e:  35 MB/sec (same for all CPU speeds if bus speed is constant)
 400 MHz G3:  50 MB/sec
 400 MHz G4:  80 MB/sec

Same RAM? Same system bus? You're not measuring the bandwidth of the bus if it's changing that dramatically.

Same RAM, same Mac (PMac 7600 and 9500 tested). I think that I am measuring the ability of the processor/CPU/bus to move data around the motherboard (not just the bus) and that the numbers are real. It would seem that the addition of a newer/better processor reduces a processor-induced throughput bottleneck. Again, theoretical throughput of the bus isn't relevant if the processor/CPU/bus is only limiting you to 80- really 160 MB/sec, re: your above comments.


> On a 1024x768 screen, make a finder window half the size of the
 screen. Drag it around the screen.  on the unsupported Rev A. Beiges
 and iMacs, the window moving is choppy.  Change to Thousands of
> Colors from Millions and it is *noticeably* less choppy.

For an opaque window, yes, I see slightly faster compositing. For a
translucent window I can't tell the difference. For a translucent
image over a translucent image, thousands is clearly slower.

I haven't tested this as I forget which windows are translucent. Now that I think of it, menus are translucent and menu fading *plenty slow* on all PCI based video Macs if you have a full screen sized menu (long bookmark in Safari). Even on the normally sprightly PCI Rage128 in the Beige G3/500, it's choppy compared to by AGP Rage128 in my G4/450DP (nice and smooth). With the Beige's built-in video, it's a bit slower than the PCI Rage128 (not much) but the difference between both and between Thousands and Millions is minimal (especially when compared to the 2x differences in scroll speed). I need a better test that I can give numbers with.


> > > Video speed is slower in OS X in slower computers (less than 800 MHz
>> G4) under Millions of colors than under Thousands.

 >That's not what I observed. Have you actually checked this with the stock
 >7x00 video?

 I haven't used the stock video on my 7500 yet.  I'll try that soon
 (tomorrow if it's not too busy).   I can't see that it'll be any
 faster than the Beige's built-in video.

That's not what I'm questioning, it's whether rendering and complex compositing (not just scrolling and dragging opaque windows, which are not the operations I'm finding to be the bottleneck) is faster in 16 or 24 bit.

Again, I don't know how to test that aside from the full screen menu fading I mentioned above. What operations aside from menu drawing use this consistently? I'd like to test it in a number of machines I have access to.


Also, how much VRAM do you have? You'll need 4M to get to 24 bit at higher
resolutions.

I have 4MB.


- Tom


-- Unsupported OS X is sponsored by <http://lowendmac.com/>

Support Low End Mac <http://lowendmac.com/lists/support.html>

Unsupported OS X list info <http://lowendmac.com/lists/unsupported.html>
 --> AOL users, remove "mailto:";
Send list messages to:     <mailto:[EMAIL PROTECTED]>
To unsubscribe, email:     <mailto:[EMAIL PROTECTED]>
For digest mode, email:    <mailto:[EMAIL PROTECTED]>
Subscription questions:    <mailto:[EMAIL PROTECTED]>
Archive <http://www.mail-archive.com/unsupportedosx%40mail.maclaunch.com/>

Using a Mac? Free email & more at Applelinks! http://www.applelinks.com



Reply via email to