Introduction
There's still 2 1/2 months to go until Intel will launch the new i820-chipset, also known as 'Camino'. However, the early days in the life of Camino are long over. People who closely followed Intel's roadmap in the last 9 months know that Intel pushed the release of Camino from June 99 back to September 5, 1999, because the price of the RAM used in combination with this chipset (RDRAM) was not coming down as quickly as expected. Thus it shouldn't be a surprise that Intel has already finished the 'B0'-stepping of i820, which normally is the first release silicon.
RDRAM, The Controversy-Memory
We've already heard tons about the 'Camino-controversy', which mainly goes on about Camino's focus on a new memory type, known as 'direct Rambus RAM' or RDRAM. This RAM has the advantage of a very high peak bandwidth, but the disadvantage of a high latency at the same time. We also know that Intel does not believe that the next type of SDRAM, known as PC133 SDRAM, is going to be a feasible thing, resulting in a lack of support of this new SDRAM-type in all future Intel products.
AGP4x
Camino adds some other nice features, one of the less impressive ones is the support of the new ATA66-EIDE standard that's already realized in Intel's integrated i810-solution. The most anticipated new feature is Camino's introduction of AGP4x. This new AGP-standard can transport double the amount of data to the current AGP-standard, which makes most sense in combination with a high bandwidth system memory, but we still shouldn't expect too much of it. So far it's difficult to see any difference between AGP1x and AGP2x products, let alone the lack of AGP-support in the well-performing 3D-graphics solutions from 3Dfx.
Expectations
First of all, an i820-platform should provide a better performance than the well-known BX-chipset, since this is the chipset that Camino is supposed to replace. Memory performance does not have that much of an impact on overall system performance as one might think, most software doesn't even make much of a difference between SDRAM running at 66 MHz versus PC100 SDRAM, but there should still be some improvement in performance of Camino over BX, since Camino's 400 MHz PC400 RDRAM has exactly twice the bandwidth of PC100 SDRAM. However, let's not forget that the CPU can only take advantage of 33% more memory bandwidth, and this only in case if the CPU runs at 133 MHz FSB. The other thing that should improve more or less significantly is the graphics performance, but as we know it already from AGP2x, only very few gaming applications do really take advantage of the AGP-bandwidth.
Testing Was Tough
I had the pleasure to fight with a Camino-board that was equipped with the B0-stepping of i820. The motherboard came with three RIMM slots, it was not equipped with the new 'MTH' and any DIMM Slots for PC100 SDRAM.
RIMM-Slots don't look much different to DIMM-Slots, but you have to fill each empty slot with a terminator to avoid any reflections at the high speed Rambus-interface. I was unfortunately not lucky enough to get more than 64 MB PC800 RDRAM, so that I had to test the systems with less RAM than I usually use. You can imagine that more RAM would have been better to show the performance differences of the different platforms, but 64 MB should still be enough for a first evaluation.
RDRAMS-Versions
There's one interesting note that may not be known to the majority of you. There are now three different RDRAM-versions, PC600, PC700 and PC800 RDRAM, according to a Rambus-interface clock of 300, 356 and 400 MHz, and I wanted to test PC600 against PC800. The PC800-RDRAM I have would of course run at 300 MHz as well, but this seems to be possible at 100 MHz FSB only. It seems as if at 133 MHz FSB you're only able to run RDRAM at 400 MHz, at 100 MHz FSB you can choose between 300 and 400 MHz. This was definitely the case for the board I've tested, but it could be that later revisions can run PC600-RDRAM at 133 MHz FSB as well. It's also possible that the RDRAM speed has to be a product of the FSB. In case of a FSB of 133 MHz this would mean that only 400 = 133*3 MHz is possible, but at 100 MHz FSB there's 300=100*3 and 400=100*4. It's not very likely that Intel will keep the RDRAM-speed tight to the FSB though, because this would make PC700 completely impossible.
I was also not quite lucky with the AGP4x. The Savage4-driver crashed before reaching the Windows98-desktop and TNT2 would produce general protection faults as soon as I started a 3D-application. Thus I could only test with office applications or some special software. 3D games were unfortunately out of the question. I will supply you with AGP4x-results as soon as I'll get a platform that does it properly.
I also came across an odd problem with Pentium III's L2-cache. As soon as I clocked my PIII higher than 550 MHz, the L2-cache wasn't recognised by the motherboard anymore. This made it very easy to run the special benchmarks in which I wanted the L2-cache to be disabled, but it did not give me the chance to do a normal benchmark comparison between Camino and BX at 600 MHz. Instead of this I compared 533/133 results to 550/100 results, which I consider as pretty sensible. 533 MHz is not much less than 550 MHz at all.
Test Setup
As BX-platform I used the following:
- Intel Pentium III 550 processor w/o multiplier lock
- Abit BX6 Rev.2 BX-motherboard
- 64 MB PC100 SDRAM from Micron, which ran at a latency setting of '2' even under 133 MHz FSB
- Hercules Dynamyte TNT2 AGP graphics card, NVIDIA reference driver 0188
- Western Digital WDAC 418000 EIDE HDD w/ATA66-support
The equipment of the Camino-board was identical except of the 64 MB PC800 RDRAM RIMM.
The tests were ran under Windows 98, built 4.10.1998 at 1024x768x16 bit screen resolution. The refresh rate was 85 Hz. The benchmark software used was BAPCo Sysmark98 and Intel's Application Launcher Benchmark. I preferred BAPCo over Winstone, because it reports the results more accurately and it's a lot easier to do several runs. It takes a good amount longer than Winstone though.
Please be aware of the fact that Camino is not optimized for the highest performance yet. This goes mainly in regard to L2-cache performance and other architectural things. However, it's not likely to expect much more memory performance than what we see right now.
