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?
30 Day update...
30 Day update...
Last edited by magic-man on Mon Dec 20, 2010 9:07 am, edited 1 time in total.
Re: 30 Day update...
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.
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.
-
- Level 1
- Posts: 4
- Joined: Wed Nov 10, 2010 9:20 am
Re: 30 Day update...
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
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
Re: 30 Day update...
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.
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.
-
- Level 1
- Posts: 4
- Joined: Wed Nov 10, 2010 9:20 am
Re: 30 Day update...
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 timesupport wrote:And please note the statistics starts from the time that the monitor dialog opens, not from the time that computer boots up.
looking forwardsupport wrote: PS. we plan to release a new beta version in a couple of days.
-
- Level 1
- Posts: 4
- Joined: Wed Nov 10, 2010 9:20 am
Re: 30 Day update...
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.4support wrote: 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.
Re: 30 Day update...
The hit rate is always and simply calculated by the below formula,goldendragon wrote: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.
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?
Re: 30 Day update...
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...
If in windows 7,. look in task manager performance monitor... The SYSTEM thread is always up to something...
Re: 30 Day update...
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!
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!
Re: 30 Day update...
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.support wrote: The hit rate is always and simply calculated by the below formula,
Read Hit Rate = Read Bytes (Cached) / Read Bytes (Total) * 100%
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.