30 Day update...

[magic-man]

For those of us who have been running the new version of FancyCache, it has been 30 days... I just wanted to give you an update on how it is working for ME... Overall, all is well. No crashes, minor issues. I am back to running the Volume version with a 3 Gig primary cache. For my usage, this seems to be the best setup (although I still may go to 4 gigs for the cache)... Below are my cache stats after a few hours at work, running FancyCache in my host (Win 7 64-bit) and doing my main work in 2 virtual machines:



If I am reading the stats right, here is what I am seeing as far as writes are concerned:
The program deferred 100,764 writes totaling over 3 Gigs...
The average write to the cache was 32K....
So the cache combined the 100,000 little writes into bigger writes, which MAY have caused less wear on my SSD (at least as I am theorizing), and DID speed things up a lot (at least for me)...
And... 66.44% of all my reads came from the cache rather than through the disk controller...

We agree? Is my math right?

[Support]

Hi,

Thanks for the update.

You are right. Just some additional information: you might have seen "Deferred Blocks (current): 35", it means that 35 blocks were modified and waiting to be written back to the disk.

[goldendragon]

I'm using the Volume as well since the Disk does not function (it installs but when clicking the icon nothing happens).
With Volume, I got a 2 or 3 BSOD in a week of usage.
I wouldn't rely too much on the statstics, I'm certain there must a bug that report impossibily high cahce hits in some circumstances, like 40+% sustained (worse, almost constant, no peaks no troughs) over minutes when I know it's not possible given my knowledge of the application and its I/O pattern: at the very least some counters are not reset properly in the statistics

[Support]

Read Hit Rate = Read Bytes (Cached) / Read Bytes (Total) * 100%

So if Read Hit Rate sustains, you might check if Read Bytes (Cached) and Read Bytes (Total) change or not. If they don't change, then there is no read commands sent to our driver layer. This is possible because windows itself has file cache mechanism acting before ours. And please note the statistics starts from the time that the monitor dialog opens, not from the time that computer boots up.

Regarding the BSOD, if you have time, could you please help us get a memory dump file?
Refer to http://www.romexsoftware.com/en-us/know ... -file.html

The disk version shall be ok...do you reboot after installation?

PS. we plan to release a new beta version in a couple of days.

[goldendragon]

And please note the statistics starts from the time that the monitor dialog opens, not from the time that computer boots up.

it goes without saying: as it stands now, I have to start Fancycache Volume manually and then activate it and only then launched the performance monitor. May I suggest that instead of doing an instant statistic updates one or 2 times/sec, to make it more "historic", that is each 5 second for example, and especially with a trailing graph shows much more that the present window (5-10 seconds?). I feel that the user is likely not interested in the instantaneous statistics that are relatively uninteresting, more informative perhaps would be to measure on a longer time span to have an idea of "sustained performance" in time

PS. we plan to release a new beta version in a couple of days.

looking forward

[goldendragon]

So if Read Hit Rate sustains, you might check if Read Bytes (Cached) and Read Bytes (Total) change or not. If they don't change, then there is no read commands sent to our driver layer. This is possible because windows itself has file cache mechanism acting before ours. And please note the statistics starts from the time that the monitor dialog opens, not from the time that computer boots up.

SIMPLY NO: your statistics report 35-40% hit rate even when there is NO I/O whatsoever: the application generating I/O is stopped, no activity going, not even a defragmenter. It was so with beta 0.3, the same with beta 0.4

[Support]

SIMPLY NO: your statistics report 35-40% hit rate even when there is NO I/O whatsoever: the application generating I/O is stopped, no activity going, not even a defragmenter.

The hit rate is always and simply calculated by the below formula,
Read Hit Rate = Read Bytes (Cached) / Read Bytes (Total) * 100%

This means that the Hit Rate is a calucated value and always showed if the Read Bytes (Total) is not zero. If both the Read Bytes (Cached) and Read Bytes (Total) are not changed, then the Hit Rate sustains. So if it reports 35~40%, then there must be data read during the statistics period.

Does the above apply to your question?

[magic-man]

Windows itself is constantly performing IO, even when nothing else is going on. That will cause cache hits...
If in windows 7,. look in task manager performance monitor... The SYSTEM thread is always up to something...

[magic-man]

Here is my updated stats for version 0.4.0... 3 Gig disk Cache, 30 second write delay, Vertex LE SSD...


As you can see, my system has been running most of the night... Primarilly engaged in web surfing and running the heck out of 2 virtual machines at work (stress testing the servers)...
VERY NICE! I am using LRU, which seems best on the host when running virtual machines in VMWare...
This really saves on the little writes to the SSD!

[mememe13]

The hit rate is always and simply calculated by the below formula,
Read Hit Rate = Read Bytes (Cached) / Read Bytes (Total) * 100%

About that. My win8 machine went through a couple of sleep cycles and now the graphs wont show anything. They dont even move, and the stats show that there is no IO even if i copy and read files.
Is there anyway i could get you a process dump or some other debugging info? I'd really want to see the numbers moving there. Do i need to log a bug somewhere?
This issue is temporarily fixed if i restart the machine.

Btw, i am a programmer, so feel free to use technical vocabulary.