MagicAndre1981 Posted September 12, 2014 Share Posted September 12, 2014 in this case you have a newer version of th kernel and the Update is no longer needed. I requested better error message since Vista, but MS ignores this. Link to comment Share on other sites More sharing options...
NoelC Posted September 12, 2014 Author Share Posted September 12, 2014 The question is, has that hotfix been rolled into the kernel? Is it possible to know? Can't say I've sensed any improvements at all in file system performance lately to be honest. -Noel Link to comment Share on other sites More sharing options...
MagicAndre1981 Posted September 13, 2014 Share Posted September 13, 2014 updates are cumulative. If you have a higher version, the fix is included. Link to comment Share on other sites More sharing options...
NoelC Posted September 13, 2014 Author Share Posted September 13, 2014 I have never run across hard information from Microsoft that says they are, but you're closer to the internals than most anyone I've known, so I believe you implicitly. Well, then, this fix makes no difference whatsoever to file system performance, whether in real use or in benchmark tests. That's disappointing. -Noel Link to comment Share on other sites More sharing options...
Hydranix Posted September 16, 2014 Share Posted September 16, 2014 You stated that you simply formatted your OS partition. (I'm assuming you used Window's tools, included in the installation ISO/DVD. Correct me if I'm wrong) Do you use a hardware RAID controller, or is it a "fakeraid"? If hardware, does it have it's own memory banks? I know this isn't the cause, but it's worth looking into.. Are your partitions aligned properly, and is the stripe size optimal for the disks erase block size? You stated you left your boot partition intact between OS benchmarks. This indicates that you didn't do a low level erase on each disk in the array and rebuild it. Without releasing the charges in the NAND cells, it must be done at the time of the write, thus causing several nano seconds of delay multiplied by the millions(?) of cells. (this is completely subject to different disk firmwares, which are industry secrets so nobody can know what takes place, so let's assume the worst) Perhaps the disks aren't/weren't TRIMed adequately before each benchmark, and during normal usage. Check into your system's garbage collection implementation and see what controls it between the two OSes (Windows, RAID controller, disk firmware, etc). I know on my PCIe SSD fakeRAID-0 RevoDrive, there's no way for me to actually instruct Windows to perform TRIM, however Linux does it quite easily. Strange..? Thats all I got for now, thanks for starting this thread, I learned a few quick tricks to boost my systems performance. -HNx Link to comment Share on other sites More sharing options...
NoelC Posted September 16, 2014 Author Share Posted September 16, 2014 Thanks for your thoughts, HNx. The controller is a HighPoint 2720SGL dedicated hardware RAID controller, though rather a lower-end model that doesn't embody its own cache. It can easily sustain virtually the full SATA III bandwidth on all four ports at once, and has been an utterly reliable device. I originally formatted the array during Windows 7 installation and the partition configuration is optimal. Notably the Highpoint driver does not support TRIM operations, but this doesn't matter. Without TRIM the SSDs manage their own free storage erasure via their internal Garbage Collection algorithms, and these really work. Over the 1.5 years I used this array with Windows 7 my benchmarks and practical I/O experiences actually got faster and faster as time went on. That has reversed with Windows 8.1. The SSD experts on the OCZ forum confirmed that a lot of people reported long-term speedups, and it has to do with the in-drive SandForce controllers getting familiar with usage patterns and organizing things to be most efficient. Part of succeeding at using SSDs long term is maintaining a sufficiently large amount of free space - counterintuitive given the hardware cost, but it really works. My observation, since moving up to Windows 8.1, is that most I/O operations have been getting incrementally slower and slower. Not terribly much so in the general case - from applications I still get about 1.5 gigabytes/second throughput (though it was 1.8 GB/sec under Windows 7), and a few operations faster than ever. File Explorer is an exception, it's much less efficient. Everything I can measure implies the drives are just fine - it's the Windows software that's becoming less efficient. No one can say whether it's on purpose. And apparently not everyone sees the same performance. Some folks report they can enumerate tens of thousands of files per second in Explorer, though it's always possible they are still running Windows 8(.0) which was fast. There is clearly something very specific being done in Windows 8.1's File Explorer that TREMENDOUSLY slows down operations, as compared to prior versions (e.g., Windows 8's File Explorer). I say watch what they pull out of their, er, hat with the file system implementations in Windows 9 - I'll bet Microsoft magically somehow makes it fast again, and they'll exclaim what heroes they are for speeding things up so amazingly. -Noel Link to comment Share on other sites More sharing options...
UCyborg Posted January 12, 2018 Share Posted January 12, 2018 Counting files remains dog-slow on Windows 8.1 in 2018. Nothing improved in that regard on Windows 10 from what I'm observing on my PC. It's indeed a night and day difference compared to 7/8. I have plain old HDDs, where this is most profound since they're slower, but have plenty of capacity and potential to host tons of files of varying size. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now