[2017-05-27] PrimoCache 3.0.0 Beta is available now!

First hand news related to PrimoCache
Axel Mertes
Level 9
Level 9
Posts: 180
Joined: Thu Feb 03, 2011 3:22 pm

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by Axel Mertes »

RobF99 wrote:Here is a problem that has always existed and is further accentuated now with L2 Write cache....

I have a 30 Gb write cache for L2. My L1 is 1 Gb. Delay write 120 seconds - but the problem happens with smaller numbers and even larger e.g. 600 seconds.

I process a lot of images via batching in photoshop. e.g. 1000 X 1 Gb TIF files. When I save files at the beginning they save fast because they are writing to L2 - when it comes time for Primocache to write the data to the hard drive - whether 60 seconds, 120 seconds or 600 seconds - all other operations on the hard drives stop as it waits to write the data to hard drive (sometimes as much as 20 Gb). So my batching pauses for up to 20 minutes as it writes the data the hard drive. I can't even browse a folder or do anything while it write the L2 cache. In the end my overall time taken is the same as if I did not use Primocache - because no othe operations seem to be able to happen as it flushes the write cache. Using Windows 7 64 bit. The disk queue length is around 5 as it is writing. It looks like this write operation takes "exclusive" priority over the drive as it flushes and certainly takes priority over read operations on that same drive until ALL data is flushed.

Initially it will write 4 to 5 files per minute to L2 cache - when when it flushes I can wait for up to 20 minutes as it flushes.

Something needs to be done to lower the priority it takes over the hard drive. Can this be done as background? This might solve the problem.
I can only imagine that this hurts. My caches are fairly large, so I usually don't end up in such a scenario. I currently employ a 64 GByte L1 and a ~2 TByte L2 cache...

Anyhow, it sounds a bit like you were writing data at a fairly high data rate. When your cache is smaller than the total amount of data written plus you are writing data faster than the target drive can sustain, caching will never help.

However, it might be the case that you are right and that no write operations toward L1 cache are accepted while flushing the cache to disk. If that is true, it should be changed - obviously. Any block written from L1 or L2 to disk can be free'ed up, so the flushing should not exclusive block everything, but free up block by block to further accept new write operations. Those will run into cache only at the speed of the flush to disk itself, but that would be better than not accepting data. Anyhow, this is really speculating, as I can't reproduce the situation on my system right now. After all, it sounds like you cache is way to small.

Do the math:
How many files are you writing in total?
How big they are?
How long does it take?
What is the maximum speed your (uncached) drive can sustain?
Use e.g. ATTO DiskBenchmark for this to measure.

If - after all - the amount of data is so high that it more or less fills the drive with I/O during the whole batch processing, you won't really accelerate it with a cache - except the cache is larger than the total size of the files. You may see a bit optimized read vs. write operations. Depending on your drive fragmentation, that would not really help. I strongly recommend defragmenting the drive regularly (every night for instance), that improves I/O strongly too.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by RobF99 »

I would consider myself an expert with this program and have used it religiously for 2 years now. I know what I want it to do and I do have a 30 Gb write cache and sometimes even dedicate the entire 250 Gb to read/write operations. It doesn't matter even with 250 Gb - if it is flushing the cache even as little as 3 Gb of data - the entire drive locks up from read operations while it is flushing the cache - even using average as a write strategy - which is supposed to lower the rate at which data is flushed. I don't know a lot about coding but I would say that the system is considering that I/O for flushing as something that cannot be interrupted or not interruptible for other I/O for the drive or as one I/O operation. The program should behave just as you mentioned where it continues to be able to add to the cache as it is flushing the cache. It probably already has the capability to do that.... but I think it is the read operations not being able to happen that prevents data to be written to the cache because you cannot even browse a folder on that drive while it is flushing.

I think also that the program should have an additional write strategy - Instead of say flushing the the cache every XX seconds - that it should also have the option to discretely delay a write operation.... e.g. If I saved a file the program should allow a delay of XX seconds to flush that particular write operation instead of flushing the entire cache every XX seconds. I think this would work better too as the flushing strategy would be a FIFO type strategy and other I/O could be appropriately queued among those I/Os. I hope support reads this and considers implementing such a strategy.
User avatar
Nina
Level 4
Level 4
Posts: 38
Joined: Sat Jan 29, 2011 2:21 pm

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by Nina »

RobF99 wrote:I would consider myself an expert with this program and have used it religiously for 2 years now. I know what I want it to do and I do have a 30 Gb write cache and sometimes even dedicate the entire 250 Gb to read/write operations. It doesn't matter even with 250 Gb - if it is flushing the cache even as little as 3 Gb of data - the entire drive locks up from read operations while it is flushing the cache - even using average as a write strategy - which is supposed to lower the rate at which data is flushed. I don't know a lot about coding but I would say that the system is considering that I/O for flushing as something that cannot be interrupted or not interruptible for other I/O for the drive or as one I/O operation. The program should behave just as you mentioned where it continues to be able to add to the cache as it is flushing the cache. It probably already has the capability to do that.... but I think it is the read operations not being able to happen that prevents data to be written to the cache because you cannot even browse a folder on that drive while it is flushing.

I think also that the program should have an additional write strategy - Instead of say flushing the the cache every XX seconds - that it should also have the option to discretely delay a write operation.... e.g. If I saved a file the program should allow a delay of XX seconds to flush that particular write operation instead of flushing the entire cache every XX seconds. I think this would work better too as the flushing strategy would be a FIFO type strategy and other I/O could be appropriately queued among those I/Os. I hope support reads this and considers implementing such a strategy.

