*****Kingston SSDNow V Series Solid State Drives*****

leexgx said:
Read speeds on SSDs run at the same speed when access read be it Trim or not, Trim is for Write part of the SSD can keep the Write speed up so the erase command does not need to be used when an file is been saved
Click to expand...

Did you just decide that logically it should be this way and decide that I must be lying, and that there was no point even considering anything else?

wiper.jpg


Empty non-OS drive. Before and after wiper. Benchmarks done less than 5 minutes apart. No other changes.
 
the drive should not do that on the reads unless Writes are going on at the same time, your Write performance is been cut back by more then 50% that is not normal should be less then that, more like 20-30% if that but only on Writes reads at most 1% andtech tested it they never got there SSDs to operate the way yours is working

be Quite poor on Indilinx if they are reporting an Read and Write speeds of the drive when it is wiped (all cells pre erased so read an Write are high), or there is an bug in the 1.10v firmware that is doing that, how did you make it go into that state, an Full format, filling the drive until it has no free space left (not the same thing as Filling the drive in an norm way), mite norm do what you have just shown

i am doing the norm filling Method of filling an SSD, Write 128gb to the SSD but Not filling it to the point it has no free space, you put on 62GB and remove the file and then do that again the Drive will now be Filled state (most if not all blocks now will need to to an erase before an Write can be performed)

my SSD is now 70% filled as i can tell from the benchmarks on HD tune
the speed of my SSD in HD Tune up 60% is 85MB/s, after 60% its doing 150MB/s on reads (must be no data there) put onto the SSD 30GB now and run HD tune read test and see if there are any Dips in the test (do the test before putting any data on it then put Half the amount that your SSD hold and then retest it you likey see that read speeds have dropped do to where the data is even if you delete )

----
i made this post before, been having an go at filling my ssd with out braking it like, mine seems to be hovering around 70% now thats Writing 27gb an time with only 75gb left, i have done it about 5-6 times now

i guess the recommended action is not to fill an SSD until it runs out of space as it mite be braking the wear leveling on the SSD some how or something els on the SSD

---
one other thing i have seen happening (that i am sure is not related to the SSD) is that windows 7 is making an 1gb cache in ram as well, it is doing this with every thing even an pen drive that i find very annoying as if i press cancel i have to wait until the 1gb of modified ram has got back to around 100MB, the annoying fact is that my pen drive operates at 8mb/s Writes (most do any way) and i have to wait on the copy box until the cache has ran out in system ram

also in hd tune pro (not sure if its in the free ver) is disk monitor after an copy has finished i can see that Write operations are still been performed every 2 secs for about 10 seconds (starting at 30mb then dropping down every 2 secs to 1mb)
i think this must be the way windows 7 does it but i never had HD tune pro on vista before so not sure
 
Last edited:
The drive does do that, go to the OCZ forums and trawl through posts if you don't believe me.

I think it's much more complex than just writing to each cell once. If it was then it'd simply be write speeds that decrease. If you want to come up with an explanation I'd start looking at things like erase sizes, and wear levelling in with the cell erase before rewrite.
 
I'm just guessing here but..
the way an SSD reads is by assessing the number of electrons in a cell. If it's more than 100 (something like that) the value is 1, otherwise it's 0.
TRIM works (I think) by clearing the electrons, but it can only clear them from an entire block of cells at once, so copies the useful cells' data to cache, wiping the block, then copying back.
So that would mean you have a clearer 'signal' for the drive when assessing whether a particular cell has sufficient electrons - the cells surrounding it, which would only be marked for deletion before Trim and still contain electrons, will be cleared of electrons following Trim. So by that reasoning, read speeds could increase because it would take less time for the controller to decide if a cell had sufficient electrons or not, when the surrounding cells are blank.

Does that make sense?

It's just a theory, I don't have any evidence for this, so make of it what you will, but in my mind it seems a possible explanation for increased read speeds following Trim.
 
If I'm reading your post right Leexgx, your tests were done with a drive that was filled with used blocks, but those pages could just simply be wiped because the file was deleted and no data needed to be preserved. So the SSD only needed to Erase -> Write

If you fill a drive using lots of small file operations and general use, you can end up with a drive that has some data that needs to be preserved in most of the blocks, meaning the SSD needs to Read the block to cache, modify it in cache, erase the block and write it back out. This Reading and modifying is an additional overhead that would explain the difference in yours and Halks findings.

I'm assuming that the hit to read speeds that Halk is seeing comes from the fact that SSD's are very highly parallel internally, after a while of general use with small files the drive will be unable to place blocks evenly across all of it's channels thanks to having some channels where there are no empty blocks or blocks with deleted data, rather than take the performance hit at write time, it stores the file across a more limited number of channels.
Thus the file can't be read back from as many channels at once and you get a slower sequential read.

Just a theory, you should be able to test it by messing up a drive with small file ops, writing a large file to it, then copy a large file, at least a couple of GB. Run a benchmark testing the sequential read of this file back into a Ramdrive. Run wiper, and then do the file copy again.
If I'm right you should see similar speeds both times, because wiper doesn't move data around the file will still only be spread across a limited number of channels. This wouldn't show up in benchmarks because I assume they create the file they are testing new each time, and if it's created on a wiped drive it will be written across all channels.

