Interesting. Sandforce could not compress it at all. Makes me wonder about what Anand's SSDs had written to them with his repeated claim of 0.6 WA.
Printable View
121,33TB Host writes
MWI 33
--
I've done some checking and I do think we'll have to leave things as is, I'll change the labels to MiB, GiB, TiB and I'll put a "Hint" on TiB so that when the mouse is hovering on TiB written it will display TB written in the "Hint".
I've been through the source code and have adjusted for one event that wasn't recorded, the initial creation of the file used for random writes.
So, the GiB counter did not count the bytes written for when that file was created, essentially that means every time the app is started.
Having said that, this counter was never meant to be the only counter but we'll make it work for that as well. (as close as possible)
There is another source of writes and it is the internal database used for recording the loops, for every loop the stats are recorded so there is a 4KB blocksize update/write + the update of the Index. I'll check if I can get to those writes and add them to the running totals. (they don't amount to much but they are definitely producing writes)
Vapor, you can check the number of bytes written by the app by using the Task Manager->Processes
From the View->Select columns... menu option Enable I/O Read Bytes and I/O Write Bytes.
Yeah, A = 272GB or 253.3GiB for an increase of 256 in the SMART attribute. Each 64 increase was very consistently 63.2-63.4GiB too. Until more data says otherwise, I'm going to take SMART attribute readings for SF-1200 to equal GiB.
Just ran 135.95GiB of writes to my X25-M 80GB G1 and it showed up as 136.72GB in SMART (and damn my G1 is slow and stuttery with this...35MB/s and a stall once every 5-10 seconds). It would be good if someone could double-check this with more writes--my G1 just doesn't want to take part in the party.
Started it back up on my Vertex 2s with Task Manager running, will let it run for awhile and see what differences there are, if any.
354.69GiB written and reported by Anvil app vs. 354.6975GiB reported by Task Manager. Looks like any discrepancy is at the disk level or not there at all and just showing up due to the way I was measuring.
Going forward, it looks like A) it's totally fine to use Anvil's reported writes and B) SMART values are most likely in GiB.
I agree with A. But not B. From your data, it seems like the Sandforce SMART attribute has a bug. The attribute reports 256 of SOMETHING when Anvil's app reports 253.3GiB = 271.9788GB. The SMART attribute may be INTENDING to be in GiB, but what it is actually reporting is a unit that is about 98.9% of a GiB (about 1,062,000,000 Bytes). As you said, it is consistent -- consistently short of a GiB, meaning the firmware is recording 1% more writes than actually occurred if it is intending to be GiB. Alternatively, for all we know, it could be INTENDING to be in GB, but somehow it is missing some writes -- about 6%.
Any update on the C300 vs M4 debate?
We will start as soon as Vapor gets his C300 in the mail today.
As far as Sandforce on-the-fly compression goes I think it would be very interesting to compare that to a different brand of SSD using NTFS compression. Then you'd basically have on-the-fly hardware compression vs. on-the-fly software compression. Sandforce is basically just using Stacker on a chip. It would be nice to estimate what if any performance hit you would take by just running your Crucial or Intel drive compressed. Even if it does reduce performance slightly it might be worth it if it increases the write endurance of the drive to match Sandforce for compressible data. It also might be interesting to try to use NTFS file compression with a Sandforce drive. I wonder what would happen. Would it reduce the size of the files even more? Make them bigger?
I remember back when Stacker was popular. Lots of people ran with fully compressed drives in those days. It would effectively double the size of the drive. In the SSD new world order with 60 GB and 120 GB drives becoming common it would seem to have found a place again. Strangely, I can't find a single third party drive compression program similar to the old Stacker. Is the built in NTFS compression really so good that it can't be improved? I vaguely recall some app that used zip files to implement an automatic compression scheme, but I don't remember much about it. I'm also curious about how such a scheme would work with a large ramdisk.
What are you using to read the SMART data?
I noticed that the RAW smart value from all Intel SSDs is in units of 32 MiB. But CrystalDiskInfo displays a field at the top called "Host Writes _____ GB", where it converts the 32 MiB unit field to GiB, but labels it GB.
It is really sad, it seems that almost all Windows programs incorrectly label GiB as GB, but almost all linux programs correctly label the units (and most give you a choice of GiB or GB). Incorrectly labeled units cause a lot of confusion. Besides the problems we are having monitoring TB written to our SSDs, the Windows trend of labeling the units incorrectly has apparently convinced countless newbies that formatting their drive somehow decreases the capacity by 10% or whatever. Arghhh!
Attachment 116974
Attachment 116975
wow one hertz, your getting to the end (possibly) this is where the good stuff starts.... zero percent left :)
At 14:00 GMT+1 (summertime) I startet up the endurance test of my M4.
It's been running for 90 min and is doing well so far. If the speed stays at this level I'll be writing about 200 TiB in July.
Attachment 116980Attachment 116981
How often do you want me to post updates?
B.A.T, what is the Crucial equiv of MWI? AD, 05, or what? Know it when we see it move? :p:
I think an update of like once a day should be good, maybe a little more often as 8TiB/day is very fast.
Should be running on the C300 within a few hours now :)
I wonder who will get 0 MWI first, johnw or One_Hertz?
In that case, you are actually reporting TiB, I think. I don't have an Intel SSD that has written more than 999GiB, so I cannot tell for certain what it reports at that level, but my Intel toolbox is definitely reporting in GiB, even though it labels it incorrectly as "GB".
You can double check by looking at the raw value for attribute 225 (0xE1). It is in units of 33,554,432 Bytes = 65,536 sectors = 65536 x 512 = 32 MiB .
Intel SMART attributes:
Attachment 116984
Attachment 116985
26.387 TiB , 79 hours, sa177: 56/56/2174
If that 2174 is the average block erase count, and 56 is a number from 100 to 1 that normalizes the block erase count from none (100) to nominal max (1), then Samsung would appear to be specifying about 5000 block erases for their toggle flash (4960 at normalized 1, 5009 at normalized 0 ).
The problem is that if 2174 is the average number of block erases, then the WA is huge. Assuming 64GiB of flash on board, 2174 erases comes to 136TiB, which when compared to the 26.4 TiB written by Anvil's app, results in a ratio of 5.1.
If we take into account the 42GB of static data I have on the SSD, and assume Samsung does NOT do any static data wear leveling (I hope that is not true, but for the sake of argument just go with it), then there is only about 24.9 GiB free for Samsung to erase. 2174 * 24.9 GiB / 1024 = 52.8 TiB , which divided by 26.4 TiB results in a ratio of 2.0. Still seems high for WA.
I cannot make sense of the data. Anyone else have any ideas?
I suppose we will find out if Samsung has terrible write amplification in a few days or weeks -- if the Samsung 470 dies after much lower TiB written than the Intel or Crucial SSDs. Although if that happens, it will be ambiguous whether the early death was a result of high WA, or whether Samsung toggle flash has lower endurance than IMFT flash.
If only I could find a Samsung datasheet for the 470 SSD series SMART attributes. Intel and Micron both document their SMART attributes clearly in a datasheet. But if Samsung has such documentation, I cannot find it (their website is a total catastrophe -- even some of the consumer manual PDF files for the Samsung 470 SSD are broken)
Got home about an hour ago for the long weekend...UPS attempted delivery of the C300 about 2.5 hours earlier than normal and I missed it. :mad:
Called to arrange to pick it up this evening from their warehouse...was hoping it would be there before 6:45ish but won't be there until 8PM and I'm going to be at a July 4th fireworks show then.
Have had over a dozen UPS packages attempted to be delivered and I missed it, only for them to go to the front desk and have someone sign for it there and have it wait for me. First time I've ever had a package not delivered and no special signature is required....grumble, grumble.
Oh well, C300 starts midday Tuesday and I will be home that day to receive it.
I had been posting once a day, but I may post twice a day now, since as Vapor says, things are moving fast for these SSDs.
I notice that Micron does not appear to have a host writes SMART attribute. So are you reporting the TiB written from Anvil's app?
I also notice that your SSD has a threshold of 10 (not 1 or 0) for attribute 0xAD = 173 "average erase count of all good blocks". That "10" seems an odd value for threshold. Your raw value is currently 7. If we assume your SSD has 64,023,257,088 Bytes worth of good erase blocks (from Micron datasheet), then that comes to 417GiB of writes, as compared to your screenshot, 419.79 GiB written. So it seems to be reasonably good agreement.
Maybe we can start graphing the raw value of attribute 173 for the m4 and 177 for the Samsung 470. For the Intels, does attribute 233 (0xE9) have a raw value that we can graph?
Micron (Crucial) SMART attributes:
Attachment 116986
Attachment 116987
I'll post screenshot of Anvils app two times a day, and from 0xAD.
I had forgotten to turn on High power mode so my computer rested for a couple of hours while I was out. It's back running again and it will stay that way
btw does this look right? My 0xAD shows 11 = 64GiBx11=704GiB but Anvils app shows 1 TiB
Attachment 116994Attachment 116996
BAT
Change from HEX to DEC in CDI, (function -> Advanced -> raw values)
11h = 17
--
123.49TB Host writes
MWI 32
No other changes.
Updated charts :)
Raw data graphs
Writes vs. Wear:
Attachment 117000
MWI Exhaustion:
Attachment 117002
Host Writes So Far:
Attachment 117001
(bars with a border = testing stopped/completed)
Normalized data graphs
Writes vs. Wear:
Attachment 117004
MWI Exhaustion:
Attachment 117003