Performance drop with deferred writes active

[slapo]

Good day,

I've just recently discovered FancyCache and it seems to quite nice, except for one issue. FancyCache Volume 0.4.1 is the one I use.
When benchmarking with CrystalDiskMark, there's a strange fluctuation of results before they stabilise on an average.
When using it, it seems some stuttering occurs from time to time, usually after launching a new app or working with files that haven't been used in that session before.

In ATTO, the results seem to be in line with the stuttering mentioned for block sizes above those the cache is set to.

Here are a few screenshots:




Partition on which FancyCache has been disabled:


Partition with FancyCache and deferred writing enabled:


Partition with FancyCache enabled and deferred writing disabled:


Whether I activate the L2 cache or not doesn't seem to really influence the results in a significant manner.
Disk E: used for the L2 cache is a USB stick.
The drive benchmarked is ST3250820AS, an older Seagate model. I got a similar drop in performance with a WD6400AAKS, though.

How does FancyCache determine the cache size it suggests?
It had suggested a gigabyte before I changed the settings as you can see them in the screenshots.

I have experienced similar stuttering with FlashFire when I have chosen that I prefer stability to performance. Not that it helps, although the sources of FlashFire are available now and the project seems to have been abandoned by the dev or at least there have been no new releases for quite some time, which is a pity.

Would it be possible to enable deferred cache for removable drives? I suspect this could help performance of cheaper (thumb) drives quite a bit.

Thanks

[Support]

Hi,

Thank you for your feedback.

The performance has been improved greatly in the next version. We'll release the new version soon.

[slapo]

Hello,

that's good news, thanks

Would it be possible to enable deferred cache for removable drives?

Cheers.

[horizon]

This would be a risky feature. And not sure, if this is good idea. (Even Windows itself, prefers not to cache writes for removable storage by default.) ... so that "safe removal" of the device is not needed. (This is afaik since wxp. On olders systems the data loss was quite usual. )

--Lukas

[slapo]

This would be a risky feature. And not sure, if this is good idea. (Even Windows itself, prefers not to cache writes for removable storage by default.) ... so that "safe removal" of the device is not needed. (This is afaik since wxp. On olders systems the data loss was quite usual. )

--Lukas

If it makes transfers of smaller files faster, it might be well worth it - usb sticks are just rubbish when working with many small files.
I think a 1 second delay before writing could be sufficient and would reduce the risk of data loss compared to higher delays.

[magic-man]

This would be a risky feature. And not sure, if this is good idea. (Even Windows itself, prefers not to cache writes for removable storage by default.) ... so that "safe removal" of the device is not needed. (This is afaik since wxp. On olders systems the data loss was quite usual. )

--Lukas

If it makes transfers of smaller files faster, it might be well worth it - usb sticks are just rubbish when working with many small files.
I think a 1 second delay before writing could be sufficient and would reduce the risk of data loss compared to higher delays.

It MAY be worth it.. But... we also have to look at it from a PR standpoint For example, in other forums, I had some that complained about FancyCache (and ANY write cache), blaming the cache for the following complaint type:
"I lost data with the write cache enabled. Must be the cache softwares fault"... Problem is, that they had issues (BSOD) without the cache.
My recomendation to those who want to use the write cach (like me) is as follows:
If you system is already stable with no issues like lockups, AND (BIG AND), you have a good backup strategy (prefer automated), then GO FOR IT!!!!!!

[slapo]

It seems that in 0.5.0, FancyCache can be enabled on removable devices. I've tried it with my cheap USB stick and it seems to help quite a bit when transferring directories with heaps of small files. I've tried it with Liferay Community Edition packaged with Tomcat. After roughly a minute, when FancyCache was disabled, there was still only a puny bit of the progress bar visible and the estimate was 19 minutes. With FancyCache enabled, after the minute the transfer seemed to be in 1/6 already and the estimate was about 6 minutes.

I'll try to benchmark this later on, perhaps using FastCopy.

ATTO benchmarks have improved as well as the real usage experience - there is no stuttering with the Seagate HDD anymore. However, if ATTO can be trusted, it seems smaller block size reads suffer if the cache size is exceeded. I'll try to post results of those benchmarks when I get to run them again.

[Support]

Hi slapo,

Thank you for testing again.

Here is a notice for read performance,
viewtopic.php?f=25&t=706

[slapo]

I've tested the Seagate drive mentioned in my original post. Here are the settings:


I kept them the same, except I switched deferred writes on/off and changed the caching strategy. What change has been applied can be seen in the Description in the screenshots below. I didn't use the L2 cache this time, as it seems FancyCache tried to fill it first before using the RAM cache, as ATTO practically locked up when I enabled a USB stick as an L2 cache. I have also included a screenshot with FancyCache quite disabled for reference.