NTFS Compression on HDD benchmarked

[taltamir]

I recently came across an article measuring the usefulness of NTFS compression on SSDs. My own SSD has a sandforce controller so it will not help there, but would it be useful on my HDD?

I remember back in the day I used to use it, but I stopped due to low performance, I was curious to know if performance is better with current hardware. Finding not results available online I did my own benchmarking.

System:
Win7x64
i5-3570K
16GB DDR3-1600
XFX HD6950
Gigabyte GA-Z77MX-D3H
240GB Intel 520 SSD
640GB WD 2 platter drive.

At first I ran the ATTO benchmark which showed MASSIVE improvement across the board when turning on compression
I tried AS SSD which uses incompressible data, unfortunately rather then seeing how much data it can push in a minute, it creates a set amount of data (made with SSDs in mind) and then runs it for as long as it takes. This resulted in the test stalling out (even without compression.

Incompressible Data - Windows file copy, potentially useless, needs repeating
I pulled out a stopwatch and tried just timing copying a single 5.85GB HD movie file (x264) from my SSD to the HDD.
Compression off: 45 seconds
Compression on: 110 seconds (CPU Usage fluctuated between 13 and 19%; mostly about 15-16%; according to win7, single core only)

Mixed Data - Windows file copy, useless
I went and made a folder on SSD called NTFSC test and filled it with 1, 4, or 8 copies of windows directory (skipping the 1 file I was unable to copy out of the windows folder).
1x windows (1.41GiB according to windows properties unusual rouding):
compression on v off both 5-6 seconds.

8x windows (11.3GiB according to windows properties unusual rouding):
compression off: estimated very long time, aborted.

4x windows (5.67GiB according to windows properties unusual rouding):
compression off: 121 seconds. - 10 seconds for first 50% then stalled for a long time before proceeding slowly.
compression on: 103 seconds. - 10 seconds for first 25% then stalled for a short time and proceeded slowly but not as slow as with compression off.
compression off: 71 seconds. - is superfetch "helping"? is the read speed an issue? who knows but this is definitely not a reliable experiment.
Will see about AS SSD overnight results (it creates custom random data every time)

Windows file copy seems to be a really REALLY REALLY bad benchmark.
I hope overnight AS SSD proves more repeatable.

Compressible data - ATTO bemchmark:
Compression off:

Compression on:

Testing notes:
I created an empty compressed folder and pasted a file in it for the stopwatch test.
For ATTO I shared and then mapped that empty folder as a network drive. (ATTO creates its test files in the root directory of chosen drive).

 

[KingFatty]

Would you be willing to re-do the test with something that is not incompressible? I think the big movie file you used was incompressible, so maybe the NTFS compression algorithm didn't really like it and took a lot of time to just throw up its hands?

 

[taltamir]

Would you be willing to re-do the test with something that is not incompressible? I think the big movie file you used was incompressible, so maybe the NTFS compression algorithm didn't really like it and took a lot of time to just throw up its hands?

Not incompressible = Compressible.

And that was the PRIMARY thing I tested... check ATTO benchmark which showed massive gains for NTFS compression.

I would certainly be willing to perform more tests. Any program (that is free) that people can suggest I will add.

I will probably do AS-SSD overnight.

 

[dawks]

Would you be willing to re-do the test with something that is not incompressible? I think the big movie file you used was incompressible, so maybe the NTFS compression algorithm didn't really like it and took a lot of time to just throw up its hands?

Yea, theres not much sense in trying to compress something thats already as compressed as it can get. x.264 is a very highly compressed format. As is MP3, or JPG... text files compress very well, you may want to try with some giant txt files. A side note, I compress a 2gig database backup with 7zip, from 2gigs down to 110megs. Works great.

I'll also mention, its looking like NTFS compression is going away. Windows 8 will most likely be the last release of it. NTFS in Windows Server 8 is shipping with data de-duplication, and thats giving the boot to NTFS compression.

 

[taltamir]

Yea, theres not much sense in trying to compress something thats already as compressed as it can get. x.264 is a very highly compressed format. As is MP3, or JPG... text files compress very well, you may want to try with some giant txt files

Did you miss the part where the majority of my test was compressible? There is very much reason to run this with incompressible data. NTFS compression does not and CANONT be made to exclude already compressed files. It WILL try to compress ANY file on that drive regardless on whether it is compressed or not.

So testing how it handles compressed files is very much relevant. Just like it is with a sandforce controller drive.

 

[KingFatty]

Are all the results based on copying from the Sandforce-based SSD (not compressed under NTFS) to the HDD (compressed under NTFS)?

What about going the other direction, from the HDD to the SSD? Is it identical and doesn't matter on the direction?

I'm curious if it would change anything if the SSD were also compressed under NTFS - would windows be smart enough to recognize that the origin and destination drives are both compressed under NTFS and just skip the compression part?

Could sandforce SSD potentially benefit from NTFS compression, even though it seems redundant? Maybe it could?

 

[taltamir]

Are all the results based on copying from the Sandforce-based SSD (not compressed under NTFS) to the HDD (compressed under NTFS)?

The useless stopwatch copy tests are all from the SSD (Intel Sandforce, no NTFS compression) to the HDD, either NTFS compressed OR uncompressed (different target directory).

The ATTO tests... well ATTO is running off of the SSD but AFAIK it creates the data procedurally so its basically RAM to HDD being tested (write), or HDD being tested to RAM (read)

What about going the other direction, from the HDD to the SSD? Is it identical and doesn't matter on the direction?

Doing that is a completely different test; it would be testing the read speed off the HDD & the write speed of the SSD.
I am not going to do that or any other tests with windows file copy anymore since I saw how poorly it works for repeatability. I will limit myself to proper testing programs.

I'm curious if it would change anything if the SSD were also compressed under NTFS - would windows be smart enough to recognize that the origin and destination drives are both compressed under NTFS and just skip the compression part?

AFAIK this is not how NTFS compression works.

Could sandforce SSD potentially benefit from NTFS compression, even though it seems redundant? Maybe it could?

Possible but very doubtful. That is something that should be discussed on this thread:
http://forums.anandtech.com/showthread.php?t=2083204

 

[Cerb]

compression off: 71 seconds. - is superfetch "helping"? is the read speed an issue? who knows but this is definitely not a reliable experiment.

No, just file caching, and indeed, it won't be a reliable experiment. For that, the files will need to be cold in cache every time they are read. Maybe there's a utility that can free the cache(s)?

 

[taltamir]

No, just file caching, and indeed, it won't be a reliable experiment. For that, the files will need to be cold in cache every time they are read. Maybe there's a utility that can free the cache(s)?

what caching? that is... what caching that is not superfetch?

 

[Cerb]

what caching? that is... what caching that is not superfetch?

Recently used data tends to be re-used, so why go out to disk for it, if you have free RAM? Hence, it stays in RAM until that memory is needed for something else (including newer data from disk), the disk is removed, or something else forces it to be freed. They started doing this right in Vista. You generally only need several MBs truly free at any given time for good performance (enough for dynamically allocated program buffers). After a few tens of MB, any extra truly freed RAM is being wasted. It acts very much like CPU caches used to.

Superfetch is a special service that preloads files into memory, based on common usage patterns. It is an attempt to speculatively preempt your need to read from the disk.

 

[taltamir]

Recently used data tends to be re-used, so why go out to disk for it, if you have free RAM? Hence, it stays in RAM until that memory is needed for something else (including newer data from disk), the disk is removed, or something else forces it to be freed. They started doing this right in Vista.

Yes they did, they started doing it in vista and gave it the buzzword name "SuperFetch".
Hence why I asked what caching OTHER then superfetch, the thing I specifically said was happening and that you said "No, just file caching"

Edit:
wikipedia says:

SuperFetch is a technology that pre-loads commonly used applications into memory to reduce their load times. It is based on the "prefetcher" function in Windows XP.[9]
The purpose is to improve performance in situations where running an anti-virus scan or back-up utility would result in otherwise recently-used information being paged out to disk, or disposed from in-memory caches, resulting in lengthy delays when a user comes back to their computer after a period of non-use.

Which would suggest that superfetch is SEPARATE to what you described. You described recently pulled information not being culled from RAM, while this claims superfetch specifically designed to augment this by re-preloading the useful info in case its removed.
That being said, wikipedia is a terrible source and I am pretty sure it is wrong on this and that superfetch is also the "keep it in ram" part.

 

[Cerb]

Yes they did, they started doing it in vista and gave it the buzzword name "SuperFetch".

No, they did not. They've never had a buzzword for it. It's a fundamental I/O feature, that has been in many OSes for many years. MS revamped theirs from NT4 to 2k, but it still wasn't as good as Linux or FreeBSD. In Vista, they revamped it again, making it perform about as well as it does in Unix and Unix-like OSes (notably Linux and FreeBSD).

Hence why I asked what caching OTHER then superfetch, the thing I specifically said was happening and that you said "No, just file caching"

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364218(v=vs.85).aspx

Superfetch is a speculative prefetcher.

 

[taltamir]

Thank you for clarifying.
From that link it appears the only name it has is "file caching" and its done by "cache manager". No buzzwords.

 

[Phynaz]

You need to reboot between tests to eliminate the effect of caching. And you need to turn off Superfetch.

 

[KingFatty]

Also, here is a long-shot, but is it possible there is some overhead/degradation when copying to the uncompressed NTFS folder, because of the fact that NTFS compression is enabled for other folders on the drive? Like, if you compared that kind of copy to a virgin drive with no NTFS compression, would they be identical or is there some overhead incurred every time Windows touches a drive once compression has been enabled on it in any way?

 

[taltamir]

Also, here is a long-shot, but is it possible there is some overhead/degradation when copying to the uncompressed NTFS folder, because of the fact that NTFS compression is enabled for other folders on the drive? Like, if you compared that kind of copy to a virgin drive with no NTFS compression, would they be identical or is there some overhead incurred every time Windows touches a drive once compression has been enabled on it in any way?

AFAIK this should not be an issue. Also I have nothing compressed on the target drive except for the test files.

 

[ZeroRift]

I'm curious: How much more CPU does ATTO consume during testing with NTFS compression on?