🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.games.rpg
Article #720810

Re: OT-choice CPU/GPU

#720810
From: Ross Ridge
Date: Thu, 19 Mar 2015 23:39
87 lines
6246 bytes
DMP  <nom...@nodomain.com> wrote:
>Rin mentioned that the SSD's get slower with time due to "the number of 
>writes that slowly damage the memory over time". I didn't want to get in 
>a situation like I had three computers ago. I got a custom built job 
>that came with two IBM "Deathstars" both of which failed. My bad for not 
>doing the research then. I do hold on to my systems for a goodly amount 
>of time, so reliability and longevity are important. The only thing I've 
>ever had failed were disk drives, two IBM's and a Seagate

In theory SSDs should be more reliable than hard drives, but I think
in practice they end up being roughly the same.  The slow down doesn't
occur directly because of damage, but more because of what SSDs do to
avoid damage.  Individual flash memory cells wear out pretty quickly,
with current flash densities it only takes a few thousands writes to a
cell before it stops working.  In the context of an SSD this is both way
more endurance than you need, or way less depending on how you look at it.

In the best case if you were to able exploit every flash cell in the SSD
to its fullest this would means you could write hundreds of terabytes of
data to the drive before single flash cell died.  To do this your writes
would have to spread out evenly across the drive.  In the worst case,
if all your writes were to same place on the SSD, it would take only a
few thousand kilobytes before it wore out in that place.

Normal hard disk usage doesn't spread out writes evenly across the disk.
Writes will end up being concentrated in certain places on the disk so
SSDs have to work differently than hard drives to prevent premature
failure.  The key thing they do is something called wear levelling.
When told to make repeated writes to the same area on disk they internally
remap the writes to different areas in flash memory to spread them
out.  For this to work well the SSD needs to use unused flash memory.
While SSDs keep a small amount of their flash memory reserved for wear
leveling and other purposes, they mostly rely on using unused disk space.

With older SSDs and older operating systems the SSD had only one way
knowing whether disk space was unsed or not.  If a part of the disk was
never written to it knew it was unsed.  Unfortunately this means that
when you delete a file the SSD wouldn't know that the space it took up
was no longer in use.  That space had beeen previously written to, so
the SSD would have to assume it was still in use.  This would mean as
far the SSD was concerned the drive would eventually fill up and there
would be no unsed space to use for wear leveling and certain performance
gains that go along with it.

With newer SSDs and new operating systems there's now another way the
SSD can no what space isn't used.  This is new command called "TRIM"
that can be sent to the SSD by the operating system to inform the SSD
about ares of the disk that are no longer being used.  So now when you
delete a file the OS will send the TRIM command to let the drive know
that space taken up by the file is no longer in use.  This means SSDs
don't slow down anywhere near as much as they used to.

(Note that most of the slow down actually comes a from an issue call
write amplification, where small disk writes end turning into large
flash writes because of the way flash memory works.  The techniques used
for wear leveling also help reduce the effect of write amplification,
so I've basically conflated the two above.)

Finally SSDs use sophisticated error correction schemes so that even
when a flash memory cell does go bad you won't lose data.  The SSD is
able detect the error, correct it and move the data to another area in
flash memory. Hard disks do the same thing, as while they don't wear
out anywhere near as quickly, a small amount of damage is pretty much
inevitable even with a drive that's working normally.

>I have confidence in the builder and they will tell me what their 
>experience has been with SSD v. mechanical particularly with their 
>gaming towers. There isn't much difference in the cost of an  250 gb SSD 
>and 1TB WD Black. There also must be a reason why most of the gaming 
>computer builders are adding SSD's to their configurations. The smaller 
>SSD's are getting to be close in price to the larger mechs.

I doubt your builder would recommend not getting an SSD.  These days
they belong in any but the most budget concious PCs.  I even put one in
my Mom's 5 year old PC that she just uses for e-mail and web browsing.
It makes a big difference even for that.

Also remember smartphones and tablets all use flash memory for storage. If
you have one of those you're already effectively using an SSD.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rri...@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  
Technical Details
Message-ID: <mefmnj$n5n$1@rumours.uwaterloo.ca>
Path: mbox-mo1.pugleaf.net!zn2ni11980lbb.1!nntp.google.com!goblin2!goblin1!goblin.stu.neva.ru!ottix-news.ottix.net!utnut!rumours.uwaterloo.ca!.POSTED!not-for-mail
References: <me3v83$kpu$1@dont-email.me> <01a75b82-5b78-4713-9df3-6f8947ef002e@googlegroups.com> <med2cr$ech$1@rumours.uwaterloo.ca> <mee9n8$o6v$1@dont-email.me>

Show Full Headers
Complete Article Headers
X-Received: by 10.112.181.166 with SMTP id dx6mr10074734lbc.17.1426809610055;        Thu, 19 Mar 2015 17:00:10 -0700 (PDT)
X-BeenThere: comp.sys.ibm.pc.games.rpg@googlegroups.com
Received: by 10.152.23.195 with SMTP id o3ls374086laf.82.gmail; Thu, 19 Mar 2015 17:00:07 -0700 (PDT)
X-Received: by 10.152.28.137 with SMTP id b9mr12526264lah.8.1426809607246;        Thu, 19 Mar 2015 17:00:07 -0700 (PDT)
MIME-Version: 1.0
Path: mbox-mo1.pugleaf.net!zn2ni11980lbb.1!nntp.google.com!goblin2!goblin1!goblin.stu.neva.ru!ottix-news.ottix.net!utnut!rumours.uwaterloo.ca!.POSTED!not-for-mail
From: Ross Ridge <rri...@csclub.uwaterloo.ca>
Newsgroups: comp.sys.ibm.pc.games.rpg
Subject: Re: OT-choice CPU/GPU
Date: Thu, 19 Mar 2015 19:39:31 -0400
Organization: University of Waterloo
Lines: 87
Message-ID: <mefmnj$n5n$1@rumours.uwaterloo.ca>
References: <me3v83$kpu$1@dont-email.me> <01a75b82-5b78-4713-9df3-6f8947ef002e@googlegroups.com> <med2cr$ech$1@rumours.uwaterloo.ca> <mee9n8$o6v$1@dont-email.me>
NNTP-Posting-Host: taurine.csclub.uwaterloo.ca
X-Trace: rumours.uwaterloo.ca 1426808371 23735 129.97.134.34 (19 Mar 2015 23:39:31 GMT)
X-Complaints-To: ab...@uwaterloo.ca
NNTP-Posting-Date: Thu, 19 Mar 2015 23:39:31 +0000 (UTC)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit