Primocache stops writing to L2 after a while

[Pentium100]

I think that the problem is in the L2 algorithm. While L1 is written immediately after reading the requested block, L2 is written some time after reading (and requires a second read). Essentially, if I could trick PrimoCache into thinking that my SSD is actually RAM, it would work perfectly.

[Jaga]

-removed by author-

[bd2003]

I think that the problem is in the L2 algorithm. While L1 is written immediately after reading the requested block, L2 is written some time after reading (and requires a second read). Essentially, if I could trick PrimoCache into thinking that my SSD is actually RAM, it would work perfectly.

Agreed. I think it's just a flawed algorithm. There is no reason to delay writing to the L2 cache until the source disk is idle. It's literally the only SSD caching software that does this...every other one I've tried caches immediately to the SSD after a read.

It would be somewhat tolerable if it at least read at a reasonable pace, but it just does these little bursts. My guess? The act of reading from the source drive to cache to L2 is the very activity that trips the idle detection. Hence the bursty behavior.

[Jaga]

-removed by author-

[Bjameson]

Since SATA channels are fully capable of independently and asynchronously reading and writing to different channels, I see no reason for any L2 delay at all. Why tune the algorithm? Remove it altogether please. It's an obstacle, not a feature. OK I understand that separate threaded read/write modules are exceptionally difficult to implement. Yet the 'traffic light' algorithm now used to control the data flow will keep degrading the cache performance, no matter how much you try to improve it.

[Davey126]

Disappointing support has been silent on this matter. I have deferred making additional purchases and I am considering other options as the storage landscape continues to change. Spinning platters will be part of the solution for awhile but declining SSD prices allow some configs to balance speed and capacity without a dedicated caching solution. If it worked perfectly I might consider Primocache for L2 but I don't care to wait and test future fixes that should be part of the current solution. I have a few registered copies which I use exclusively for L1; no problems there.

[idefix44]

Since SATA channels are fully capable of independently and asynchronously reading and writing to different channels, I see no reason for any L2 delay at all. Why tune the algorithm? Remove it altogether please. It's an obstacle, not a feature. OK I understand that separate threaded read/write modules are exceptionally difficult to implement. Yet the 'traffic light' algorithm now used to control the data flow will keep degrading the cache performance, no matter how much you try to improve it.

So what about my old rig and its PATA bus?
My PrimoCache target is my "Operating System and Applications" partition and I use a registred version without problem with the filling of L2 wich is on a PATA SSD partition...

[BikeHelmet]

So what about my old rig and its PATA bus?
My PrimoCache target is my "Operating System and Applications" partition and I use a registred version without problem with the filling of L2 wich is on a PATA SSD partition...

Clearly it needs to be a selectable option.

L2 Write Behaviour
Idle (current)
Normal (Writes on second read, then gets more selective as cache fills up?)
Aggressive (Writes on second read, always, then aggressively junks old cached data for more frequently used new cached data?)

-BikeHelmet

[piquadrat]

Since SATA channels are fully capable of independently and asynchronously reading and writing to different channels, I see no reason for any L2 delay at all.(...).

Well, it is not so simple. If one wants to read from the volume and write to the cache at the same time the speed of such operations should be equal. If not, some kind of buffer (probably in the RAM) has to be implemented and it will grow in the sequential transfers in uncontrollable manner. That means the final read sequential speed from the volume is the lower one from two values: ssd write and volume read speeds.
Many ssd's used by the consumers today are very asymmetrical with low sequential write (100 MB/s). In such cases deffer sync is beneficial because it will not cripple non_cached_already_reads to that 100MB/s of ssd write capabilities.

But I agree, this behavior should be switchable.

I have fast (sequentially) RAID-0 volume capable of beyond 500MB/s reads/writes but yet see the benefit of using ssd drive as a cache even if it has 250MB/s writes. For me deffer sync is optimal because i can read non cache data with 500MB/s (not 250MB/s like in competitors' solutions) and getting fast 4KB performance for cashed data at the same time.
But I see the scenarios (high continuous throughput) where this implementations shows its weakness.

IMO the user should choose which cache sync strategy prefers.

[Davey126]

This tread has been silent for awhile. Curious if support has been able to duplicate the L2 write concerns previously reported and if so whether there will be a fix or remediation in future versions.