> >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. > 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. > 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. > 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. > > > 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. Also, how much VRAM do you have? You'll need 4M to get to 24 bit at higher resolutions. -- 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
