facebook rss twitter

Review: ABIT SR7-8X SiS648 Motherboard

by Tarinder Sandhu on 6 September 2002, 00:00

Tags: abit

Quick Link: HEXUS.net/qams

Add to My Vault: x

Benchmarks I

Starting off with SiSoft SANDRA's memory benchmark. Although not a perfect indicator of potential performance, it does give us some insight into how well the memory controller is functioning

Faster memory speeds equate to higher benchmark scores. Running the system memory at DDR-400, whilst the CPU is set at 133FSB, gives us almost 3GB/s of potential bandwidth. How does this increased bandwidth translate into real-world performance ?, let's run Pifast and find out. Pifast simply calculates the constant Pi to a set number of decimal places. A fast FPU and oodles of bandwidth are the drivers here. I've chosen 10 million decimal places as a benchmark.

A faster memory bus is able to cram in more data to the quad-pumped, bandwidth-starved Pentium 4. The fact that I had to use slightly relaxed timings, at DDR-400, stops it from gaining an even greater advantage in this test.

Next we'll turn our attention to MP3 encoding. We're benchmarking by encoding a 638MB custom WAV file (Moby's Play album, incidentally) into 192kb/s MP3 using the LAME 3.92 encoder and Razor-Lame 1.15 front-end.

WAV - MP3 encoding is seemingly oblivious to increases in bandwidth. Sheer MHz count here.

I'm now using a quality-driven approach for my DVD-to-DivX crunching. 2-pass encoding via VirtualDub. Three Kings is the DVD of choice, resized to 720x304, precise bilinear and black borders cropped. YUV2 spacing is used and the bit rate is set to 1700 kbps. I encode a 15-minute section and calculate the average fps from there. DivX 4.12 is still my CODEC of choice for benchmarking purposes.

I'm a little disappointed that the SR7-8X could not pull out a larger lead over the IT7 in this test. I also have to note that the SR7-8X crashed twice whilst running this test at DDR-400. I'm not entirely sure why this was, but I've got a feeling that the memory speed of DDR-400 was to blame.