When running a benchmark using the program AS SSD on an NVMe drive, When the second checkbox seen in the image below is unchecked, the drive gets terrible write performance in AS SSD (see first benchmark screenshot below), but not in CrystalDiskMark (see last screenshot); however, if I check that box, then AS SSD performs well. Does anyone know what's going on here? My concern is that according to that checkbox description, I should NOT have it checked since my drive doesn't have its own power supply, but AS SSD is so slow, I'm concerned other programs may be affected.

In case it's helpful, I learned about that checkbox in the first place from reading https://www.reddit.com/r/Dell/comments/628odr/toshiba_nvme_slow_write_speed_fix/, but this doesn't explain to me why CDM would still be fast. See also Slow SSD performance (Toshiba 1GB NVMe). I updated my Intel RST drivers and that didn't help.

I understand there could be a roundabout driver solution here, but I want to stay within warranty and try to find out what's going on so I can get Dell to support this and issue an official solution.

enter image description here enter image description here enter image description here enter image description here

  • I don't trust the benchmark. Are you sure it understands NVMe? I'd just ignore the benchmark. Commented Jun 3, 2017 at 3:01
  • 1
    don't check that unless you really don't care to reformat the SSD daily (without recovering any data from it). See my answer. Commented Jun 3, 2017 at 9:56

2 Answers 2


Usually data losses may only be possible in cases of faulty hardware or unclean shutdowns (sudden power outages, heat protection kick-ins, BSODs, etc.). But many programs are aware of that (all programs which are designed with safety in mind) so, for example, they don't just overwrite data in place: they create a new file, write data there, flush cache to ensure it's written, then remove the old file.

Without this checkbox, if failure occurs at any point, you'll always have at least the old version of data.

When box is checked (without buffer flushing), in case of power failure or sudden reset, data losses may be vast and uncontrollable, you may even lose data unrelated to files being written because file-system updates occur with same principles. You may even completely lose all data on the volume, if failure occurs in an especially unfortunate time. Even worse: in some cases, you may lose data on clean shutdown/reboot, if drive doesn't flush cache on its own before reset.

Because of that, disabling buffer flushing without independent power supply for the drive is playing with fire. If you're using SSD for non-original data (caches, mirroring of slower storage for fast access, non-original program files, Steam or other means of games installs, etc), and willing to risk it (though in case of steam, beware of loosing savefiles, depending on where games put them), you may check that. But expect catastrophic failures occasionally (especially in case of unclean shutdown/unmount), and probably just reformat and re-fill the drive with data in such a case, instead of trying to recover.

Also, ensure performance gains are real and significant. Because maybe the first test just tries to flush after each write, which will indeed cripple performance, but barely this is done by any widely used application at all.


  1. blogs.msdn.microsoft.com/oldnewthing

  2. Sandisk ExpressCache manual:

  3. Some other forums

  • Interesting theory about AS SSD calling flush but why would updating the driver boost performance for this as mentioned in the Reddit link I posted?
    – g491
    Commented Jun 4, 2017 at 17:35
  • Performance boost is explained in another link you posted - superuser.com/q/1107759/131936. Basically, it's bugs/bad optimization of controller driver, which have been fixed in newer version. Commented Jun 5, 2017 at 4:24
  • For example, here is issue published by Intel: search for "1804279652" on page downloadmirror.intel.com/26730/eng/Release_Notes_15_5_PV.htm Commented Jun 5, 2017 at 4:32
  • Regarding your comment of "Even worse: in some cases, you may loose data on clean shutdown/reboot, if drive doesn't flush cache on its own before reset." do you have any source for this? I can't imagine that Windows wouldn't issue a flush command before a clean reboot / shutdown if this were a potential issue. Thanks
    – g491
    Commented Jun 10, 2017 at 8:06
  • @g491 yes, it's first link in my reply (read the linked comment). Also, see post of Raymond Chen on the topic, he is Windows developer. He says, even though Windows flushes data from RAM, with this checkbox it does not send "flush" command to the drive, so the drive could flush it's own cache when it feels best. Even on shutdown. And some drive's firmware is too buggy and does not flush automatically on shutdown/before reset. Commented Jun 10, 2017 at 14:49

It seems to me by Occam's Razor, if AS SSD has bad results when buffer flushing is on, then this reflects the fact that data takes longer to be written to the disk. The measuring by AS SSD seems to go deeper than CrystalDiskMark. CrystalDiskMark apparently does not care what happens after the write is issued to the OS, considering the data as already written, while AS SSD hooks into the OS.

Modern disks have a rather large RAM cache that is usually internally protected from power cuts, so there is no need to insist on waiting for the disk controller to fully write the data to its internal disk - this just harms performance.

See also this article : Flushing your performance down the drain, that is.

  • 2
    For SSDs, write caching still harms data integrity along with performance. Note the article from 2010 talks of them spinning flywheel devices. ;-) SSDs are a whole different kettle of fish. I have an SSD with capacitor backup to complete flash-memory page writes. However on a hard power cut (and also a kernel crash) I regularly experience file corruption even at Window's "safer" level of write caching: after reboot, certain files are the correct size but the content is full of zeros where the data should be. No problems reported by scandisk. Commented Feb 25, 2019 at 9:23
  • 1
    Hmm, actually what I can't say with confidence is whether the data loss would have occurred anyway with write caching disabled. I've only just started to try this after many years of SSD data loss, across windows 7 & 10 and multiple SSDs. Turns out write caching only made 10% difference in practice (worst case!) to compiling code - and actually I need-only disable it on one drive, as I can shift the bulk of my writes to a temp drive, and that way I don't even lose that 10% performance. Commented Feb 25, 2019 at 9:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .