You are already running the Intel AHCI driver ver. 17.5.3.1026 and not the native windows OS AHCI driver. That's the reason why you do not have storahci.sys which is the OS's native AHCI driver. It either has been installed through WU or manually via Intel RST. It's been reported that Intel RST version 15 causes issues. I am not sure if it has been fixed at the 17.x versions. I firstly would either uninstall Intel RST OR to rollback to the native AHCI driver coming from the OS (default). The native AHCI drivers are old, but actually are running well. Only drawback (on very old systems) can be that SSDs are listed as removable drives. (On my old PC for instance). There are lots of discussions if installing Intel RST makes sense at all or to use the native MSFT driver. Many people say that if one does not use any RAID it makes not much sense. Additionally some people say that the native MSFT AHCI driver is used by SSD's vendors to optimize their SSD firmware. It makes sense to optimize for OS default drivers rather than to optimize for Intel's own (except you are running a SSD from Intel of course). After you have rolled back to native MSFT AHCI I would repeat the tests. The native AHCI driver's name is storahci.sys. Recheck that first. If it should not resolve the issue you can try what I have posted afterwards (reg edit) since you now are running storahci.sys. The regedit BTW I have found on several other sites, but I never have tried it myself since I do not have issues using storeahci.sys. I hope it works out for you. Another thing that I firstly thought about is all the meltdown / spectre patching which is from the technical aspect a total mess since it is totally made without any concept. Some have updated microcodes in combination with other patches and the latest w10 has retpoline included. (which also caused performance issues at special situations). Also 1809 should have got retpoline update already...I even don't know if it's active there... Who knows if it slows down file copy operations if a special patch situation would turn out very negative?
Anecdotal "evidence" here, I've been running Intel's drivers for almost 2 years (not the whole RST package, just the drivers, often from win-raid who are fast to provide them), and it's basically a cosmetic choice with very minor performance implications. There were 2 occasions when performance was improved, there were some pretty big drops in benchmarks such as Samsung Magician's and they got fixed in later RST drivers. I remember one perf. issue got fixed when I jumped from 16.8 to 17.0. The Intel RST drivers often match the Intel RST EFI module that gets updated with the BIOS, so I assume things can get solved through BIOS updates as well. And yes, the numerous microcode and firmware updates might have been the culprit for the performance decrease. For my 8700k/z370 platform, the patches didn't really affect CPU benchmarks or performance, but the storage performance (850 Evo) definitely went through some ups and downs. I assume the impact would be even more dramatic for fast NVMe SSDs. I only got one a few weeks ago so I only know how it runs on the latest BIOS (17.5 EFI module) and drivers from 17.5-17.7 range, if I had a dual BIOS motherboard I would probably give an old BIOS a shot just to see the 970 Evo Plus without security updates, but it's really not worth the risk with my budget board that I can't recover from BIOS update failures.
What are your thoughts on this? When the speed is at the higher of the two values it is switching between, it is really good - I'm very happy with it. If only it would stay that way. Also, the 100% disk usage is of file explorer itself. CPU usage remains low. This would not be the case if the antivirus was kicking in.
"by adjusting my working set cache to 1/2 of my memory + 1gb" In my case that's 33gb. Not trying to be smarta**, but if you don't know how to set the working cache, it's not something to mess with as it can seriously mess up the performance of the OS. If you still want to try, you're looking for a program called cacheset64. To make it auto, you'll also need to make a startup script for Windows to run.
Sorry, maybe you can or want tell, what problem you're talking about. In the meantime, so many different things have started to be talked about that it is impossible to understand what anyone is talking about.
I'm assuming he is talking about the problem mentioned in the title of the thread. Sorry - no progress yet - I've been swamped with work - but I have a few ideas that I'll try in a few days.
In Windows 7 this problem does not exist - it is only in Windows 10, that too in a fairly recent release. @Lumans tried Windows 7 for testing only.
It all depends on the speed of your computers system bus and your drive speeds. Typical SSD is fine and recommended but when your machine starts to write to the drive what is happening is the is SSD`s have cache and the first initial burst write is filling up cache memory on the drive then the system bus as it is writing and when the system bus fills up the speeds slow down because some system buses only read and write data so fast unless you have a high end gaming system with a fast bus. I`ll use the analogy and say your SSD may be able to send data down a 4 or 5 lane highway (AKA) bus but if your system bus in your computer can only do 3 lanes then the highway fills up and traffic starts to slow down!
I don't think that is what is going on here. If I try to copy, say, 60 GB, the first 25-30 GB gets transferred at around 480 MBps, which is excellent. Then it slows right down to about 12 MBps. Then back to 480 and so on.
Ya I've noticed that as well and I'm not even using Sata. My laptop uses NVMe PCIe Gen3 PCI-E x4 which is supposedly far superior to Sata when it comes to read/write times.
I'm going to try Explorer alternatives and shut down Windows File Explorer and see if the issue goes away.
PROGRESS: Moving files between internal drives, from an M2 SSD to a SATA SSD. The SATA SSD has a max speed of about 500 MB/s. The M2 is faster, but I don't have anything that will write to it that fast. 1. ISO files seem to be immune from this issue. Copied a 12.1 GB software iso at over 480 MB/s (initial speed due to caching was much faster, then it reduced to about 480 MB/s and stayed there). 2. FreeCommander works. No slowdown observed (initial speed due to caching was much faster, then it reduced to about 480 MB/s and stayed there). This was a 6.2 GB game (folder containing several .bin files) that did slow down drastically when I tried to copy using Windows Explorer. I'll keep testing and report back as and when I have sufficient material to move/copy, but for now I'm happy, as I can do what I want to using FreeCommander. I'm going to move a lot of stuff to an external USB HDD soon and see how things go.
I am using a third party utility - FreeCommander - and it does not exhibit the same annoying slowdown. I suppose TeraCopy would be fine also. I'm using the portable version of FreeCommander. For small files Windows Explorer works fine - the slowdown takes a few seconds to kick in, and my computer is fast enough that I never see this unless I am copying a large amount of data. So for daily use I want to continue using Windows Explorer. I'll only use the third-party utility when I have to copy a few tens of GBs. I didn't like the extra clicks that a proper install of TeraCopy would make me do if I used the full version and integrated it with Windows Explorer.
Yes, but in this cast - there isn't any issue, right? Just don't use the native copying process, but your superior one.