Could highlight a new issue with them, that wiper fixes benches, but any data written during the poor performance state will remain at poor performance. Running wiper regularly will prevent it ever happening in the first place though.

Anyway, just a theory, I'd love it if someone with an indilinx drive could test it for me.
 
when data is Written to the SSD the data is fragmented across the SSD so it can hit as many cells as it can when it reads data back so to improve speeds, not sure if it matters if the file is big or small as it still be the same fragmentation on the ssd any way, could be the wear leveling is not working correctly, but it could be any thing really as they are not giving us any info on that matter
 
Just to report, I picked up one of these 128GB drives and I'm really happy with it, Vista boots way faster and is generally quicker in every way. It was easy to install which is a bonus.


Its definately been the best bang for buck upgrade I've done for a while.
 
Last edited:
it still does not have any cache on it (16KB not really cache)

the stuttering issues is Dependant on your drivers and chipset, most likely lucky it is not doing it (or you have most likely not written 128gb to the disk yet so no pages are been erased yet so most likely be ok for now or drivers are hiding the problem)

you can get an Samsung and corsair that has 32MB of cache on it and they only cost £15 less for the 64gb samsung SSD and for £14 less the corsair S128 (then buying an kingston)
so no reason to buy an kingston that uses an chip that has known problems no firmware can fix it

http://www.overclockers.co.uk/showproduct.php?prodid=HD-000-CS&groupid=701&catid=14&subcat=1427 Corsair S128
http://www.overclockers.co.uk/showproduct.php?prodid=HD-071-SA&groupid=701&catid=14&subcat=910 samsung 64gb (recommend the 128gb for space reasons)

untill they bring out an JMicron SSD that has cache on it (more then 16KB) best to avoided JMicron based SSDs
 
Ranger07 said:
Just to report, I picked up one of these 128GB drives and I'm really happy with it, Vista boots way faster and is generally quicker in every way. It was easy to install which is a bonus.


Its definately been the best bang for buck upgrade I've done for a while.
Click to expand...

Can you download and run a copy of CrystalDiskMark? The results should tell us everything we need to know.
 
random Write 4k will most likely be 0.5-0.2MB/s unless his drivers are buffering the Writes, the 512KB may not be much better, even if the SSD is filled or not
 
I picked up the 64GB version of this last week. My machine is 1.86 dual core, xp 64, 6GB ram and compression on all drives (including the SSD). After putting all my software on I did this test against my Maxtor Maxline III drives (think it's this, was higher end then normal consumer ones), a 16MB cache drive that's server grade with NCQ enabled, was very quick in 2006 when first purchased, and due to NCQ not to far off Rapters of the time.


All numbers MB/s

Maxtor
Sequential - Read 43.5 - Write 44
512k random - Read 25.5 - Write 48.5
4k random - Read 0.58 - Write 4.3

Kingston SSD
Sequential - Read 119 - Write 85
512k random - Read 110 - Write 50
4k random - Read 16 - Write 1.99

I'm very happy with drive, however I did move a 1.5GB outlook file onto it, and it ran slow. I have moved internet temp files onto the HDD's.

For loading programs it feels like 20 years ago, when HDD's first appeared, and DOS programs were being moved from floppy drives. All those DOS programs written for floppy were very fast on early HDD, and this feels the same. MS Word 2007 2-3 seconds, MS Visio < 2 seconds, PhotoShop CS4 7 seconds.

On a total fresh install of XP64 (with compression off at this point - no service packs or anything). I counted 6 seconds from the Windows loading screen to where I could access the Start button. I have put everything on (all updates) including compression, and i'm down to 20 seconds.
 
Last edited:
i think i'll have to try one of these for myself, thinking about getting the 128Gb version and splitting it up 40Gb for windows and apps and the rest for games :D or if i'm still duel booting xp & vista/windows 7 20Gb for xp, 40Gb for vista and the rest for games and looking at what others have said setting all that up shouldn't take too long :D
 
The Halk said:
Have a read at this. It shows that RAID on SSDs does not lead to double real world performance.
Click to expand...

What a pointless set of benchmarks.

Of-course it isn't going to double that kind of work.

How about loading times or transfer between disks or something else.

Pointless forum post that one you linked to tbh. That wouldn't make me think twice about RAID 0 SSDs for one second.

My 2p anyway.
 
razer1978 said:
rest for games :D
Click to expand...

Be carefull putting games on this. At one stage I put Company Of Heros on the drive, however due to the amount of Company Of Heros patches (some over 1GB) it was patching so slow. In the end I moved COH to a normal HDD.

As said it's great, but it gets 'overloaded' if it has to deal with updating very large files. As mentioned I have moved my 1.5GB outlook file off the SDD.

Go for SSD it will really improve things, but be selective on any large files that you think may change.
 
JasonM said:
it was patching so slow. In the end I moved COH to a normal HDD.

...

Go for SSD it will really improve things, but be selective on any large files that you think may change.
Click to expand...

Forgive me but that doesn't sound like it's really improving things at all. I think the motto here is buyer beware, make sure you get a SSD that doesn't suffer from the infamous stuttering problems.
 
You must log in or register to reply here.
Back
Top Bottom