Todd Simi wrote:
Hi,
I know this may be a silly question since it probably a hardware limitation,
but I'm running F7 and would like to know what I can do to increase the hard
drive seek time, if anything.
I have a pretty new SATA drive at 3GB/sec and it seems to have to seek longer
than I'd expect.
It's running with DMA4, AHCI, etc.
The rest is an ASUS MB with a Core 2 Duo 6400 @ 2.4 Mhz & 2GB Ram @ 800Mhz.
Are there any setting from the standard that by help?
here's the hdparm output
[root@localhost ~]# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 8608 MB in 2.00 seconds = 4313.28 MB/sec
Timing buffered disk reads: 202 MB in 3.02 seconds = 66.79 MB/sec
[root@localhost ~]# hdparm -tTacdiIMpQ /dev/sda
/dev/sda:
IO_support = 0 (default 16-bit)
readahead = 256 (on)
Model=ST3250620NS , FwRev=3.AEG , SerialNo= 9QE2230L
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7
* signifies the current active mode
ATA device, with non-removable media
Model Number: ST3250620NS
Serial Number: 9QE2230L
Firmware Revision: 3.AEG
Standards:
Supported: 7 6 5 4
Likely used: 7
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors: 16514064
LBA user addressable sectors: 268435455
LBA48 user addressable sectors: 488397168
device size with M = 1024*1024: 238475 MBytes
device size with M = 1000*1000: 250059 MBytes (250 GB)
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: unknown setting (0xfefe)
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
* Write cache
* Look-ahead
* Host Protected Area feature set
* WRITE_BUFFER command
* READ_BUFFER command
* DOWNLOAD_MICROCODE
* Advanced Power Management feature set
SET_MAX security extension
* 48-bit Address feature set
* Device Configuration Overlay feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
64-bit World wide name
unknown 84[11]
unknown 84[12]
* SATA-I signaling speed (1.5Gb/s)
* SATA-II signaling speed (3.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
Device-initiated interface power management
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT LBA Segment Access (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
not supported: enhanced erase
Checksum: correct
HDIO_GET_ACOUSTIC failed: Inappropriate ioctl for device
Timing cached reads: 4502 MB in 2.00 seconds = 2252.78 MB/sec
Timing buffered disk reads: 38 MB in 3.08 seconds = 12.35 MB/sec
Thanks
Todd
Hard drives have 2 main metrics when it comes to speed: throughput and
seek time. Throughput is the speed of reading/writing a large contiguous
file. Seek time is the delay while your hd is "seeking" for the next
piece of data (presumably in a different physical location on the drive).
3GB is a rating of the SATA bus, in essence how fast data *could* be
transferred from the drive, if the drive made that data available. Since
every drive nowadays has a cache built in (8-16mb usually), reading from
cache can probably go at 3GB (or speed of the cache, whichever is lower)
- but that's only the 8-16mb that has recently been accessed. If you
want to read a file your HD hasn't read recently, it has to seek, then
read it.
Here's where the paths differentiate: some users need high throughput,
and some need fast seek times. If you use the HD for storing a lot of
small files, e.g. Squid cache, then seek times are more important.
Otherwise (reading/writing large files) - throughput is more important.
There isn't really any way of improving the speed of a SATA drive - they
should run at top speed already. If you used IDE drive, there might've
been some settings to tweak for maximum throughput - but with SATA those
are moot (and no, IDE is not faster than SATA :)
Depending on how much more performance you need, you can check out:
* alternate filesystems. They're usually well-suited for a particular
way of operation (e.g. lots of small files) and are average on all other
tasks. Degree of improvement isn't very high - and highly depends on
usage patterns - feel lucky if you get 10%. The only cost here is time
to implement and maintain the system.
* high-end HDs, e.g. 10,000+ RPM. These can improve your performance
somewhat, in the range of 10-20% - but it stacks on top of performance
gain of alternate filesystems. This is probably the cheapest upgrade path.
* solid state HDs. These have no moving parts, and thus the seek times
should be 0 (or very close to it). Don't know about the throughput.. in
theory it should be higher than traditional HDs, but in practice...
dunno, go read reviews :) Since it's a new technology, these are still
pretty expensive. Oh, and I doubt the speedup will add up with alternate
filesystems.
* if you want to go all out, try getting a RAM drive. You insert
standard computer RAM into it and your computer sees it as an HD. Very
fast and very expensive (cost of RAM)
HTH
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
