I'm confused... is my sata drive (ata3 below) running at the proper speed? This is a western digital SATA 2 drive. The messages below mention both 3.0Gbps and UDMA/133, which I don't understand.
hdparm -I says udma6 is being used. Testing my old drive, with this new SATA II one shows very similar performance, near 60MB/s (via hdparm -Tt). Is this unusual? I would expect some kind of improvement...
This is an nforce4 chipset, A8N-SLI motherboard. ===========================
ata3: SATA max UDMA/133 cmd 0x9E0 ctl 0xBE2 bmdma 0xC400 irq 225 ata4: SATA max UDMA/133 cmd 0x960 ctl 0xB62 bmdma 0xC408 irq 225 ata3: SATA link up 3.0 Gbps (SStatus 123) ata3: dev 0 cfg 49:2f00 82:746b 83:7f01 84:4023 85:7469 86:3e01 87:4023 88:407f ata3: dev 0 ATA-7, max UDMA/133, 390721968 sectors: LBA48 nv_sata: Primary device added nv_sata: Primary device removed nv_sata: Secondary device added nv_sata: Secondary device removed ata3: dev 0 configured for UDMA/133 scsi2 : sata_nv ata4: SATA link down (SStatus 0) scsi3 : sata_nv Vendor: ATA Model: WDC WD2000JS-55M Rev: 02.0 Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: drive cache: write back sda: sda1 sda2 sda3 sd 2:0:0:0: Attached scsi disk sda
Ivan Gyurdiev wrote:
I'm confused... is my sata drive (ata3 below) running at the proper speed? This is a western digital SATA 2 drive. The messages below mention both 3.0Gbps and UDMA/133, which I don't understand.
You're seeing the similar messages that I do, the controllers seem to be recognised as 3Gb/s but the drives are either reporting or being recognised as 133MB/s
in my case the drives (WDC WD2500KS )are *not* PATA drivers with on-board SATA bridge chips, how about yours?
hdparm -I says udma6 is being used. Testing my old drive, with this new SATA II one shows very similar performance, near 60MB/s (via hdparm -Tt). Is this unusual? I would expect some kind of improvement...
Again that's about the same speed as I get
# hdparm -t -T /dev/sda
/dev/sda: Timing cached reads: 4456 MB in 2.00 seconds = 2229.43 MB/sec Timing buffered disk reads: 180 MB in 3.02 seconds = 59.61 MB/sec
and that seems to be sustained during mdraid rebuilds rather than just on the small test that hdparm.
What does hdparm -T show? If it shows above 1.5Gb/s then at least your physical interface is doing the SATA II speed to the drives,
Not that this is going to improve real world performance much as you already saw the physical disk transfer tops out at 60MB/s which is "only" just over 0.5Gb/s
so in my case the interface between motherboard and disk electronics is 37 times the speed of the interface between disk electronics and disk surface, sata II's 3Gb/s speed is irrelevant, if only I had NCQ that could make a difference ..
You're seeing the similar messages that I do, the controllers seem to be recognised as 3Gb/s but the drives are either reporting or being recognised as 133MB/s
in my case the drives (WDC WD2500KS )are *not* PATA drivers with on-board SATA bridge chips, how about yours?
Well, I think this is a SATA drive.. WDC WD2000JS-55MHB0
hdparm -I says udma6 is being used. Testing my old drive, with this new SATA II one shows very similar performance, near 60MB/s (via hdparm -Tt). Is this unusual? I would expect some kind of improvement...
What does hdparm -T show? If it shows above 1.5Gb/s then at least your physical interface is doing the SATA II speed to the drives,
/dev/sda: Timing cached reads: 2260 MB in 2.00 seconds = 1129.27 MB/sec Timing buffered disk reads: 176 MB in 3.03 seconds = 58.07 MB/sec
/dev/hda: Timing cached reads: 2228 MB in 2.00 seconds = 1113.55 MB/sec Timing buffered disk reads: 176 MB in 3.00 seconds = 58.60 MB/sec
7200 RPM, 8 MB cache. It's nice to know my SATA II drive is so much superior :)
so in my case the interface between motherboard and disk electronics is 37 times the speed of the interface between disk electronics and disk surface, sata II's 3Gb/s speed is irrelevant, if only I had NCQ that could make a difference ..
How does NCQ make a difference? Also, jgarzik's webpage says: "Nvidia has released docs on nforce4 under NDA". Do you know if there's work in progress to implement NCQ for that chipset?
Ivan Gyurdiev wrote:
Well, I think this is a SATA drive.. WDC WD2000JS-55MHB0
Yes, some SATA drives, are re-designed from the PATA drives, incorporating a SATA/PATA bridge on the drive, I think yours is similar to mine, with native SATA
Of course you can also buy external SATA/PATA convertors, but I wasn't expecting you to be using one of those.
It's nice to know my SATA II drive is so much superior :)
If the rpm, number of platters, and data encoding stay the same, so will the performance, broadly speaking, 8MB or 16MB of cache will only have an effect if you're doing reading that fits a certain pattern, and as we've seen the physical disk couldn't even half fill an ATA133 interface (let alone SATA, or SATA II) only cache reads can do that.
How does NCQ make a difference?
It lets the o/s make several read requests to the drive in parallel, then the drive re-orders them according to where it *know* the physical heads are to minimize seek time, and maximize throughput. like SCSI has done for a long time.
Remember they head/cylinder/sector numbers you see from SATA/PATA disks are basically *lies* with LBA so the o/s can't know this.
Also, jgarzik's webpage says: "Nvidia has released docs on nforce4 under NDA". Do you know if there's work in progress to implement NCQ for that chipset?
Sorry I don't have (or know about) nForce chipset, my Intel mobo supports SATA II's 3Gb/s speed, but not the NCQ.
It's nice to know my SATA II drive is so much superior :)
If the rpm, number of platters, and data encoding stay the same, so will the performance, broadly speaking, 8MB or 16MB of cache will only have an effect if you're doing reading that fits a certain pattern, and as we've seen the physical disk couldn't even half fill an ATA133 interface (let alone SATA, or SATA II) only cache reads can do that.
Why are my cache reads so much slower than yours (by a factor of 2)? A friend of mine has SATA I, with 1800 MB/s cached reads, which is also much better.
Ivan Gyurdiev wrote:
Why are my cache reads so much slower than yours (by a factor of 2)?
Either something is making you use SATA I, instead of SATA II, but your dmesg showed 3Gb/s, or perhaps that you have 8MB cache and I have 16MB makes a difference.
A friend of mine has SATA I, with 1800 MB/s cached reads, which is also much better.
I don't see how he can, SATA I = 1.5Gb/s = 1500Mb/s = 150MB/s (after allowing for 8b/10b encoding)
Now I'm scratching my head too, even with SATA II = 3Gb/s = 3000Mb/s = 300MB/s how can hdparm -T show me 2229MB/sec? I though hdparm -T didn't test o/s memory caching, just drive caching?
On Wed, Feb 01, 2006 at 01:35:21PM +0000, Andy Burns wrote:
Now I'm scratching my head too, even with SATA II = 3Gb/s = 3000Mb/s = 300MB/s how can hdparm -T show me 2229MB/sec? I though hdparm -T didn't test o/s memory caching, just drive caching?
It measures cached I/O performance from main memory versus the drive.
Alan
Alan Cox wrote:
It measures cached I/O performance from main memory versus the drive.
Yes thanks, it started to dawn on me that there was a gaping hole in my understanding so I re-read the docs, I thought the difference between -T and -t was disk's cache to mobo, compared to disk's surface to mobo
WRONG!!
Andy Burns wrote:
Now I'm scratching my head too,
OK, having looked at hdparm man page for -T
"This displays the speed of reading directly from the Linux buffer cache without disk access. This measurement is essentially an indication of the throughput of the processor, cache, and memory of the system under test. If the -t flag is also specified, then a correction factor based on the outcome of -T will be incorporated into the result reported for the -t operation."
I always though -T just repeatedly read one sectore from disk's on baord cache repeatedly, clearly I have always been wrong, that is what "-t" does :-(
I thought "-t" read a file large enough to overflow the onboard disk cache, so actually I'm pleased my dmrebuild test does actually give the same speed.
And the difference in your 2228MB/s, my 4456MB/s and your friends 1800MB/s are down to motherboard/cpu/memory, mine is P4 630 with dual DDR2 667MHz
And the difference in your 2228MB/s, my 4456MB/s and your friends 1800MB/s are down to motherboard/cpu/memory, mine is P4 630 with dual DDR2 667MHz
I thought you got 2228MB/s ?
Anyway, let's summarize.
Me: 400Mhz single-channel Kingston 1GB, Athlon64 3700+ 1MB L2, hdparm: 1200 MB/s Friend: 3200 Corsair dual-channel, hdparm: 1800 MB/s you: p4 630 dual ddr2 667Mhz, hdparm: <insert high # here> ===
Hmm... allright. I guess dual channel helps.
It no longer seems like an intelligent idea to remove my PATA drive from the LVM group for reasons of speed, it has exactly the same performance as the other one, and I get extra 80G (and not having to deal with the rescue CD to shrink partitions - which btw doesn't work at the moment)
Ivan Gyurdiev wrote:
I thought you got 2228MB/s ?
You're right, copy and paste error from "4456 MB in 2.00 seconds = 2229.43 MB/sec", 4456MB/s would be truly impressive.
Me: 400Mhz single-channel Kingston 1GB, Athlon64 3700+ 1MB L2, hdparm: 1200 MB/s Friend: 3200 Corsair dual-channel, hdparm: 1800 MB/s you: p4 630 dual ddr2 667Mhz, hdparm: <insert high # here>
yes it was 2228MB/s
and dragoran get 2765.83 MB/s on his AMD64 DDR474
Hmm... allright. I guess dual channel helps.
I should hope so ...
It no longer seems like an intelligent idea to remove my PATA drive from the LVM group for reasons of speed, it has exactly the same performance as the other one, and I get extra 80G (and not having to deal with the rescue CD to shrink partitions - which btw doesn't work at the moment)
Have you tried LVM on RAID0 (if you can stand the loss of reliability) I can't remember the hdparm numbers I got from it, I think it was not quite linear for the uncached part i.e. > 100MB/s, will test again soon.
I think it is also possible to do LVM stripe straight onto the disks, rather than LVM on top of mdraid stripe, but I can't seem to do it in the installer, perhaps that's considered too esoteric for anaconda, and I could manage it if left the space and created the LVM by hand afterwards.
Not sure if there would be a speed advantage by reducing the layering. I will eventually split my 2x250GB drives something like 2x50GB mirrored and 2x200GB striped, to give me a reliable area and a large/fast area.
Ivan Gyurdiev wrote:
It's nice to know my SATA II drive is so much superior :)
If the rpm, number of platters, and data encoding stay the same, so will the performance, broadly speaking, 8MB or 16MB of cache will only have an effect if you're doing reading that fits a certain pattern, and as we've seen the physical disk couldn't even half fill an ATA133 interface (let alone SATA, or SATA II) only cache reads can do that.
Why are my cache reads so much slower than yours (by a factor of 2)? A friend of mine has SATA I, with 1800 MB/s cached reads, which is also much better.
/sbin/hdparm -Tt /dev/sda
/dev/sda: Timing cached reads: 5428 MB in 2.00 seconds = 2713.83 MB/sec Timing buffered disk reads: 174 MB in 3.00 seconds = 58.00 MB/sec ----------------- /sbin/hdparm -Tt /dev/hda
/dev/hda: Timing cached reads: 5532 MB in 2.00 seconds = 2765.83 MB/sec Timing buffered disk reads: 90 MB in 3.01 seconds = 29.92 MB/sec ---- this has more to do with the cpu/memory speed, but nothing with the interface I have a AMD64 with DDR474Mhz Ram and getting the speeds listed above.
-
Alan Cox -
Andy Burns -
dragoran -
Ivan Gyurdiev