How is ExpressCache 1.3.2 working?

AlleyViper - thanks so much for your response.  Just followed your instructions (which were very easy to follow!), and I’m hoping for a good result!  Will report back to let you know how it went.  Thanks again!

Ok so capped my readycache partition at 16Gb using the below instructions:

  1. From the command line: ECCmd -format (this will clear the information out of the cache)
  2. Delete the partition (this is done from the Disk Management pain by right clicking on the drive and selecting “delete” the partition
  3. From the command line: ECCmd -partition (drive number) 16384 (this will create a partition of 8GB in size)
  4. From the command line: ECCmd -format (this will format the new partition and make it ready for EC/RC to utilize)

Here is a shot from ExpressCache -

Here is my sub 1 minute boot to desktop -

Here is my very long boot just to login screen before partitioning to 16Gb -

So far so good!!! I will update if things change.  Sandisk needs to fix this problem!!!

rlewandowski23 that’s strange, using -partition # 16384 gives me an exact 16GB total on the GUI. About 12-14GB will be filled then.

Good luck to anyone who tried and can post her/his findings. I’ll be away from my test machine for a couple of weeks.

I used eccmd -partition (drive # shown in diskpart, in my case 1) 16384 , and ExpressCache splash screen, eccmd -info, and MiniTool Partition Wizard all show a 16.0 GB partition.   Maybe you typo’d 18384 – that’s very close to the 18432 of an 18 GB partition.

I’d leave it be at 18 GB – my memory is that AlleyViper was the only person obsrving delays as low as 17 GB, other reports were 23 GB and up.   If you can, let us know what happens as you fill past 17 GB.

Is this product not compatible with VMWare?

Whenever i start my VmWare, my hdd starts to read or write somethings like crazy and after a while either it freezes or it tries to continue like normal (but not normal…)

Just a thought:

As I look over the delay problems reported in this thread I’m not so sure they are specifically related to firmware 1.3.2 as much as the general issue of overprovisioning of an SSD.   For those needing an intro to the subject here is a good one written by an LSI/SandForce guy: .

My thought is this:  Suppose Sandisk offered this same caching SSD product in a 64 GB size with a 32 GB active partition.

The retail cost should only be about $20 more than the current product.  Considering how much caches get written to and how much housekeeping is involved over time, i’d pay an extra $20 for a “double provisioned” 32 GB cache with both increased performance and longevity.

Yea your right I did typo that.  I did do an 18Gb partition.  The partition command I ran was - ECCmd -partition (drive number) 18432 .

So far my cache has filled up to 14Gb.  But, I haven’t loaded any PC games or anything yet.  Do we know what the max cache partition size we can use before we will start seeing problems?

NWGuy the thought about the drive being too small and it should be larger and overprovisioned makes tons of sense.  The OCZ Synapse drive that I had was setup that way.  It was a 64Gb drive that was overprovisioned to 32Gb.  I was wondering why ReadyCache wasn’t setup that way.

I thought I was getting a better drive that was better supported via software by replacing my OCZ synapes (which uses the now defunct dataplex software) … overtime I am discovering that may not be the case :(.

I think think the Sandisk / Condusive ReadyCache product is good.    Especially since the release of the 1.3.2 software update, there have been relatively few bug reports.

17 GB fill of the default 29.xx GB partition is the lowest reported fill where delays occured, that was AlleyViper.   All the other reports I found started at just over 23 GB, there were several in the 23.xx range, and then up from there.    It bears noting that the cache is still working at 100% fill for almost everyone, the task is mostly just trying to improve performance at this point.

Just to clarify, when I posted that delay with only 17GB cached it was due to a Win logo freeze at the usual point, but it was way shorter (only about 2-3s) than annoying ones with >22GB filled. They seem related, anyway.

Also, after reducing the caching partion I’ve had no more casual freezes later in the boot with stuck hdd led lit. Those happened when cache was near full.

Most probably, a 2/3 ssd size cache partition should be near the limit before trouble happens for most, given that it won’t fill completely. I still hope most issues can be solved either by software, or a ssd firmware update.

1 Like

Resetted cache twice, still hang-in on windows boot.

1 Like


When will 1.3.3 be coming out to address these boot delay issues?


Hooked it up to my raid card to see if that works better again:P I just disappears after a while and sets the raid alarm off, so I guess its rma time:P

mattschnaidt, rlewandowski23, NWGuy, and anyone that tried a cache size reduction: did you also notice any improvements after this time of testing?

With my cache drive capped at 18Gb I haven’t had any problems yet.  I wish sandisk would fix this so I didn’t have to cap the drive. Honestly, it’s beginning to seem like a design flaw and they should have made it a 64Gb drive that is overprovisioned to 32Gb.

This is exactly what my OCZ synapse drive I used to use did.  Honestly, Sandisk should just release a new drive and give us all discounts on a new one if we send the old one in.

I tried “Preview” before submitting a long post and could not find a way to edit the post further, in so doing lost the post – out of time to type it all again now.

So without explanations, my recomendation for anyone experiencing what they feel are excessive boot delays are to try a partition size of 25Gb (25 x 1024 = 25600) using one of the methods previously discussed in this thread.  That may be the largest cache size you can use to reduced this problem if you are experiencing it.

Regardless of partition size one uses, occasionally seeing the Windows logo for up to two revolutions of the dots is part of normal cache operation.  Testing continues, I have two of these in different machines now now, one will remain at the original 29.xx Gb partition  and one will vary.

I’ve given more thought overprovisioning since I mentioned it as a possible way to reduce cache housekeeping delays.  If I personally bought a 64 Gb SSD cache drive, I’d probably run it in the 50-60 Gb range rather than half of that to overprovision.    In other words I’d accept reduced longevity and occasional housekeeping delays to gain additional files cached.

Another issue is marketing.   Although one could justify overprovisioning a small SSD used as a cache due to the relatively low total cost of going from 32 to 64 Gb of NAND, what about a 1Tb SSD?    How are you going to sell increased reliability for one product and not another?   I can see it for ‘mission critical’ enterprise level cost relatively no object installations but for the home market, “I can give you TWICE the storage for the same money” would be impossible (IMO) to beat.

Yea that would be an unfortunate design flaw if its failing because the relatively cheap controller it uses can’t keep up with all the writes when full, causing resets or whatever.

That being said I never got close to full on mine after a while, so I guess it failed.

I don’t think it’s the controller, it should easily be able to keep up with LBA requests.   I agree with AlleyViper, this is most likely a Condicive software glitch.    My hypothesis is that something is that some permanent or temporary data array is, under some circumstances,  running out of pre-allocated or available space, or possibly some numerical value is exceeding type allowd value (not likely these days).

Two things that can negatively affect caching performance:

Security software scans.  We all (hopefully) do a quick scan each boot, and probably idle time scans – and every so often I scan every single file, archive, etc.   This makes the cache record lots of LBAs many of which are otherwise rarely read.

Defragging moves data from one LBA to another, cache has to adjust to new read patterns.   Active defraggers that try to move files around in real time to keep them contiguous generate  ‘spurious’ (from a caching perspective) LBA reads and change which LBAs hold which data, again forcing the cache to reorder/reprioritize.   

I re-formatted my PC and installed Windows 8.1 with Update x64.  I thought I would give ExpressCache 1.3.2 another shot at working without modification.  But, once the cached filled up it start causing problems like my PC taking forever to boot up.

I took the suggestion above and capped my cache at 25Gb.  That has helped.

Sandisk when is this going to get fixed!!!  This is taking way too long to release updates for this product.

Well, to finally confirm it: after >month and a half of use with only 16GB this computer exibited no readycache related problems. No winlogo temporary freezes or later catastrophic system freezes while running windows with near full cache. I’ll try a 3/4 full drive now (22900KB) excluding again dedicated storage and download drives (torrents mess up cache badly by creating too much cached activity, wich leads to a quicker purge of more important system data). As I’ve had repeated trouble with only about ~22-24GB filled, I’ll undershoot 25GB a bit more than suggested.

I’ve used for a short time a laptop with a 24GB mSATA cache drive using readycache, and there seem to be no issues. This ssd almost full all of time, because on one partition it held hybrid boot data (maintained by other program), and the remaining ~16GB were kept close to full.

Then again, I guess overprovisioning should yeld better IOps (specially on writes) and drive longevity for wear leveling, but such freezes on startup that take a lot of seconds seem more related to a software fault (as NWGuy pointed) than the added latency of a non-optimized SSD/weak controller. Hence why less cached data up to some 20-25GB might strain less the software.

I also believe that many cache reset problems can be due to windows updates, file scans, scheduled defrags, hours of torrenting + moving files, that cause havoc on the LBA list, leading to an expected total resynch.