FIRST LOOK: ULi M1697 for Athlon 64/x2
by Wesley Fink on December 13, 2005 12:05 AM EST- Posted in
- CPUs
USB Performance
USB 2.0 performance has been a problem area for some chipsets, so benchmarks were run to test USB performance of the new ULi M1697. We ran our standard USB throughput test on the ULi M1697 using an external USB hard drive.
Our test method uses a RAM disk as our “server”, since memory removes almost all overhead from the serving end. We also turn off disk caching on the USB and Firewire side by setting up the drives for “quick disconnect”. Our results are then consistent over many test runs.
We use just 1GB of fast 2-2-2 system memory, set up as a 450MB RAM disk and 550MB of system memory. Our stock file is the SPECviewPerf 8.01 install file, which is 432,533,504 bytes (412.4961MB). After copying this file to our RAM disk, we measure the time for writing from the RAM disk to our external USB 2.0 or Firewire 400 or Firewire 800 drive using a Windows timing program written for AnandTech by our own Jason Clark. The copy times in seconds are then converted into Megabits per second (Mb) to provide a convenient means of comparing throughput. Higher Rates, therefore, mean better performance.
Disk Controller Performance
With the variety of disk drive benchmarks available, we needed a means of comparing the true performance of the wide selection of controllers. The logical choice was Anand's storage benchmark first described in Q2 2004 Desktop Hard Drive Comparison: WD Raptor vs the World . To refresh your memory, the iPeak test was designed to measure "pure" hard disk performance. The hard drive was kept as consistent as possible while varying the hard drive controller. The idea is to measure the performance of a hard drive controller with a consistent hard drive.
We played back raw files that recorded I/O operations when running a real world benchmark - the entire Winstone 2004 suite. Intel's iPEAK utility was then used to play back the trace file of all IO operations that took place during a single run of Business Winstone 2004 and MCC Winstone 2004. The drive was formatted before each test run and a composite average of 5 tests on each controller interface was tabulated in order to ensure consistency in the benchmark.
iPeak gives a mean service time in milliseconds; in other words, the average time that each drive took to fulfill each IO operation. In order to make the data more understandable, we report the scores as an average number of IO operations per second so that higher scores translate into better performance. This number is meaningless as far as hard disk performance is concerned, since it is just the number of IO operations completed in a second. However, the scores are useful for comparing "pure" performance of the storage controllers in this case.
USB 2.0 performance has been a problem area for some chipsets, so benchmarks were run to test USB performance of the new ULi M1697. We ran our standard USB throughput test on the ULi M1697 using an external USB hard drive.
Our test method uses a RAM disk as our “server”, since memory removes almost all overhead from the serving end. We also turn off disk caching on the USB and Firewire side by setting up the drives for “quick disconnect”. Our results are then consistent over many test runs.
We use just 1GB of fast 2-2-2 system memory, set up as a 450MB RAM disk and 550MB of system memory. Our stock file is the SPECviewPerf 8.01 install file, which is 432,533,504 bytes (412.4961MB). After copying this file to our RAM disk, we measure the time for writing from the RAM disk to our external USB 2.0 or Firewire 400 or Firewire 800 drive using a Windows timing program written for AnandTech by our own Jason Clark. The copy times in seconds are then converted into Megabits per second (Mb) to provide a convenient means of comparing throughput. Higher Rates, therefore, mean better performance.
Disk Controller Performance
With the variety of disk drive benchmarks available, we needed a means of comparing the true performance of the wide selection of controllers. The logical choice was Anand's storage benchmark first described in Q2 2004 Desktop Hard Drive Comparison: WD Raptor vs the World . To refresh your memory, the iPeak test was designed to measure "pure" hard disk performance. The hard drive was kept as consistent as possible while varying the hard drive controller. The idea is to measure the performance of a hard drive controller with a consistent hard drive.
We played back raw files that recorded I/O operations when running a real world benchmark - the entire Winstone 2004 suite. Intel's iPEAK utility was then used to play back the trace file of all IO operations that took place during a single run of Business Winstone 2004 and MCC Winstone 2004. The drive was formatted before each test run and a composite average of 5 tests on each controller interface was tabulated in order to ensure consistency in the benchmark.
iPeak gives a mean service time in milliseconds; in other words, the average time that each drive took to fulfill each IO operation. In order to make the data more understandable, we report the scores as an average number of IO operations per second so that higher scores translate into better performance. This number is meaningless as far as hard disk performance is concerned, since it is just the number of IO operations completed in a second. However, the scores are useful for comparing "pure" performance of the storage controllers in this case.
Facebook
Twitter
RSS
51 Comments
View All Comments
Scarceas - Thursday, December 15, 2005 - link
I presumed that ULI provided Anandtech with the sample to review... if you think about it, there are some wierd angles on that... A big deal like that isn't hammered out in a couple of days. ULI "brass" knew the sale was coming.It's kind of wierd, IMO, to send out stuff for reviews as you're going under.
I suspect that nVidia will sit on any tech they acquire, and not implement it. I was sorely disappointed that they sat on the GigaPixel technology a few years back, and there was of course more from the 3dfx acquisition that they never implemented.
IRQ Conflict - Wednesday, December 14, 2005 - link
Too bad this chipset is doomed before it even gets implemented LOL!http://www.nvidia.com/object/IO_28250.html">LinkPuddleglum - Wednesday, December 14, 2005 - link
https://www.nvidia.com/object/IO_28250.html">https://www.nvidia.com/object/IO_28250.htmlTorched - Wednesday, December 14, 2005 - link
Bad link on above post. You can read about Nvidia buying out ULi http://www.theinquirer.net/?article=28333">hereIRQ Conflict - Wednesday, December 14, 2005 - link
wierd, it was working yesterday? Oh well nVidia's following M$'s lead again. I can still smell the embers of the 3dfx acquasition.Peter - Tuesday, December 13, 2005 - link
And yet again, we're seeing Anandtech experts (?) evaluate the RAM controller properties of an AMD64 chipset.Hello?
The RAM controller is in the CPU, folks. Time to acknowledge that and skip that step in a chipset review.
Puddleglum - Wednesday, December 14, 2005 - link
Peter, this is what you were referencing:I don't see the words "controller" or "chipset" in there, and yet you say that the article evaluates the RAM controller properties of the chipsets. What he said about the lack of memory voltage adjustments was not referencing the chipset, but the method that Anandtech uses to overclock their boards.How did you come to think that the article mentioned the RAM controller?
Peter - Thursday, December 15, 2005 - link
I'm referring to the following statements on page 4:>Memory Stress Testing: Since this is a new chipset, the best setting for tRAS was first determined.
>This means that any setting from 6 to 11 tRAS will work well with this chipset.
>*7T was determined by MemTest86 benchmarks to deliver the widest bandwidth with the ULi M1697 chipset.
For anyone who's looked at the block diagram on page 2, it should be bleeding obvious that the RAM isn't the chipset's business at all.
Cygni - Tuesday, December 13, 2005 - link
Uhhhhh... havent used many A64 boards lately? ;) The ability to run low latency timings is very highly regulated by the board and chipset. You cant just drop any stick of ram in any board and get identical timings.The memory controller may be on the chip itself, but this doesnt eliminate the board and chipset from the equation whatsoever.
Peter - Wednesday, December 14, 2005 - link
AMD64 architecture totally eliminates the chipset from anything that is even remotely to do with the RAM bus. That's the point, and you're not getting it either.