Why is there a delay between reading and caching?

[bd2003]

I've been trying to find just the right caching software, but primocache has some very odd behavior. Using just an SSD to accelerate a HDD, with most caching software (intel RST, veloSSD, etc) - when you read from the HDD, the data is simultaneously written to the SSD cache. After clearing the standby/windows cache with rammap to factor that out, if you read the same data immediately again, it's already in the cache.

But with primocache, it doesnt write anything to the L2 cache immediately. Instead, it will wait until the source disk is idle, and then start filling in the L2 cache in little bursts, redundantly reading it again from the source HDD. It's incredibly slow....averages like 20mb/sec. What's the point of this? Any SSD is going to outstrip a HDD in reads/writes, so the caching can't possibly stall the reads. And after having been read, the data resides in the windows standby cache, so why does it even need to hit the disk again?

From reading the site, I gather this is done in an attempt to not block access to the source drive:

PrimoCache keeps track of use frequency for all data blocks in underlying slow disks. And when system is idle, PrimoCache will store high frequently used data blocks to level-2 cache. If system is busy, such store process will not happen in order not to slow down other Windows tasks.

But how can that possibly happen anyway, given that the speed of an SSD is practically guaranteed not to bottleneck a HDD? I cant think of any scenario where this will be an issue.

Also, why can't an L2 cache writes? It's likely that any data written will be accessed again...isnt the whole point of the cache to speed up accesses? If I install a new program, shouldn't it be presumed that I'm going to access it, and thus want it in the cache from the start?

[InquiringMind]

But how can that possibly happen anyway, given that the speed of an SSD is practically guaranteed not to bottleneck a HDD?

Given SSD's have 300-500MB/s write speed and HDD's 150MB/s, it's very much the reverse. Populating L2 at full speed would certainly bottleneck the HDD until L2 was filled. If you had, say, 256GB L2 configured, populating that at maximum HDD speed would take about 25 minutes during which the system would be largely unresponsive (as if the disk had been disconnected).

Also, why can't an L2 cache writes? It's likely that any data written will be accessed again...isnt the whole point of the cache to speed up accesses?

It can and should, but L2 data needs to be written to disk also when time permits to avoid data loss or corruption in the event of a system crash. As long as the cached copy is used for subsequent reads, you should get the best balance between performance and reliability.

[bd2003]

But L2 only caches reads...so it can't possibly be populated at a speed any faster than the HDD can read. I just don't see how it can be a bottleneck unless writes to the SSD are slower than reads from a HDD. If that's the case, you really need a new SSD.

[Pentium100]

Given SSD's have 300-500MB/s write speed and HDD's 150MB/s, it's very much the reverse. Populating L2 at full speed would certainly bottleneck the HDD until L2 was filled.

It should populate L2 at the same speed that the HDD is read by the user software, essentially, it should do something like this (simplified pseudocode):

Code: Select all

function readblock (addr); //gets called by user software when trying to read a block from the hard drive
if (addr in L2) return ReadL2(addr)
else {
     data=ReadHDD(addr);
     WriteL2(addr,data);
     return data;
     }

So, if I read a file from the hard disk it should be copied to L2 at the same time I read it, so if I access the file a second time it should be all in L2 (assuming L2 has enough space).

Currently PrimoCache works like that when dealing with L1. However, for L2 it reads the hard drive a second time at low priority to fill the cache.

[bd2003]

Exactly. What is it waiting for?

Honestly I think way too much attention is paid to the rather pointless and redundant L1 cache, while the super useful L2 cache is given the short end of the stick.