+1
Totally agree with you.

BTW, the oldie FancyCache with "Averaging Write Amount" activated, is much better than PrimoCache in WOs if I remember correctly.
minhgi
Level 10
Level 10
Posts: 255
Joined: Tue May 17, 2011 3:52 pm

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by minhgi »

RobF99 wrote:I would consider myself an expert with this program and have used it religiously for 2 years now. I know what I want it to do and I do have a 30 Gb write cache and sometimes even dedicate the entire 250 Gb to read/write operations. It doesn't matter even with 250 Gb - if it is flushing the cache even as little as 3 Gb of data - the entire drive locks up from read operations while it is flushing the cache - even using average as a write strategy - which is supposed to lower the rate at which data is flushed. I don't know a lot about coding but I would say that the system is considering that I/O for flushing as something that cannot be interrupted or not interruptible for other I/O for the drive or as one I/O operation. The program should behave just as you mentioned where it continues to be able to add to the cache as it is flushing the cache. It probably already has the capability to do that.... but I think it is the read operations not being able to happen that prevents data to be written to the cache because you cannot even browse a folder on that drive while it is flushing.

I think also that the program should have an additional write strategy - Instead of say flushing the the cache every XX seconds - that it should also have the option to discretely delay a write operation.... e.g. If I saved a file the program should allow a delay of XX seconds to flush that particular write operation instead of flushing the entire cache every XX seconds. I think this would work better too as the flushing strategy would be a FIFO type strategy and other I/O could be appropriately queued among those I/Os. I hope support reads this and considers implementing such a strategy.
I found out just letting primocache decided when to flush the deferred write by itself I don't have any long pause. L2 shared cache / average write / normal 10 sec. dedicate l2 write seem to hold cache way to long if you have large defer time. When it time to write back to the hard drive, you see the long pause. I do work with data that can be up to 10 GB.
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by Jaga »

Davey126 wrote:Single data point: I have been running 3.0.x in Win10 x64 box for several months w/o issue. I did try to upgrade a creaky 32-bit XP machine from 2.7 to 3.0 but ended up with a delayed blue screen. I would not hesitate to deploy v3 wherever it is beneficial.
Just an update after upgrading Primo to the 3.0.0.1 Beta kernel in a production environment (with a fully backed-up machine):

Ran for 2-3 days without issue, then Windows 10 failed to start with a Critical Process Stop error (bluescreen on login). I have rectified the problem and the machine is working again, but I wanted to warn others that the current Beta may not be as bulletproof as we would want. I do not recommend using it in a production environment at this time. I am going to open a topic in the Support forum to give Romex details.
RobF99
Level 8
Level 8
Posts: 130
Joined: Fri Sep 19, 2014 5:14 am

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by RobF99 »

You can actually disregard my first post on this issue. I was using an external drive and the system I was plugged into was only performing at USB2 speeds and this was the reason for the long delay. I plugged the same drive into another system and my issue no longer existed and Primocache was behaving EXACTLY as I expected it to and did not pause for long amounts of time. It was properly flushing the L2 cache to the hard drive while accepting more incoming writes. So it behaved perfectly. I am sorry if I caused support to look for a problem that wasn't there.

I LOVE this program.
gotterdammerungly
Level 4
Level 4
Posts: 29
Joined: Mon Sep 29, 2014 2:04 pm

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by gotterdammerungly »

I have been using v.3 for a few days and it is working beautifully; seems better than v.2. No issues. The new features and options are most welcome. Can't really bear using a PC without Primocache now.
InquiringMind
Level SS
Level SS
Posts: 477
Joined: Wed Oct 06, 2010 11:10 pm

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by InquiringMind »

Jaga wrote:I'd simply like the ability to preload a folder/file by right-clicking it, and choosing the option from a Primocache context link. You could preload games, videos, whatever you wanted just before you used them, speeding it all up tremendously.
Installing the HashCheck shell extension will give you virtually the same feature. It will generate hashes for selected files (or folders) via right-click, which in the process would cause any selected files to be read into cache. If you want to automate the process (or load files from disparate locations) then create a checksum file with those files (using your favourite text editor to combine/edit previously created ones) and then run a checksum verification from command line/batch/script to load those files into cache.

Plus for data safety phreaks, you can never have too many checksums of your precioussss filessss.
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by Jaga »

I wonder how fast HaskCheck would run on say a... 5gb folder. Will have to test and see, then see if it's indeed all cached. The Windows cache still has the ability to interfere with Primo.

The answer is... roughly 15 seconds on a folder structure containing 16,961 (Windows compressed) files amounting to 6.23 GB. Going to have to do some benchmarking to see if they all actually made it into the cache.

Either way - thanks for the idea InquiringMind.
User avatar
Jaga
Contributor
Contributor
Posts: 692
Joined: Sat Jan 25, 2014 1:11 am

Re: [2017-05-27] PrimoCache 3.0.0 Beta is available now!

Post by Jaga »

Quick update on the MD5 hash technique to read into cache:

Attempted this with the same directory of files, after clearing Primo's cache contents on the volume. Turns out that either Windows is handling the caching on those files, or Primo is ignoring the MD5 comparison, as the read values on the volume do not go up at all when MD5 verifying 6+ GB of files.

I think a bit more testing will be involved. I'd still prefer a way to request Primo handle the caching, instead of leaving it up to Windows.
Post Reply