Is 8MB cache better than 2MB?

Napoleon · Sep 9, 2002

Hi, ncogneto and all.

Thought I'd put in a dedicated thread so we can analyze <A HREF="http://forumz.tomshardware.com/hardware/modules.php?name=Forums&file=viewtopic&p=56278#56278" target="_new">this</A> until nausea overcomes us all.

Just for reminder, I'll start with some quotes (kudos to ncogneto):

Look I understand all that. I don't even disagree. Yes the JB is faster than some of the drives you mention at some if not nearly all tasks. Once and for all that is not the debate!

To clarify yet again the issue is not that the JB out benches the BB the issue is why. As you and others seem to suggest the reason is the additional cache. And pardon me for sounding sarcastic, but no-one has yet to offer any logical sound reasoning as to why. Would I recomend the JB over the BB...YES! Would I be so bold to say that the reason it does outperform the BB is just the cache? NO!

Let's get started, then. First off, I love sarcasm/irony, both given and received. However, IMO quote-based sarcasm is at it's best when one can quote a minimum of four consecutive sentences and point out how totally clueless they are. That's not to say that what I just quoted is clueless, just that I'm about to get highly speculative without having any kind of hard facts for backup. So I'll expect to see some truly hilarious quotes. Take your best shot!

Okay, <A HREF="http://www.wdc.com/products/Products.asp?DriveID=27" target="_new">here</A> is what I'm basing my assumptions about WD1200JB on. If there's 234,441,648 user sectors on the drive and 16,383 cylinders (assuming that the given cylinder number reflects the real mechanics of the drive), average capacity per cylinder would be 234,441,648*0.5kB / 16383 cylinder = 7MB / cylinder. Since there are three platters (6 heads), average capacity per head would be 1.17MB.

So, let's make a wild assumption that the WD1200JB is designed so that all the 6 heads are used in parallel during single rotation, kinda like internal RAID. If so, sustained internal transfer rate could be as high as 7MB / 8.4ms = 833MB/s (60s / 7200rpm = 8.4E-3s / rotation). If that truly is the case, >7MB internal buffer would be a must to achieve that 833MB/s internal transfer rate. Unfortunately, even SATA speed (150MB/s) would be saturated by 833MB/s dataflow from the platters, so the 8MB cache would be more of a rotation buffer than real cache. But 8MB would still be a must, because missing one rotation would shred the external transfer rate to pieces due to rotation latency (8.4ms).

Again, all this jibes quite nicely with 133MHz SDRAM burst rates when using 64-bit bus (133MHz * 8bytes = 1064MB/s). Or 133MHz DDR with 32bit-bus. Still, cache latencies (caused by memory latencies and cache algorithm latencies) would come into play. Most 7200rpm drives boast some 450-600MB/s internal transfer rate. Judging by that, I suspect that the good old sector interleave has snuck back in to the hard drives. For example, 1-way sector interleave would drop the dataflow from platters to 416MB/s in my JB assumption. Hence, 500-600MB/s internal transfer rate would suffice, so there would be some 500MB/s worth of latency time for adding some clever tricks to the caching firmware.

As for the el-cheapo WD1200BB case, let's assume that the heads are not used in parallel. With that assumption, you'd get 1.17MB / 8.4ms = 139MB/s data rate from the platters at 7200rpm. Comparing against 450-600MB/s internal transfer rate, there's plenty of latency time to figure out how to best eliminate the external speed bottlenecks (100MBps, 128MBps PCI bus, 133MBps, 150MBps, asf). Having a spare 2MB - 1.17MB = 0.83MB cache memory helps a lot too, I bet.

Considering the HD zoning and the fact that external tran speed is approximately halved at the inside cylinders vs outside cylinders, I daresay that even 8MB cache is too small. You'd need 16MB for a decent rotation buffer for the rim. Densities increase, and with them, the cache sizes as well. IMO even distant-future SATA versions aren't able to cater for potentially high-performance, high-density drives of the future. That is, assuming that increased density means more data per cylinders instead of more cylinders. However, I think that the former will be the case. Increasing capacity / cylinder basically requires just better materials and manufacturing processes whereas increasing the number of cylinders requires better mechanics. Hint: everyday mechanics really haven't evolved all that much since Sir Isaac Newton's discoveries...

