# RAM latencies, hard drive speeds, and FSB - some questions

## Dralnu

Alright. I'm staring at some RAM. I know the latency means something, but my memory isn't what is used to be. Lower the number, the better, right?

FSB - from what I've been able to gather, its more or less a placebo effect from one to another, though with some of it there is a fairly good-sized jump with speed.

And for the biggie: Hard drives.

From what I've been looking into, SATA 3Gb/s is the connection to use, but what would the speed diffrence be between, say, a 7200 RPM w/ SATA 3Gb/s, or would a 10K RPM on an IDE cable be faster?

From a seek standpoint, the 10k would be faster, but transfer is faster on the SATA.

Well?

----------

## barophobia

Sustained, non-cached,  transfer speed should favor the 10Krpm hard drive.  If you hit the hdd cache then the sata drive will be faster.

Lower latency in memory means cpu has to waits less when it cache misses.

FSB - i don't know.

Performance measurements are not very straight forward, it all depends on what you want to do.

----------

## Dralnu

Hrm. Which brings up the next question: How often does one hit cache when running their system, or how does one find out what kind of patterns will cause such to happen.

----------

## barophobia

Every component has its own cache replacement policy and how they cache things.  There is always that one pattern that causes tons of cache misses for every replacement policy.  I think the Intel core2 chips have some insanely strange and complex cache replacement policy i am not too sure, not really a hardware guru.  This is partly why I do not trust system benchmarks all that well.  I also believe there are lots of academic publications written about cache replacement policies and when they fail.

Oh and more complications to the hdd i forgot to write.

NCQ -> small writes will be "written" faster with the sata drive since all that has to happen is transfer to hdd cache the hdd say "ok it is written" then go write it later

----------

## eccerr0r

Also you have to compare recent disks.  I've seen some older 10K disks with slower transfer rates than "modern" 7200 RPM disks - however, seek rate of the 10K disks are still better than of the 7200'ers.

The SATA 3Gb/sec is merely transfer from the HD unit to the machine.  Being able to read off the platters that fast is something else - and no disk can read off the disk that fast yet.

FSB speed is weird.  It puts an upper bound as how much data you can transfer to/from the CPU.  However due to recent "fixed multipliers" FSB speed may have a direct implication as to how fast the CPU can run too.  Higher the better in general.  Some even more recent CPUs can decouple FSB and core CPU speeds.

----------

## Dralnu

Hrm. That definatly doesn't make things any simpler.

Could you possibly point me towards one of those papers, or would that be a bit much for trying to pick a good hard drive for a new box?

----------

## NeddySeagoon

Dralnu,

For small read/writes, less than the on drive cache, data can be stored/served from the cache at the drive to motherboard data link speed or the motherboard to main memory speed, whichever is less. 

For larger accesses, the data rate limit is the head/platter data rate, since there is no possibility to get all the data into cache.

Those are the main considerations.

```
hdparam -tT
```

 shows these two data rates

The latency of a HDD is related to the rotational speed and the track stepper. If the data you want has just gone past the head, you have to wait for the drive to rotate once to be able to read it, therefore faster drives are better. (On average, you wait 1/2 a rev)

If the data you need is on another track, you have to wait the time to move the head too.

Lastly, there is Native Command Queuing on some SATA chipsets now (requires kernel support). This feature reduces latency by allowing commands to be executed out of order to minimise head movement. Overall, it increases the useful time spend transferring data but at the expense of delaying some requests. Averaged out, its a good thing. It only makes a real difference when a drive is busy

----------

## barophobia

I think this whole analyzing cache his and miss things at this level is not useful for normal users (99.9999999% of users) that remaining fraction includes computers (read embedded systems) that only does one thing like the ones controlling the Mars rovers.

And besides linux caches hard drive writes in main memory anyways so it really does not make much of a difference just get a sata with 16mb of cache ,i think is todays standard.

On a side note i can think of a situation that a non-raided set of hdds will out preform raided ones.

Lets say you have millions of small files, and lots of processes accessing these files randomly, all at the same time.

the non-raided set of hard drives has a chance of retrieving N files at the same time (say you have N hdds).  While the raided system has to serve these files one at a time, paying the seek time between these accesses.  

so you have these time expectations

raided = F*(S+R/N)

non-raided = F/N * (S+R)

F is the number of files to be accessed, N the number of hdds you have, S seek time, R file access time for one hdd.

We are assuming that the raided system stripes the file across all hdds.  Since we are dealing with small files R will be much smaller than S.

edit: 

Probably the reason why old 10krpm drives are slower than modern ones is because of the bit density on modern hdds are much higher so more bits fly under the read head even at 7200rpm.

----------

## Dralnu

So, what I've gotten here is, that ultimatly there is no single good choice. I'm still leaning towards a 10K RPM drive (I'll google up something to see if there is a 10K SATA 3Gb/s. If there is...) since A) It doesn't seem a 3Gb/s transfer is going to do me that much good if the drive isn't running all the time, and from what I can figure, you could drain out the cache on the drive using such on a long write, meaning you are limited to the speed of the drive (correct me there if I'm wrong), and B) Without knowing if the data will be set in one place on the drive, the lower seek latency might speed things up. If it hits cache, it will be the slower of the two, but if it doesn't, then the speed should be faster.

Am I even remotely close?

----------

## barophobia

Yes once you drain the cache you will be limited to the speed you can write to the platters.

Oh yeah no one uses ata interfaces anymore.

Basically if you are really worried about the seek times and transfer rates then get a 10krpm sata drive from western digital.  It should be able to faster than your 7200rpm sata drives.

----------

## NeddySeagoon

Dralnu,

Your summary is pretty good.

Thats the thing about optimisation - its better under most conditions, best under a small number of conditions and maybe worse under some too.

You have to choose the parameters that are important to you and optimise them, that varies from application to application and with load level too.

----------

## Dralnu

Alright, 10K drive it is. I'll hunt down one with an sata interface and all that.

Thanks for the input.

Maybe this should be moved to DT&T? Might be worth someone some other time..

----------

