Hi Dimitris, I have seen the same patterns - but I don't think it's reflecting normal workload - so don't be alarmed. :-)
1) You are comparing an Intel and a AMD processor accessing memory. Intel's Core-processors (and Intel in general) have always performed were well in this hdparm memory-tests. I don't know why.. but that's the case (Maybe because of there releatively large second level cache 4MB for Core2-duo) - compared to AMD that typically still runs with 512KB / 1MB. When it comes to real life usage the the difference is not that big. AMD is very fast on context-switching. 2) I believe that this is syncronous reads.. The raptor disk is very fast in random reads as it has a low accesstimes. The bigger and slower disk may most likely have higher data- density - resulting in a high troughput anyway - as long as we are only reading one file at a time.. If you compare random reads/writes between the disk you get what you payed for.. My data from a Laptop with Core2 Duo T7200 @ 2.0GHz and a 100GB 7200 2,3" drive is: /dev/sda: Timing cached reads: 5384 MB in 2.00 seconds = 2697.96 MB/sec Timing buffered disk reads: 150 MB in 3.04 seconds = 49.41 MB/sec /Johan On Tue, 2007-03-20 at 14:17 +0100, Dimitris Lampridis wrote: > Hi everybody, > > although the following question is not debian-specific ( at least I > hope so ), I'm posting it here, betting on the 64-bit architecture > knowledge of the list. > > I have two 64-bit systems, both running Debian testing. One is a Core2 > Duo [EMAIL PROTECTED], running a 32-bit Debian, the other is an AMD dual > core 3800+ desktop computer, running 64-bit Debian. > > I'm benchmarking both systems and I've run "hdparm -tT" on both. Now, > the laptop has a typical laptop disk, namely a TOSHIBA MK1234GSX. The > desktop on the other hand, has two Western Digital Raptors, 80G each, > in software RAID0, and a slower/bigger typical desktop disk, namely a > Seagate ST3160812AS, that is sitting outside the RAID configuration. > > The outputs of "hdparm -tT" are as follows: > > ----------------------------------------------------------------------------------------------------------- > 1 - LAPTOP: > /dev/sda: > Timing cached reads: 5788 MB in 1.99 seconds = 2901.82 MB/sec > Timing buffered disk reads: 102 MB in 3.02 seconds = 33.78 MB/sec > > 2 - DESKTOP WD raptors in RAID0 (root partition): > /dev/md2: > Timing cached reads: 1920 MB in 2.00 seconds = 960.95 MB/sec > Timing buffered disk reads: 410 MB in 3.01 seconds = 136.14 MB/sec > > 3 - DESKTOP single WD raptor: > /dev/sdb: > Timing cached reads: 1938 MB in 2.00 seconds = 969.44 MB/sec > Timing buffered disk reads: 206 MB in 3.02 seconds = 68.24 MB/sec > > 4 - DESKTOP single Seagate: > /dev/sda: > Timing cached reads: 1926 MB in 2.00 seconds = 963.75 MB/sec > Timing buffered disk reads: 208 MB in 3.01 seconds = 69.02 MB/sec > ----------------------------------------------------------------------------------------------------------- > > > Now, off to the questions: > b > 1) Why are cached reads on the Laptop so much faster (case 1 vs. 2,3 > and 4)??? The laptop has 1G of memory (probably a cheap one as well, > to keep the cost low), the desktop has 2G of memory, fastest one my > money could buy... > > 2) Shouldn't the "notorious" WD raptor greatly outperform the Seagate > when comparing single disk performance (case 3 vs. 4)? After all, the > WD costs 2 times the price of the Seagate (or was it even more..?). > > There seems to be some kind of limiting factor/bottleneck on my > desktop that is restricting performance. I don't believe there's such > a big difference (in terms of performance) between the Intel Core Duo > and the AMD dual core architectures, capable of yielding such results > (3x faster in cached reads), especially when we're talking about a > "power-sensitive" laptop versus a mighty data-crunching desktop > machine. > > btw. I found out that I cannot set any HD parameters from within > hdparm, for both systems. It always fails with the message: > Inappropriate ioctl for device > > so the Serial ATA drivers don't have the relevant ioctl() calls > implemented? or maybe i'm missing something here... > > Thank you all for your time, and if you feel this is out of > topic, plz. let me know and I will post somewhere else. > > Dimitris > >
