Romex Software Forum

With this new version (0.6.0) I see you changed how deferred writes are done... Fancycache seems to be spreading them out over a long time. Fine for someone with deferred writes on a USB thumb-drive or a slower system, BUT...
I have a high end laptop with Windows 7 and real fast SSD drives and have never had any freeze ups due to waiting for writes... I noticed that the deferred writes only go out at a max of 2 megs per second, which is less than 1% of the write speed of my drive (which is 275 Megs per second). Is there any way we can make the writes a little more aggressive????
I know some had issues with 0.5.0 pausing their machine during writes, but I never saw that problem. Can we make it configurable or write faster for those of us wo are using SSDs??

Thanks!

I would like to propose a simple solution for those of us that do not need the driver to throttle the writes and to also allow those who DO need it to be able to optimize them for their system:

Put a flag called "Throttle Writes" (default off), then a percentage box that would allow them to set the percentage to throttle by such as 10%, 25%, 50%, 75%, 90%, etc (suggest default if flag is on at 50%). This would be on a per drive (or volume) basis just like the other settings.

That way if I used it, I would have no throttling needed... Another with a slower system could set it to 50%.... USB flash drives could set it to 90%...

Yes, we changed the algorithm of Defer-Write to smooth the write. The new alogrithm detects the disk activity, as well as balances the writing load during the latency time. The goal is to prevent the computer from possible lack of response while doing timing write-flush, especially when there are other active works at the same time.

magic-man wrote:I noticed that the deferred writes only go out at a max of 2 megs per second, which is less than 1% of the write speed of my drive (which is 275 Megs per second).

How do you measure it? Did it affect the real performance, such as the work becomes slow or the testing results by the benchmark tools is not good as before?

Another way, perhaps you might try to reduce the latency. With the new algorithm, the latency can be set to a smaller value than before.

Of course, if this new algorithm isn't good as expected, we can do as you suggested.

Thanks.

support wrote: Yes, we changed the algorithm of Defer-Write to smooth the write. The new alogrithm detects the disk activity, as well as balances the writing load during the latency time. The goal is to prevent the computer from possible lack of response while doing timing write-flush, especially when there are other active works at the same time.

magic-man wrote:I noticed that the deferred writes only go out at a max of 2 megs per second, which is less than 1% of the write speed of my drive (which is 275 Megs per second).

How do you measure it? Did it affect the real performance, such as the work becomes slow or the testing results by the benchmark tools is not good as before?
Another way, perhaps you might try to reduce the latency. With the new algorithm, the latency can be set to a smaller value than before.
Of course, if this new algorithm isn't good as expected, we can do as you suggested.
Thanks.

The way I monitor the IO is with a Windows 7 gadget that monitors / graphs all IO going to and from the controller. It is called Drive Meter from Hansolav...
URL: http://gallery.live.com/liveItemDetail. ... &bt=1&pl=1
It is not slowing my system down, just not using any of the available band width to the drives.... Strange that the algorythm picked 2MBS max... In pulses of about 1 second... I wonder if the algorythm is seeing Windows 7 flashing the drive light once a second (for the CD ROM detect) and thinking it is activity?
Please don't base your opinion of the algorythm on just my feedback (I liked version 0.5.0)... It might be better for others... Not everyone wants to use it strictly for SSDs...
If possible and if not too hard, can we look at the suggestion or a way to make it send more at a time?

I also notice that since I have my latency optimized for my work load, that this new algorythm results in more deferred urgent writes as opposed to 0 in 0.5.0 with the same latency (600 seconds)

Here is a screen shot of how it looks now when flushing the buffer and what it looked like before (yellow lines are writes, green are reads):
Now (0.6.0):


Then (0.5.0):


Thanks!

magic-man wrote:It is not slowing my system down, just not using any of the available band width to the drives....

So I think this shall not be a real problem, right? The old algorithm might use up the the band width to the drives at the right time of the latency expired. This is easily to cause the current active work into slow response. Instead, the new algorithm averages the write amount during the latency time.
PS. the new algorithm doesn't degrade the write performance even when there are lots of the write requests, according to our testing results. It still will fully use the available band width of the drives when necessary.

magic-man wrote: I wonder if the algorythm is seeing Windows 7 flashing the drive light once a second (for the CD ROM detect) and thinking it is activity

no. We have other internal judgement.

support wrote:I also notice that since I have my latency optimized for my work load, that this new algorythm results in more deferred urgent writes as opposed to 0 in 0.5.0 with the same latency (600 seconds)

How about reducing the latency? Perhaps you might try the half of the old latency, that is 300 seconds?

support wrote:

support wrote:I also notice that since I have my latency optimized for my work load, that this new algorythm results in more deferred urgent writes as opposed to 0 in 0.5.0 with the same latency (600 seconds)

How about reducing the latency? Perhaps you might try the half of the old latency, that is 300 seconds?

I will give it a try...

Can you tell me what size blocks the new algorythm is writing at a time to the SSD?

Ok, let me explain it more clear.
Simply speaking, as you saw in your monitor, the new algorithm averages the writes based on the deferred write amount and the latency. So the amount at a time to the SSD is not fixed, besides it adjusts the amount according to the disk activities.

I am using fancyCache for Volume, write only, 40000 sec latency. I only flush the writes before doing a back up or on shut down. With ver .6 when I click on flush writes, it will write a few hundred megs then stop. I have to reboot to force fancy cache to finish flushing the cache so that I can do my backup and move on. If there could be some way to override the throttling, it would sure help me. I often have large temp files open that I would like to avoid writing to my SSD, so I don't want writing to happen until I am ready, thus the long latency.

shiraz wrote:I am using fancyCache for Volume, write only, 40000 sec latency. I only flush the writes before doing a back up or on shut down. With ver .6 when I click on flush writes, it will write a few hundred megs then stop. I have to reboot to force fancy cache to finish flushing the cache so that I can do my backup and move on. If there could be some way to override the throttling, it would sure help me. I often have large temp files open that I would like to avoid writing to my SSD, so I don't want writing to happen until I am ready, thus the long latency.

Or perhaps a throttle flag and bercentage as suggested above?