6:16 p.m.
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
3:16 a.m.
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 ..
6:22 a.m.
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?
6:54 a.m.
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.
7:06 a.m.
> 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.
7:35 a.m.
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?
7:46 a.m.
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
7:53 a.m.
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!!
7:47 a.m.
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
8:04 a.m.
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)
8:57 a.m.
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.
7:45 a.m.
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.
6680
days inactive
6680
days old
11 comments
4 participants
participants (4)
-
Alan Cox -
Andy Burns -
dragoran -
Ivan Gyurdiev