To rattle this can of worms - or snakes - even more, things get really interesting when you have a mix of read/write operations (you see, so far I've been babbling purely about reads, that is, dataflow from platters). Having a huge cache/buffer at one's disposal helps a lot there. HD write speeds are typically about half of the read speeds. To me that suggests that the HD's actually replace a simple write request with some sort of write/read/compare/verify operation. For them, you'd have to keep the known-good data in the HD cache. If the cache isn't large enough to hold either an entire cylinder or entire head, rotational latency comes and kills.

Ncogneto, I daresay that the purposes of HD and OS caches are so different that the system level apples-to-apples "real life/real file" comparisons you're craving for are truly impossible. OS is aware of files and knows what it needs in terms of files, whereas the HD cache is aware of what the drive - and the drive mechanics in particular - do need. OS caches are big, smart, and consequently have a high hit rate. IMO, drive caches aren't really caches but relatively dumb cylinder/head buffers. HD caches probably have very strict real-time requirements, so adding real smarts to them would require rather complex controller logic implemented in hardware. Ncogneto, since you drew a parallel to NVidia stuff, definition of "complex" in this case would be some GPU. More often that not, they need cooling, and they don't even have any moving parts...

Ncogneto, I must ask if this is the kind of justification for big HD caches you were looking for? I admit that the reasoning behind my claims is just about as sound as numerology, but I stick to my guns nevertheless. I can't do any better unless I succesfully apply for a design job at some HD manufacturer. And even if I did find out about the truth, I probably couldn't tell you.

PS: If you've read this far, there is a very good chance that you truly are an unique person...

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

WingDing · Sep 9, 2002

.......zzzzzzz......zzzzzzzz.......zzzzzzz.........

My dick is so big that it occupies two different time zones

Napoleon · Sep 9, 2002

.......zzzzzzz......zzzzzzzz.......zzzzzzz........

Ouch. I mean OUCH. I've been lurking in THGC forums for some time (spells years) and I've never seen such a harsh and to-the-point reality check. Thank God I added the "hidden" final remark to save certain remnants of my self-esteem. Wingding, you're one of a kind in my book. They don't make human facsimiles like you any more.

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

Ncogneto · Sep 9, 2002

First off the rotation latency figure you quoted is incorrect it should be 4.2 ms, unless you are talking about a worse case scenario. To further complicate thing you start with an assumption of the BB and JB to utilize vastly different mechanics...right off the bat by doings so you have negated the whole basis of the argument which is the value of adding extra cache in of by itself, not when used in conjuction with other mechanical enhacements.

It's not what they tell you, its what they don't tell you!Edited by ncogneto on 09/09/02 01:31 PM.

Ncogneto · Sep 9, 2002

Forgive me but I am going to shameless copy and paste another persons thread taken from Storage Reveiw forums:

You may view the entire thread here: <A HREF="http://forums.storagereview.net/viewtopic.php?t=3200&highlight=" target="_new">http://forums.storagereview.net/viewtopic.php?t=3200&highlight=</A>

Ever since drives first integrated their own controllers, there has been speculation of every kind regarding the value of the hard drive cache. Fairly recently, Western Digital released a drive with significantly more cache than others in its class, and the speculation has reached new levels of absurdity. I thought it was time to put my position on record.

First, let us remember that it wasn’t too long ago, that hard drives had fixed, and fairly simple geometries. A set of CHS values could describe a drive well enough, to implement many valuable performance enhancements. Cylinder groups found in Berkeley’s Fast File System are a perfect example of this type of optimization, found deep within operating system.

A very simple example of how accurate geometry information leads to better performance is the buffer cache. Imagine that you have developed a program that parses a file by reading each character from beginning to end. Since you can’t really read 1 byte from a disk, a naïve implementation would read the file 512 bytes at a time, resulting in 20,480 reads for a 10MB file. Since there are other applications running, that also require the attention of the disk, this could result in as many as 20k seeks. This would be very slow. This process goes a great deal faster, if the IO system (which part, depends on the OS and version) were to read ahead, prefetching the file in to the buffer cache. Subsequent reads could then come from the cache, instead of disk.

Everything I have described can be done without accurate geometry information. The difference is in how the read ahead is handled. The buffer cache of a modern system, mated to an LBA drive, would typically prefetch some fixed number of blocks, following the user request. In this case, the OS has no idea if the prefetch will reduce the number of IOs the drive can service, or not.

Think of it this way. You are on a scavenger hunt, and you have a list of items to pick up all over the city. As you progress, you are given new lists. In some cases, items which you suspect may be on future lists, are genuinely on the way. You can pick up these items, without slowing down the process. If something is out of the way, you probably shouldn’t pick it up, until you have been asked to. After all, though you anticipate that it might appear on a future list, you could be wrong.

In the case of buffer cache read ahead, prefetching is typically “on the way”, if the blocks all reside in the same track, or at least the same cylinder. If the heads have to be moved for a cylinder-to-cylinder seek, this may be out of the way. Of course, even blocks on the same track may be out of the way, if the delay forces the disk to wait a full revolution before it can satisfy the next IO.

Only software with accurate geometry information can make this determination. In modern LBA systems, this probably means the firmware in the drive. In some cases, even more detailed drive characterization in the form of head acceleration and other figures can lead to additional optimizations. Point one for the drive cache.

Even before hard drives had integrated controllers, and cache, they had buffers. As was pointed out recently by an esteemed member of our community, on another board, there is a subtle difference between a buffer and a cache. The issue is somewhat confused, because while a cache may be used as a buffer, not all buffers are caches.

Buffers are important, because there are two essential characteristics which determine the transfer speed of a disk over its host interface: bandwidth, and latency. If the device lacks sufficient buffer space, to deal with the round-trip latency over the interface, the transfer speed will be limited to a value far below its nominal bandwidth. Try using xmodem-128 over a fast link, and you will see what I mean. This is also a serious problem for TCP connections over satellite or other high latency link. Without support for large windows, the transfer speed is limited by the standard 64K window, not the bandwidth of the link. Point two for the drive cache(buffer).

It would seem so far, that I am reinforcing the importance of the drive cache. In fact, I feel that the significance of large drive caches has been seriously over stated.

As I have described, a sufficiently large buffer for transfer is essential. Increasing the size of the buffer, beyond the level necessary to hide the round trip latency however, adds no value. All modern drives have caches(buffers) which are sufficiently large for this purpose.

Although I have nothing against large drive caches per se, one has to consider the opportunity costs. Will I see better performance from an 8MB drive cache, or a system buffer cache that is 32MB larger? Even if we don’t consider that adding commodity dram to your system is cheaper than increasing the drive’s built-in cache, are the 8MB really best used inside the drive?

Consider that modern PCs have bandwidth to their primary dram measured at somewhere around 2.5GB/s. The latency to this dram is measured in nanoseconds. The drive cache however, can be accessed no faster than 320MB/s(theoretical, not measured), and in most cases is much slower. Furthermore, an application may not simply reference this data. Rather, it must issue a system call, walk down the driver stack, wait for an interrupt, and walk back up the drive stack. This takes time, and loads the system.

But what of the advantages of accurate drive characterization? After all, I described scenarios where the firmware can clearly make better caching choices, than an operating system hidden behind an LBA interface.

The assertion that all LBA sectors are mapped in order, turns out to be sufficiently detailed for the vast majority of cases. As I observed here, “The difference between servicing IOs in fifo order, and servicing them in logically sorted order is substantial. The difference between servicing them in logically sorted order, and using some lower level knowledge is much less so.”

The question is, are the advantages of accurate drive characterization sufficient to overcome the disadvantage of being farther from the processor? I believe that for most workloads, the answer is a resounding no!

So why do drives with large caches do so well in benchmarks?

The primary reason is that benchmarks work hard to isolate the drive from its surrounding system. Indeed, drives with larger caches do outperform those with smaller caches, when tested in isolation. When viewed at the system level however, the drive cache is essentially a tiny, mostly inclusive slice of the system buffer cache. How valuable would we consider the inclusive 512K L2 cache of a processor, if its L1 cache was 32MB?

Drives tests are convenient, because we assume that they extrapolate fairly easily to application performance(not always true). Since we are considering opportunity costs and general system performance however, direct application testing is required.

I for one, would like to see more of this type of testing.

It's not what they tell you, its what they don't tell you!

Napoleon · Sep 9, 2002

I am talking about the worst case rotation scenario. I mostly used rotation time to calculate (theoretical) internal transfer speed of the HD which IMO is dictated by the rotation time and capacity/cylinder or capacity/head. Hence, I used 8.4ms full rotation time instead of 4.2ms average rotational latency. Of course, I could've used 4.2ms in my figures, but it would only have made bigger HD caches look better than they really are.

Vastly different mechanics in WD1200BB and WD1200JB? Where exactly did I say that? The whole thing was based on the fact that the mechanics are identical (equal amount of cylinders, equal amount of heads) but could be used in a different manner by the firmware. My point was to give a theoretical example how identical mechanics could be used more efficiently with a larger cache. That is, by reading entire cylinder (7MB) to HD cache with single rotation vs reading entire "head" (7/6 MB) to HD cache with single rotation. BTW, I've always assumed that individual heads do not move independently. Is that assumption correct?

To quote your quote:

Buffers are important, because there are two essential characteristics which determine the transfer speed of a disk over its host interface: bandwidth, and latency. If the device lacks sufficient buffer space, to deal with the round-trip latency over the interface, the transfer speed will be limited to a value far below its nominal bandwidth. Try using xmodem-128 over a fast link, and you will see what I mean. This is also a serious problem for TCP connections over satellite or other high latency link. Without support for large windows, the transfer speed is limited by the standard 64K window, not the bandwidth of the link. Point two for the drive cache(buffer).

Pretty much what I've been saying, but apparently much less clearly. Anyway, I go ahead and quote myself:

IMO, drive caches aren't really caches but relatively dumb cylinder/head buffers.

So, my point was to give an example case where "extra" cache could really be utilised to reduce "round-trip latency" somewhat. Quoting again:

As I have described, a sufficiently large buffer for transfer is essential. Increasing the size of the buffer, beyond the level necessary to hide the round trip latency however, adds no value. All modern drives have caches(buffers) which are sufficiently large for this purpose.

As vast majority of existing 7200rpm drives are equipped with 2MB caches, I think it's indeed safe to say that 2MB is sufficient. That's what I meant with my "1.17MB per head" speculation. What I don't agree with is the claim that additional HD cache adds *no* value at all. It doesn't add much, but 0.01 does not equal 0...

Somehow, I think that we are practically agreeing with each other but there's a communication break somewhere.

Let me clarify what I was trying to prove with my musings:

Two identical drives, except one has 2MB cache, the other has bigger cache. Is the one with the bigger cache faster?
YES.

Is it a *lot* faster?
NO.

Could I tell the two apart in everyday (office) use?
HIGHLY UNLIKELY.

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

Ncogneto · Sep 9, 2002

Vastly different mechanics in WD1200BB and WD1200JB? Where exactly did I say that? The whole thing was based on the fact that the mechanics are identical (equal amount of cylinders, equal amount of heads) but could be used in a different manner by the firmware.

Actually you went a bit further than that or I am just understanding you wrong:

So, let's make a wild assumption that the WD1200JB is designed so that all the 6 heads are used in parallel during single rotation, kinda like internal RAID. ........................
As for the el-cheapo WD1200BB case, let's assume that the heads are not used in parallel.

At best in this case while the mechanical systems maybe identical they are not being utilized in the same fashion, you have the poor BB stuck in first gear and the JB is in overdrive. This is being done in your example by the firmware. While I highly doubt this is what we are seeing, for sake of your argument what happens if the same firmware is used on the BB but only addresses 2 meg instead of 8? You see, you have introduced via your example two variables...not the one that is the topic of discussion.

Bringing me to this, an interesting test would be to flash the firmware of the JB drive with that of the BB and then do a side by side comparison. If the mechanics and platter density et all are indeed the same then they should perform identically.

It's not what they tell you, its what they don't tell you!

Ncogneto · Sep 9, 2002

Two identical drives, except one has 2MB cache, the other has bigger cache. Is the one with the bigger cache faster?
YES.

Is it a *lot* faster?
NO.

Could I tell the two apart in everyday (office) use?
HIGHLY UNLIKELY.

Now get to the heart of the matter. Do you think that the increase in cache size is the only reason the JB outperforms its less endowed sibling? And if not how much does this extra cache account for the increase in performance?

It's not what they tell you, its what they don't tell you!

Napoleon · Sep 9, 2002

I think that increase in cache size is the only reason why WD1200JB is slightly faster than WD1200BB.

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

Napoleon · Sep 10, 2002

At best in this case while the mechanical systems maybe identical they are not being utilized in the same fashion, you have the poor BB stuck in first gear and the JB is in overdrive. This is being done in your example by the firmware. While I highly doubt this is what we are seeing, ...

Gotta hand it to you, your scepticism isn't entirely unwarranted. Took stupid me this long to find some decent facts about <A HREF="http://www.wdc.com/products/current/drives.asp?Model=WD1200BB" target="_new">WD1200BB</A> and <A HREF="http://www.wdc.com/products/current/drives.asp?Model=WD1200JB" target="_new">WD1200JB</A>.

Both have max. 602Mbits/s = 75MB/s buffer-to-disk speed. There goes my funky assumption about internal parallelism in JB's vs no parallelism in BB's, down the drain. Also, interleave is 1:1 in both drives. Furthermore, reported number of cylinders is fixed to 16383 for >8.4GB drives due to some ancient EIDE interface limitation. So, number of physical cylinders could actually be much higher. Consequently, average density per cylinder would be much smaller than 7MB. That undermines my "8MB buffer is needed to cache entire cylinder" quite badly. There's still a slim chance that my "7MB/cylinder == 1.17MB/head" assumption is approximately right for the very outmost cylinders. At least I don't see how 75MB/s max. buffer-to-disk speed would be possible otherwise. Slight comfort, though. Since it seems that my assumption about parallelism was erroneous, 2MB cache would be entirely sufficient to tackle any round trip latencies, with room to spare. Just about the only good thing is that this brings us back to the situation were the cache size is the one and only variable...

Bringing me to this, an interesting test would be to flash the firmware of the JB drive with that of the BB and then do a side by side comparison. If the mechanics and platter density et all are indeed the same then they should perform identically.

Now you're talking! Would be great indeed if some daring soul could replace WD1200JB's controller board with WD1200BB board and see what happens. Count me out, though. I don't have the drives, nor the skill.

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

lhgpoobaa · Sep 10, 2002

I cannot remember where i read it but an increase in cache size is NOT the only difference between the BB and the JB. I believe there are also firmware optimisations. Optimisations that apparently are aimed towards desktop and gamer usage.

some time ago i also toyed with the idea of what would happen should you replace the actual cache chip for something much larger... like a 16 or even 32mb chip. Course thats well beyond any skill i have.

My life has been so much more colourful since the advent of Super VGA! :lol:

Napoleon · Sep 10, 2002

Another cool mod, at least if it works.

Xbitlabs had yet another interesting <A HREF="http://www.xbitlabs.com/storage/wd1200jb/" target="_new">article about WD1200JB</A>. I'll quote some details directly. Dunno if the first quote is true or not, but it is interesting nevertheless.

A few months ago, Western Digital offices were living through a real tumult. The reasons for this worry were quite serious: the memory chips suppliers seem to have connived with each other to stop producing 16Mbit SDRAM chips and shifted to the production of more profitable and up-to-date 64-256Mbit chips. The 16Mbit chips Western Digital had in stock kept dwindling before their very eyes, since WD hard disk drives enjoyed pretty high popularity. Besides, WD had to avoid letting down one of its major OEM-partners, Microsoft, which was filling its stocks with X-Box consoles before the retail sales started.

In despair, Western Digital purchasing office signed fettering agreements about the shipments of the memory chips available in the market then. However, in order to make up for the price difference between the new chips and the formerly used 16Mbit ones, the faster and more profitable HDDs than the Low-End solutions acquired memory modules of greater capacity.

Then an even more incredible thing happened. By an oversight of one of WD's software developers, the hard drive DSP-processor could now access not only 2MB, but the entire 8MB memory. And which is also unbelievable, the HDD with this "crazy" DSP-processor turned out evidently faster than its counterparts featuring memory modules of lower capacity.

Luckily, WD decided not to conceal this fact, but to make some money on it. The hard disk drive model with larger cache-buffer was called "Special Edition" and started selling at a "special" price. The purchasing office and the software guy got a significant wage raise, and the competitors started whipping the cat and keep doing it still.

Anyway, enough joking Let's get down to something more serious.

This is the reverse side of the hard drive PCB. Please have a look at the memory chip, which is located on the left of the bigger chip.

If you take a close look at it you will see the marking of a 64Mbit Nanya chip: NT56V6620C0T, which means that the cache buffer of the HDD makes 8MB (the same thing was proven by the IBM Feature Tool utility, actually).

The funny thing about this Nanya chip is that it is listed among the discontinued (EOL) products. We prefer not to imagine what it may mean

Interesting, most interesting. Well, to me at least.

Basically, the "cache" looks like a standard 133MHz CL3 SDRAM chip. Couldn't make out the speed grade from the image, though. Might be the 143MHz version. Anyway, I dloaded a bunch of Nanya SDRAM datasheets. At a quick glance, the EOL 8MB Nanya chip seems pin-compatible with newer 8MB and 16MB Nanya SDRAM chips. 8MB, 16MB and 32MB chips all come in 54pin TSOP-II packages, but pin36 has changed from NC (No Connection) to A12 in the 32MB chip. Anyway, even the 32MB chip might work, provided that WD has routed A12 on the PCB and the firmware can somehow recognise (and utilise) >8MB chips automatically.

No such luck about downgrading to 2MB. Contrary to the 1st quote, at least Nanya does still produce 2MB SDRAM chips, but they come in 50pin TSOP-II package. No pin compatibility there. So I guess that WD had to change the controller PCB to accommodate the 8MB chip. If they did that, could be that they've tweaked the firmware too while they were at it.

Well, at least we could still determine the HD cache's significance if some wizard managed to up the cache to 16MB or even 32MB. Even if the chips couldn't be bought separately, I bet suitable chips could be scavenged from some old SDRAM DIMMs. If one is so inclined.

What do you mean, "don't touch that heatsink"? Step aside and let me show you howWAAAAH!!

Ncogneto · Sep 10, 2002

<A HREF="http://www.wdc.com/products/current/drives.asp?Model=WD800BB" target="_new">http://www.wdc.com/products/current/drives.asp?Model=WD800BB</A>

<A HREF="http://www.wdc.com/products/current/drives.asp?Model=WD800JB#electrical" target="_new">http://www.wdc.com/products/current/drives.asp?Model=WD800JB#electrical</A>

Take special note. JB has 2 platters(4 data surfaces) and the bb has 3 platters (6 data surfaces). This equates to a higher data density on the JB over the BB.
Furthermore:

WD BB = Transfer Rate (Buffer to Disk) 525 Mbits/s maximum
WD JB = Transfer Rate (Buffer to Disk) 602 Mbits/s maximum

It's not what they tell you, its what they don't tell you!

Napoleon · Sep 11, 2002

Tsk, Tsk. Ncogneto, are you amnesiac or something? Or on something? This thread has been about WD1200BB vs WD1200JB (as example cases) from the start. I've already admitted the fact - a fact that you (politely, thank you for that) pointed out to me no more than a couple of days ago - that 800BB and 800JB are totally different drives. Well, not totally different I suppose, they have the same manufacturer after all. Quoting myself (09/09/02 04:27 AM):

I stand corrected (and go off-topic myself. Sorry, I can resist everything but temptation). Now that I checked the WD website, WD800BB and WD800JB are indeed totally different drives, three platters vs two platters and all.

That was back in the good old "SCSI better than IDE" thread. I started this thread so that people doing a search on the 2MB vs. 8MB HD cache might find something marginally relevant.

Not being a native English speaker/writer, my style might not be of the quality and clarity you've accustomed to. However, I'm always willing to learn, so please go back to the quote above and point out the faults due to which you felt necessary to post yet another clarification about WD800?B differences.

I'm genuinely curious about the significance of HD cache and I realize that I sorely need experienced help to resolve the issue. Ncogneto, since you and I are about the only people keeping this thread alive, I would very much appreciate an attention span of one week from your part. If you don't think that's doable, could you please ask Wingding to take over as my opponent? His comments may be somewhat offensive but he seems consistent, to say the very least.

Napoleon offended. In fact, Napoleon outright pissed off. Napoleon gearing up for war. Should Napoleon stand down?

I doubt, therefore I may be.

lhgpoobaa · Sep 11, 2002

yeah. i guess we should be careful of what drive we are talking about.
the 800JB and BB ARE different with data density i relised, due to W.D.'s somewhat different naming scheme. (it would be nice if they stuck to the same scheme as the other manufacturers)
anyway, the 1000 and 1200 drive all use 40gb platters i believe, allthough for a while there was debate to if the 1000 was 3 platters of 33gb or 3 of 40 with only half of the last one used.

annnnyway... great articles you guys are digging out.
your definately are gonna be on the FAQ roll of honour when it gets updated next

My life has been so much more colourful since the advent of Super VGA! :lol:

Ncogneto · Sep 11, 2002

Anyway, IMO there is a golden opportunity to settle this one for good. Let's assume that the BB and JB models are identical except for the cache size (WD hasn't tuned JB's caching algorithms for 8MB cache or anything like that).

I do not ever remember being about the 120 gig drives only. I always thought it was about JB vs BB. But I digress, you did address that issue and I apologize ( 80 gig size drives)

I'm genuinely curious about the significance of HD cache and I realize that I sorely need experienced help to resolve the issue

As was I. I have in my possesion as I stated earlier, several of these <A HREF="http://www.seagate.com/cda/products/discsales/enterprise/tech/0,1084,327,00.html" target="_new">http://www.seagate.com/cda/products/discsales/enterprise/tech/0,1084,327,00.html</A> I have them in both the fc (4 meg cache)and fcv ( 16 meg cache ) variations. The 16 meg versions do not yeild anywhere near the improvement as see from the bb to JB.

It's not what they tell you, its what they don't tell you!

Napoleon · Sep 11, 2002

I apologize for my outburst. Had a looong lousy day. I know, lame excuse for lashing out at people who had nothing to do with it, but that's what happened. Not very constructive. :redface:
Anyway, I've gotten me some healthy, natural sleep and feel now much less inclined to reach an online Waterloo. Thus, Napoleon stands down...

I take it that your Seagate drives are SCSI? Never had the chance to experience the wide and wonderful world of SCSI myself; mere thought of paying that premium brought tears to my wallet. Regardless, I've been under the impression that SCSI cards are much, much smarter than their IDE card / onboard IDE counterparts. I'm also under the impression that SCSI controllers have much more control over HD cache usage (enable/disable caching, enable/disable lazy writes etc). I assume you have all such SCSI performance goodies enabled?

Presuming that your SCSI card does have it's own cache (some RAID card?), it would really be doing practically the same job as the HD caches. In that case, I think that any extra cache on the HD's would be largely redundant, kinda like level three cache. Anyway, several of those 10000rpm speed monsters? I see you're taking HD performance very seriously, those babies must have cost you arm and leg.

Basically, dumb IDE doesn't have the tweaking possibilities that SCSI does, all IDE "cleverness" is integrated on the drive firmware. Correct? Well well, it's been several paragraphs since I last quoted myself, so I'll go ahead and do just that. Oh boy, am I getting good at that...

No such luck about downgrading to 2MB. Contrary to the 1st quote, at least Nanya does still produce 2MB SDRAM chips, but they come in 50pin TSOP-II package. No pin compatibility there. So I guess that WD had to change the controller PCB to accommodate the 8MB chip. If they did that, could be that they've tweaked the firmware too while they were at it.

Ncogneto, that statement of mine effectively reintroduces the additional "firmware variable" you criticized earlier. But having run around in circles this long, I'm beginning to think that size of HD cache and the HD firmware utilising said cache are such a closely knit pair that it is nigh impossible to separate them.

Still, IMO that doesn't automatically make the "larger HD cache is solely responsible for the performance improvement" argument invalid. Let me draw a parallel to the OS world. Lots of people like to max out on main memory (I have, how about you?). Occurrences where every last bit of it is absolutely essential are extremely rare, at least in my case. But if/when they do take place and the memory isn't there... Yikes!

I doubt, therefore I may be.

Ncogneto · Sep 11, 2002

I take it that your Seagate drives are SCSI? Never had the chance to experience the wide and wonderful world of SCSI myself; mere thought of paying that premium brought tears to my wallet.

Actually no, they are Fibre channel thus the -fc ending. as for a premium....got them for an average price of around $75.00 ea.

I'm also under the impression that SCSI controllers have much more control over HD cache usage (enable/disable caching, enable/disable lazy writes etc). I assume you have all such SCSI performance goodies enabled?

Yes and no, not at the drive level.This is done via the firmware of the drive. as for the controller cache, this would be in the case of a Raid controller and gets a bit more complicated. For example in a RAID 0 array consisting of three drives, each individual drive has no clue it exists as part of a raid set. So then the controller cache then takes all set of three hard drive caches and assembles them in its cache. But things get even more compicated than that and you really are opening up pandora's box if you want to talk about raid controllers and thier cache. For the purpose of this discusion it is best to stick with non-raid cards. We are trying to stick with typical drive usage on the typical desktop correct? BTW my drives firmware is configurable with a utility called Seatools, but this is independent of the controller.

It's not what they tell you, its what they don't tell you!Edited by ncogneto on 09/11/02 03:49 PM.

Ncogneto · Sep 11, 2002

Presuming that your SCSI card does have it's own cache (some RAID card?), it would really be doing practically the same job as the HD caches. In that case, I think that any extra cache on the HD's would be largely redundant, kinda like level three cache. Anyway, several of those 10000rpm speed monsters? I see you're taking HD performance very seriously, those babies must have cost you arm and leg.

actually I have several cards. for the purpose of this discussion I will use a simple qlogic 2100 series controller that is not raid capable. I do own a DPT ( adaptec ) pm3755f with daughter card making it a dual channel FC raid card with 64 meg cache ( until I get my mylex card not fond of adaptec )

I'm beginning to think that size of HD cache and the HD firmware utilising said cache are such a closely knit pair that it is nigh impossible to separate them.

I do not know about the JB series drive. I do know it is possible to flash the firmware of my 16 meg cach drives (fcv) to that of the 4 meg drives (fc). however for obvious reasons the reverse is not true.

It's not what they tell you, its what they don't tell you!

Napoleon · Sep 12, 2002

Actually no, they are Fibre channel thus the -fc ending. as for a premium....got them for an average price of around $75.00 ea.

*Burst of uncontrollable weeping, maniacal laughter and violent spasms*
Where I live, cheapest 36GB Cheetah 73LP (SCSI) I could find costs about €350, and price of SCSI cards goes along the same lines. Set that against the €120 of my recently acquired 60GB Barracuda IV...
FC, no sale. I suppose I could order abroad. But being somewhat conservative, I feel much better knowing that if something goes terribly wrong, I can find some flesh-and-blood person and give him/her a piece of my mind. Or at the very least, "return" any malfunctioning POS back to the retailer through their front window some late night.

Oh boy, if I could get e.g those 73LP babies for something like $100 at a nice local retailer, I wouldn't even spit in IDE's direction...

But things get even more compicated than that and you really are opening up pandora's box if you want to talk about raid controllers and thier cache. For the purpose of this discusion it is best to stick with non-raid cards.

Agreed, totally agreed. Let's not go there. I was just curious about the setup you based your findings on. To me, "several of these..." simply spelled "RAID"

.

Anyhow, I think that in your case the significance of cache size is greatly reduced by the fact that the 73LPs are mechanically much more solid performers than any JB drive: 10000rpm vs 7200rpm, 5ms vs 9ms average seek, 0.5ms vs 2.0ms track-to-track seek, <10ms vs 21ms full stroke asf. Also, since the density is smaller than in JB's (about 20MB/platter vs 40MB/platter), 4MB cache already provides plenty of playground for implementing e.g ordered lazy writes, read-around-write, write-around-read and other happy-go-lucky caching stuff.

IMO, HD cache's two main functions are: 1) Eliminate rotational latency as much as possible and 2) reduce number and distance of seeks by ordering disk operations as much as possible in the spatial sense. In that sense, when "adjusting" the cache size with density, IMO 4MB cache in 73LP already is rougly equivalent to JB's 8MB cache. And the 16MB would be equivalent to 32MB in JB's. Now that is beginning to sound like a bit of an overkill...

I do not know about the JB series drive. I do know it is possible to flash the firmware of my 16 meg cach drives (fcv) to that of the 4 meg drives (fc). however for obvious reasons the reverse is not true.

I don't think it is possible for IDE end users to flash their firmware just like that. But I do think that your 4MB cache FW --> 16MB cache drive but not vice versa reinforces my points about the significance of FW and cache size pairing. At the very least, the FW has to be aware of the amount of cache memory. Doesn't help any if there's 16MB cache if the FW is configured to use only 4MBs of it. Then the FW has to decide what are the best ways to utilize the available cache memory ("available" being whatever the FW perceives the amount of cache memory to be).

IMO, that's where things get really hairy. OS caches work in a temporal way for the most part. At least with IDE drives, they don't have much choice; LBA interface hides the disk geometry. Modern IDE drives do return some geometry information due to legacy reasons, but the values usually are completely bogus. Consequently, just about the best an OS cache can do with IDE drives in the spatial sense is to try and arrange a single disk transaction to have as many consecutive LBAs as possible. Using it's knowledge of the applications' needs as a guideline, of course. With some luck, one such transaction can be very long; truly random access does not exist in real life. A big (IDE) HD cache can help a lot with those really big accesses. Employing it's intimate knowledge of the HD's status and characteristics (angular position of current rotation, current position of heads, TAREd sectors, whatnot), HD firmware can break big transactions into pieces that are optimal for the drive mechanics. Make a sort of battle plan how to complete the transaction with minimal losses.

On the other hand, if a HD manufacturer simply slaps in a bigger memory chip and implements a simple temporal cache with it... that would truly be pure marketing hype. There's no chance that some puny 8MB chunk of memory could beat the OS in its own game. Such extra cache in the HD wouldn't hurt the performance, but it wouldn't help either. But since the WD1200JB drives bench faster than their BB counterparts, I daresay that the properly utilized 6MB extra cache memory is the only reason.

I bet that SCSI / FC drives are able to report their mechanical characteristics much more accurately. If so, the OS could (and many do, I bet) arrange their caches according to the disk characteristics. In those cases, the OS cache already has the best of both worlds, making huge HD caches in SCSI / FC drives largely redundant.

So, these are my justifications for bigger (IDE) HD caches and also for reintroducing the effect of firmware into the "equation". To sum it up:

Size does matter, but ultimately it's in the way that you use it. :lol:

I doubt, therefore I may be.

lhgpoobaa · Sep 13, 2002

"Size does matter, but ultimately in the way u use it"

LOL yep.

My life has been so much more colourful since the advent of Super VGA! :lol:

Napoleon · Sep 23, 2002

So, these are my justifications for bigger (IDE) HD caches and also for reintroducing the effect of firmware into the "equation".

I guess I'm flogging a dead horse here, but still... X-bit labs wrote yet another interesting <A HREF="http://www.xbitlabs.com/storage/13-idehdd-roundup/" target="_new">roundup</A> on this matter. Check out the conclusions in the end, they're quite intriguing. Or read the whole thing and draw your own.

I haven't lost my mind. I know exactly where I left it.

dhlucke · Sep 24, 2002

Wow. I own the 1200JB and yes, it's faster than any other hard drive I've had. However, I should note that the benchmarks wouldn't show it. I think my IDE controller for my motherboard is either not as good as others or I have some other weird issue that's holding my marks back.

Nonetheless, certain tasks are very fast with this drive. Splitting, compressing, and decompressing files is definitely one of them.

Anyone have this drive with a ECS K7S5A and want to share their experiences?

I'd like to dedicate this post to all my friends, family, and fans. Without them this post would never have been possible. Thank you!

the_stranger · Sep 30, 2002

Napoleon: I apologize for going off-topic here, but I just wanted to say I've thoroughly enjoyed your posts in this thread - it is a topic that certainly does interest me, as I am in the market for a new high-performance IDE drive at the moment. Not only are your posts technically interesting, but the sarcasm, wit, and wordplay have been entertaining and refreshing

Thanks!

--jeff

Napoleon · Sep 30, 2002

Why thank you! Compliments directed to me are never off-topic, at least IMO. Made my day, in fact.

Gotta give credit to Ncogneto as well, though. The whole thread would have just died at its infancy if not for a well-versed naysayer.

You want WHAT on the [-peep-] CEILING?! -Michelangelo

Is 8MB cache better than 2MB?

Distinguished

Champion

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Illustrious

Distinguished

Distinguished

Distinguished

Illustrious

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Illustrious

Distinguished

Polypheme

Distinguished

Distinguished

Share this page