IDE: 8 MB vs 16 MB cache

IDE: 8 MB vs 16 MB cache

Post by dbmethod » Thu, 07 Sep 2006 10:22:36


Any real benefits of 16 MB cache buffer for IDE hard drive on a 5-year
old Win/Linux PC.

Thanks
 
 
 

IDE: 8 MB vs 16 MB cache

Post by larry moe » Thu, 07 Sep 2006 17:48:53


You save money? At least that was the case with the $100 Labor Day
deal for 400GB Seagates.

Somebody said that the 16MB cache gave 2-5% better speed on benchmarks.
Years ago, PC World or PC Magazine said going from a 2MB to 8MB cache
gave about 15% better overall speed.

 
 
 

IDE: 8 MB vs 16 MB cache

Post by Arno Wagne » Thu, 07 Sep 2006 19:33:06


Not really.

Arno
 
 
 

IDE: 8 MB vs 16 MB cache

Post by timeOda » Sat, 09 Sep 2006 01:46:44


Even that, I think, would depend a lot on the benchmark used. If you
specifically do a disk benchmark, which purposely avoids the filesystem
cache maintained by the OS in main memory, you'll see a big benefit from
on-disk cache. But I don't think that's very relevant to the real world.
 
 
 

IDE: 8 MB vs 16 MB cache

Post by Folkert Ri » Sat, 09 Sep 2006 02:28:11


Which would be just a simple STR benchmark.


Not with just a simple STR benchmark.

The c't benchmark makes an attempt to measure the affect that the reading
ahead feature of drive caches have by inserting pauses between accesses
and by doing random reads within certain bands.


Depends on your applications.
 
 
 

IDE: 8 MB vs 16 MB cache

Post by Arno Wagne » Sat, 09 Sep 2006 10:20:01


With custom-tailored benchmarks you could see up ro 100% speed
improvement. In practice it may be closer to 0%...1%.

Arno
 
 
 

IDE: 8 MB vs 16 MB cache

Post by Folkert Ri » Sun, 10 Sep 2006 06:05:51


Utterly clueless babble, as always from babblebot.
There is no such thing as a 100% speed improvement ceiling.
It may be any value, depending on what the burst speed of your interface is,
including more than 100%.


The only thing that you can say about it with some degree of certainty
is that it is likely twice the benefit that you get from 8MB cache.

Could be twice the number of cache segments or the same number of segments
twice as big or anything in between.