Not sure about that since I've used this software extensively, when it was in beta for nearly 2yrs I believe.Primocache works at the block-level, as the developers state in their website, as most storage caches do. There are also some cache products that work at the file-system level, but they are fewer in number.
Now, about the Device\Harddisk0\DR0 block device, it seems that it is the virtual disk that the Intel Software RAID driver created over multiple physical disks, and this would explain why you don't see any speedup.
Not sure about that since I've used this software extensively, when it was in beta for nearly 2yrs I believe.
I don't have it installed on my desktop with RAID0 SSD's but I did use on my laptop previously, see my earlier results for instance ~ http://forums.anandtech.com/showpost.php?p=36498929&postcount=8
Yes it was, on my laptop, but even with 8GB RAM (recently upgraded to 16GB) I din't see the kind of numbers I was expecting rather hoping for. I may revisit the application if/when I upgrade the storage on my laptop, to SSD, & am definitely looking at RAPID or some other OEM caching software like Plexturbo provided I don't find Primocache too helpful at that point in time either.From this post I can see the part number (st1000lm024) of the 1 TB Seagate/Samsung HDD. It is evident that AIDA64 was ran on this HDD and hence the low numbers.
Yes it was, on my laptop, but even with 8GB RAM (recently upgraded to 16GB) I din't see the kind of numbers I was expecting rather hoping for. I may revisit the application if/when I upgrade the storage on my laptop, to SSD, & am definitely looking at RAPID or some other OEM caching software like Plexturbo provided I don't find Primocache too helpful at that point in time either.
Btw thanks for your informative (last) post on the previous page
I am not against DRAM caching, I'm just raising awareness of the issues.
Also, read DRAM caching is dumb, NTFS already does this. If you are to use a RAM-disk for a cache you should cache both reads and writes in write-back mode, or deferred writes as they call it.
I can't think of a single scenario where write-through DRAM caching is useful, when NTFS already does it. If you go that way, go all the way through!
That;s the thing, with an HDD installed you're better off using at least some form of L2, even a high speed USB flash drive will do, but for that I'll have to abandon the existing ODD & that's something I need. I'll however go for an SSD upgrade sometime this year after which I don't see there being any need for Primocache, unless one's looking specifically for some form of RAM caching &/or wants to minimize his SSD read/writes perhaps for endurance.Yet I DO notice quite a difference in HDD usage and access for the L2 feature, just as I was happy with ISRT using the Intel solution.
That;s the thing, with an HDD installed you're better off using at least some form of L2, even a high speed USB flash drive will do, but for that I'll have to abandon the existing ODD & that's something I need. I'll however go for an SSD upgrade sometime this year after which I don't see there being any need for Primocache, unless one's looking specifically for some form of RAM caching &/or wants to minimize his SSD read/writes perhaps for endurance.
Does windows do block caching? Does Windws do write coalescing? What's the maximum write cache size in Windows?
As a long-time modded Bethesda game player, plenty of RAM makes the most difference. My SSD lets me back up the game folder as I try mods easier, but it has made almost no difference in speed of loading, which is mostly CPU limited, just as when I was running a HDD. Big games might not use much RAM for their process, but they will take advantage of Windows mapping cached files for them, instead of hitting the drives, and doing that is still a few orders of magnitude faster than going to an SSD.
Even if you do the SSD cache thing, if he's got 4GB RAM, there's room to improve. IMO, get 2x4GB. If the PC has 2x2GB, and it plays nice with the old stuff, you got 12GB, if not, 8GB. 4GB may be enough, but enough is still a ways off from ideal.
First, NTFS doesn't do crap. It's a file system. Operating systems do caching, file systems don't.
Does windows do block caching? Does Windws do write coalescing? What's the maximum write cache size in Windows?
Perhaps now that you are less misinformed you will refrain from telling people what they are doing wrong
Edit
Or maybe not going by this thread when everyone disagreed with you.
http://forums.anandtech.com/showthread.php?t=2338595&highlight=
Seems you have a problem with not knowing as much as you think you do.
I had 16GB DDR3-1600 in my i7 860 rig I built in April, 2010, I had hoped it would make up for the awful performance of a WD 2TB "Green" drive. That system was ab-so-lute-ly excruciating, and it was entirely due to the slow HDD. If Windows caches on a block level, it certainly was not utilizing the memory capacity in the way that it should.Here's some old, but still relevant information on file caching behavior in Windows: http://msdn.microsoft.com/en-us/library/bb742613.aspx
That being said, most of your questions are answered by the MSDN link that ashetos posted. Earlier in the thread, Cerb also posted a good illustration of this:
As a long-time modded Bethesda game player, plenty of RAM makes the most difference. My SSD lets me back up the game folder as I try mods easier, but it has made almost no difference in speed of loading, which is mostly CPU limited, just as when I was running a HDD. Big games might not use much RAM for their process, but they will take advantage of Windows mapping cached files for them, instead of hitting the drives, and doing that is still a few orders of magnitude faster than going to an SSD.
Even if you do the SSD cache thing, if he's got 4GB RAM, there's room to improve. IMO, get 2x4GB. If the PC has 2x2GB, and it plays nice with the old stuff, you got 12GB, if not, 8GB. 4GB may be enough, but enough is still a ways off from ideal.
To answer your questions directly:
Does windows do block caching?
Yes, in 256KB blocks.
Does Windows do write coalescing?
I suppose that Lazy writes could be considered a form of write coalescence, however I'm not sure this is precisely what you are referring to.
I don't think the P55 supports Intel's SRT caching. Please correct me if I'm wrong.
My nephew lives far away from me in another state. I only see him briefly every few years. A while back, we built a Core i5 system for him. The first i5 CPUs had *just* been released. I don't remember the chipset of the Gigabyte motherboard. Would it be P55?
He has suffered with a WD 2TB "Green Power" drive most of this time he's had this system. I know...it should never ever be a boot drive. Using that system must be excruciating.
His system is having some problems and I'll definitely need to work on it the next time I see him. I'd also like to give him one of my unused 4TB drives with some kind of SSD caching solution.
Going with SSD-only is not an option. He plays lots games with very large installations, like Skyrim. His Steam library is huge.
I don't think my nephew is technical enough to manage what goes on an SSD and what goes on the HDD with a typical SSD+HDD system. That's why I think it would work best to have a caching solution where only 1 logical drive is presented to Windows.
What options do I have? Is there a software solution or an affordable hardware solution?
I read that Intel's SRT only supports caching up to 64GB. If there's a comparable caching solution, would it support 240GB? I'm thinking of upgrading to a higher-capacity mSATA drive for myself, so I might give him my 240GB SSD.
Also: If there is some comparable caching solution, could it also have onboard RAM for an HDD write buffer?
Thanks for any advice you guys can provide!
I had 16GB DDR3-1600 in my i7 860 rig I built in April, 2010, I had hoped it would make up for the awful performance of a WD 2TB "Green" drive. That system was ab-so-lute-ly excruciating, and it was entirely due to the slow HDD. If Windows caches on a block level, it certainly was not utilizing the memory capacity in the way that it should.
Yes volumes, specifically partitions, & you can select them for read/write or read+write even individually as to the type of caching scheme you wanna employ for each partition IIRC.Correct me if I'm wrong, but I think primocache only targets volumes / files you specify, thus enhancing the perceived cache-hit rate. Contrast that to native caching, which attempts to cache a little bit of everything.
My personal (unverified) observations indicate that even a best-case cache hit in Windows will still not return 100% of the file/data you are trying to access from memory, even if it's all stored in one, contiguous file and you have plenty of available ram.
ZeroRift said:. . . Correct me if I'm wrong, but I think primocache only targets volumes / files you specify, thus enhancing the perceived cache-hit rate. Contrast that to native caching, which attempts to cache a little bit of everything.
My personal (unverified) observations indicate that even a best-case cache hit in Windows will still not return 100% of the file/data you are trying to access from memory, even if it's all stored in one, contiguous file and you have plenty of available ram. . . .
Yes volumes, specifically partitions, & you can select them for read/write or read+write even individually as to the type of caching scheme you wanna employ for each partition IIRC.
Well even if it's not 100% depending on the workload it can be as close as (just over) 99%
My thinking is quite simple: let's not add that useless complexity into our solution.
Options:
1. I wouldn't recommend a software RAM disk caching solution to someone non-technical. Under this situation you are exposed to data corruption due to power loss, due to future possible bad RAM or, even worse, due to buggy RAM caching software solution. RAM is quite expensive. In order to really benefit, you'll need a lot of it. Too much complexity for someone non-technical. Hard to debug/fix a potential problem from a remote location.
2. 250GB/64GB SSD hardware caching through intel RST. So you've eliminated those potential 1 problems like power loss, buggy software caching screw ups, but damn, such a waste of ssd performance. You'll never get rid of "what's used the most" thingy, that's what will get accelerated, youl'll never achieve the true potential of that ssd, you've basically moved some of 1.'s software complexity at hardware level.
3. The one I would've probably chosen under this circumstances. Drop an at least 250GB SSD into the pc case! Educate your nephew on how to get used to a limited storage space, how to organize his data so that it fits on a limited partition! Show him how to install his most disk demanding game/software on the ssd and how to uninstall it! Those are good things to know/learn anyways. They will do him good on the long run.
4. Hybrid flash HDD. By far, the simplest and straight to the point solution based on my understating of your needs. You drop it inside the pc case. That's it. What your nephew access's the most, that will open the fastest. Off course that it has many disadvantages, but let's not forget that it is the cheapest(based on capacity) and most easy to maintain solution.
I would never take into account 1 and 2 for myself now days, even if I consider myself technical. SSD prices have gone down. Intel RST is a useless technology now and a thing of the past, that past when a few GB SSD's where at current 128GB price levels.
Well, a cache is only as good as it's hit rate, which makes it notoriously unreliable for enhancing performance. There are some Windows features that work to mitigate that, but it's never a guarantee.
Correct me if I'm wrong, but I think primocache only targets volumes / files you specify, thus enhancing the perceived cache-hit rate. Contrast that to native caching, which attempts to cache a little bit of everything.
My personal (unverified) observations indicate that even a best-case cache hit in Windows will still not return 100% of the file/data you are trying to access from memory, even if it's all stored in one, contiguous file and you have plenty of available ram.
Let's also keep in mind here, that the native Windows cache is not persistant. Windows does nothing in the way of L2 caching without 3rd party support (ReadyBoost notwithstanding). This means that if your underlying storage hardware is slow, it may take a very long time to populate the cache. Back in the XP era, I remember how systems seemed to run faster if you left them to idle for a while after startup. I'm guessing in retrospect that that was in fact due to a slow IO subsystem gradually caching common requests to memory.
Do you still have that old system? I would love to hear your comparison between native caching and primo cache. It'd be great to have a nice "low-water" mark anecdote.
The only drawbacks, the ones you're overly exaggerating, are that you're held back by the speed of your HDD, which in my case was a 5400rpm drive, especially without a fast L2 cache. The rest is, as you previously stated, purely magic :awe:Those "magical" numbers can be achievable by using samsung's rapid which comes at no cost. Samsung's rapid is also "magic". It is pure trickery with very few cherry picked benefits, but you at least get assurance that worst case scenario is back to ssd. With software solutions under this scenario you're back to crappy mechanical.
Don't forget that caching principles stay the same no matter the implementation. No matter if it's at hardware or software level, you can't get rid of its drawbacks.
Here's some old, but still relevant information on file caching behavior in Windows: http://msdn.microsoft.com/en-us/library/bb742613.aspx
That being said, most of your questions are answered by the MSDN link that ashetos posted.
Earlier in the thread, Cerb also posted a good illustration of this:
To answer your questions directly:
Does windows do block caching?
Yes, in 256KB blocks.
Does Windows do write coalescing?
I suppose that Lazy writes could be considered a form of write coalescence, however I'm not sure this is precisely what you are referring to.
What's the maximum write cache size in Windows?
The design limitation is 16TB for modern version of Windows. Obviously there are more practical limits that come in to play, for instance, x86 computers are rarely equipped with more than 4GBs of memory, which leaves a typical cache size of, at most, 1 GB.
Sources:
http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
http://msdn.microsoft.com/en-us/library/aa366778.aspx
Option 3 means his high-end games installed on the HDD won't have any performance improvement at all. That's the primary use for his system.
With option 2 (or any SSD+HDD read cache option), the game data that's accessed most frequently will be cached. The multiplayer maps will load quickly. If he never plays the single-player campaign, those videos and maps will not occupy SSD storage space. Great! Nearly all the important parts of the OS would quickly end-up on the SSD cache. Great!
Option 4 is unappealing because I'd have to buy a pricey drive I don't already have; and they all seem to have a pitiful 8GB of flash. I'm already surrounded with extra 2TB/4TB HDDs right now. A 4TB drive with 240GB SSD cache should offer nearly all the benefits of an SSD and all the capacity he needs for games.
Option 2 is where it's at, but need an alternative to Intel SRT. PrimoCache might be it, but I'm thinking of getting a Marvel controller with HyperDuo. They have these with mSATA so my hand-me-down 240GB SSD would sit right on the controller card and a 4TB drive would connect to the same controller card via SATA3.
My questions were rhetorical.
Anyway, Windows does not cache block operations. Windows file system cache is a file cache only.
Windows does not do write coalescing nor support TRIM In the cache.
Windows write cache on desktop systems is 1GB.
thanks for the links, interesting reading.
Those "magical" numbers can be achievable by using samsung's rapid which comes at no cost. Samsung's rapid is also "magic". It is pure trickery with very few cherry picked benefits, but you at least get assurance that worst case scenario is back to ssd. With software solutions under this scenario you're back to crappy mechanical.
Don't forget that caching principles stay the same no matter the implementation. No matter if it's at hardware or software level, you can't get rid of its drawbacks.
My questions were rhetorical.
Anyway, Windows does not cache block operations. Windows file system cache is a file cache only.
Windows does not do write coalescing nor support TRIM In the cache.
Windows write cache on desktop systems is 1GB.
thanks for the links, interesting reading.
So your're thinking at replacing intel rst with a ram caching solution? If that's the case, I would chose a hardware implementation of caching(intel rst) instead of software anytime.