IBM 75GXP weird performance - write cahce problem?

  • Thread starter Thread starter davexnet02
  • Start date Start date
D

davexnet02

Hello all,
I noticed one type of operation where the performance
is very low, it occurs when reading and writing lots of data
simultaneously.
For example, I had a RAR archive of a 235MB avi file.
Extracting the archive from and to this drive took
1 minute 46.
I copied the RAR files to a second drive, a Maxtor 53073h4
and repeated the test, it took 60 seconds.

I used the IBM feature tool utility and disabled the
write cache. Repeating the test above in this
condition, it still took 1 minute 46.

Write cache non-operative?


Dave
 
davexnet02 said:
Hello all,
I noticed one type of operation where the performance
is very low, it occurs when reading and writing lots of data
simultaneously.
For example, I had a RAR archive of a 235MB avi file.
Extracting the archive from and to this drive took
1 minute 46.
I copied the RAR files to a second drive, a Maxtor 53073h4
and repeated the test, it took 60 seconds.

I used the IBM feature tool utility and disabled the
write cache. Repeating the test above in this
condition, it still took 1 minute 46.

Write cache non-operative?

2MB cache, 40MB/s transfer rate, or write cache filled in 1/40 second.
Gee, on a 1 minute 46 sec operation how much difference do you think that
will make?
 
2MB cache, 40MB/s transfer rate, or write cache filled in 1/40 second.
Gee, on a 1 minute 46 sec operation how much difference do you think that
will make?
Obviously I had no idea. If it really works as you describe,
I can see not much at all.
Since most HD accesses in a typical desktop scenario are pretty
small reads and writes, then what's the point of the cache at all?

However, if some of the problem is to do with timing, and the
cache having an effect of smoothing out the operation,
the benefit could be greater than the sum of the parts.
OR so I thought.


Dave
 
davexnet02 said:
Obviously I had no idea.
If it really works as you describe, I can see not much at all.
Since most HD accesses in a typical desktop scenario are pretty
small reads and writes, then what's the point of the cache at all?

1. Being just that: cache.
2. Being an extension to the buffer so that several commands can be queued.
However, if some of the problem is to do with timing, and the
cache having an effect of smoothing out the operation,

It probably does somewhat do that but it may be only noticable on pure
sequential operations.
And do note that the buffer is already 128 kB and may take more than one
command of less than 128 kB transfer size.
 
Back
Top