300MB SATA

[Jimshady]

I often hear people at school having a cry about how 300MB SATA will have zero effect on a computers performance.

I understand that the bus is not the bottleneck, but with HDDs with larger cache, like 16MB, wouldn't there be a reasonable cache-hit ratio? If so, then peek bus-throughput is not necessarily proportional to the rotational speed (or should I say mean seek time with NCQ and all). So there may just be times when more than 150MB of bandwidth could be required? Less suspended threads, more responsive computer, makes sence to me.

Or because of the natured of secondry storage transactions, are disk-buffer read hits not a frequent enough thing to sustain high throughput with an HDD?

PS if I sound incoherent, I've been up for a long time :/ Need bed!

 

[jtr1962]

IIRC Storage Review actually did find a measureably performance increase between drives with 8MB cache versus the same drive with 2 MB cache, so your theory is certainly plausible. If there are regularly a large number of cache hits, then a faster interface should result in better performance. The difference, in real world terms, will probably only be on the order of a few percent. Also, past a point more cache doesn't necessarily result in any better performance, all other things being equal. It can be argued that 16MB cache is good anyway because it doesn't cost much more, and in time software will probably be bloated enough for there to be a noticeable difference between 8MB and 16MB cache.

BTW, welcome to StorageForum! 8)

 

[Adcadet]

because STR doesn't affect the performance of the vast majority of desktop computers.

 

[Handruin]

I wonder, is it possible to synthetically test his theory? Is there a way we can simulate a cache hit consistently, or is it not possible unless we write some type of device driver? Meaning, can we try to read data with and without cache to see the speed difference, and then try different sizes of data to see if there are burst equivalent to that of the theoretical bus speed limits?

 

[Jimshady]

I guess it all comes down to the effect a HDD cache size increase has on the cache hit-ratio. Do we see much locality occur in secondary data transfers? I don't know. I understand that a nice sized buffer will smooth out writing to an HDD, keeping processes in the ready state more often. So writing is one instance where a wider bus would help (a little bit, and not for sustained writes), and there wouldn't be any real advantage for sustained, or uncached reads. Just sustained cached reads. But what programmer writes a program that needs to read the same data more than once.

I can think of a scenario where the cache hit would be large, but it's so far-fetched, and wouldn't apply to 99.99% of computer users. With virtual memory pages that are constantly being paged in and out. You would have to have very little memory, and many ready processes, however, for that to work.

I don't know, not worth loosing sleep over, I think.

 

[Adcadet]

my privious post made no sense - sorry.

Didn't SR show that most cache hits involve small files? If this is the case, I would think latency would be a big issue, which in this case wouldn't require the drive to go to a platter for data. The time savings between 150 MB/s vs. 300 MB/s might mean almost nothing if the file in question being transfered is tiny and the delay to begin the transfer is relatively large.