On Sun, 19 Dec 1999 15:22:07 +0200 (IST), you wrote:
>Udi Finkelstein <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 17 Dec 1999 01:51:54 +0200 (IST), Evgeny Stambulchik
>> <[EMAIL PROTECTED]> wrote:
>>
>> > As far as performance is considered, it's not RPM that usually matters
>> > (inspite of a big hype), but the amount of cache on disk. Until
>> > recently (1-2 years), the maximum cache on IDE disks was 128KB, while
>> > about each SCSI disk had 0.5MB.
>>
>> I would speculate that all the on-disk cache you need is two full
>> cylinder's worth of data.
>>
>> You want at least one cylinder's worth of data so you can read it all in
>> one round, and really want two so you can read the next one while your
>> buffers are still being transferred to the PC.
>
>Applying this logics to RAM would suggest that level-2 cache should be just
>twice as big as level-1 and the latter shouldn't exceed the doubled total
>storage value of CPU registers. Actually, saying a fixed amount "is enough"
>means there is no sense in multi-level caches at all.
Nope. your example falls for a basic mistake. L1, L2 are *caches* for the main
memory. The disk buffer calculation I did was for a disk **buffer**. caches
were meant to exploit the "the 80/20 rule" (AKA "Parto's rule" IIRC), while
buffers were simply meant to balance between different channels with different
peak/sustained transfer speeds. cache access pattern is pretty random (you
gets different bits and pieces of it hit every time), while a buffer basically
behaves as a FIFO.
>> I have a hunch that with a computer fast enough, anything over 2 cylinder's
>> worth of data will offer near zero improvement. After all, the system cache
>> is more efficient than going to the drive and pulling data from the HD
>> cache, so the HD cache can only help you if it lets you stream the data at
>> the maximum possible speed (one rotation for each full cylinder).
>
>The above reasonings are good, but you're silently assuming the OS has nothing
>to do except writing/reading from the disk; moreover, from the _single_ disk.
>It's definitely wrong in the multi-task OS's like Linux/Unix. I'd call your
>estimate a "minimal reasonable value".
I stand corrected. Using buffers larger than one or two cylinders allows you
to "empty" the disk buffers less frequently, and reduce the interrupt load on
your server. As you wrote above, when you use multiple disks, this can help.
>> The problem is that it's hard for us customers to really estimate how much
>> cache is really in these drives (in terms of number of cylinders), since
>> the numbers of cylinders pronted on the disk label has nothing to do with
>> the actual number of physical cylinders it has.
>
>?? It's a news for me. Anyway, what you're interested in is the amount of data
>read in contiguously during one disk revolution, a ratio between (contiguous)
>I/O read/write data access rate and RPM. This value is actually a function of
>HD technology, and is pretty constant over the whole range of disks, both IDE
>and SCSI, present today: with access rate ~8-10MB/s for 5400 RPM disks and
>~13-15MB/s for 7200 RPM models, one gets ~100KB per disk revolution. Hence,
>the minimal resonable amount of cache should be ~200KB, something that not all
>currently available IDE disks exceed (and about none 1-2 years ago), while
>0.5MB for SCSI disks has been a usual thing for years; many high-profile SCSI
>disks can be (optionally) supplied with either 2 or 4MB - don't expect to
>easily find them in Israel, though :)
Again, I stand corrected. (why the hell didn't I think of the simple
calculation above??)
>Regards,
>
>Evgeny
Udi
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
