[Discuss] I need a recommendation for a Linux-compatible high-end PC builder

Sun Jan 28 12:47:44 PST 2018

>> Typically every new system has a speed gain compared to older systems
>> because of faster cpu's, faster memory, faster HDD throughput, etc. So
>> did you actually measure that SSD gave you any advantage by copying
>> your system from SSD to HDD and comparing speeds between HDD alone and
>> SSD + HDD for the same system and same hardware?

For my main home laptop (which I'm writing this email on) it's had a
Samsung Evo SSD in it for about 2 years now as the only drive.  I've had
zero issues with it, and the performance difference was night and day going
from the original drive.  Originally it had a spinning disk in it (TBF, I
*think* it was only a 5400 RPM drive, so not the best of spinning disk
technology), but in terms of "single change upgrades" going from the
spinning disk to SSD on this thing is probably the biggest single
improvement I've seen in a machine I've owned (not just load times, but
general responsiveness).  Before the SSD I was ready to buy a new machine
because it was so slow, and after the SSD I've been completely happy with
the machine and it's the only thing I've replaced/changed on it.

Full disclosure: it's not a Linux-based system (Macbook), and is an
"average", day-to-day use laptop (so not "dream" machine by any stretch,
only 4GB of RAM & an I5 processor).

On Sun, Jan 28, 2018 at 12:17 PM, Alan W. Irwin <irwin at beluga.phys.uvic.ca>
wrote:

> On 2018-01-27 21:28-0800 Cy Schubert wrote:
>
> In message <0D45725C-AAF0-4164-9833-65824155FB6E at gmail.com>, Jean
>> Taggart write
>> s:
>>
>>> Hello Alan,
>>>
>>> Splurge for an ssd.
>>>
>>> Most modern ones do trim and wear leveling at the controller level.
>>>
>>
>> Only if the filesystem support trim. You must enable this. On my
>> FreeBSD systems it's a tunefs option. ZFS automatically detects SSD and
>> enables it. On Linux ext4, for example, you would use the discard
>> option.
>>
>>
>>> Ssd’s have provided the most performance differences in all my recent
>>> builds.
>>>  The whole premature wear fears have been addressed. 1tb ssd for the os,
>>> 4tb
>>> for data as  2nd drive.
>>>
>>
>> The wear is due to electrons passing through a gate.
>>
>> It's best to use your ssd for primarily read such as /, /boot, /usr, or
>> /opt, unless you update your system a lot or use it for O/S development
>> (like I do) but not for /var, /tmp, or swap.
>>
>> Having said that a lot of accesses will also wear out a disk actuator
>> too.
>>
>>
>>> I have 10 systems that run Ubuntu and Debian on ssd’s used for work,
>>> intense
>>> testing. So far only one failure. I’m an early adopter and that was a
>>> Samsung
>>>  evo 950.
>>>
>>
>> My wife's laptop has had one fail with no warning though the technology
>> was young then. Today's SSDs use microprocessors to distribute writes
>> across the SSD, maintaining a map of logical to physical blocks.
>>
>>
>>> I can’t recommend them enough.
>>>
>>
>> My work laptop has one. The performance gain is very noticeable.
>>
>
> To Cy and Jean:
>
> Typically every new system has a speed gain compared to older systems
> because of faster cpu's, faster memory, faster HDD throughput, etc. So
> did you actually measure that SSD gave you any advantage by copying
> your system from SSD to HDD and comparing speeds between HDD alone and
> SSD + HDD for the same system and same hardware?
>
> The reason I ask how you are measuring these speed gains is I just
> don't get for large RAM systems why there is any major speed gain at all
> from an SSD that is dedicated to system files (with the exclusions you
> mentioned above to keep the write wear down).  The size of the "/"
> partition on my current system is "only" 18G.  Let's make the
> ridiculous assumption that all those files are actually used (rather
> than just there in case of need which is likely true for the vast
> majority of them). Then if you had large amounts of RAM
> (such as the 64GB I am about to buy) Linux would automatically cache
> all those files in RAM to give you essentially instantaneous access to
> them.  So on large RAM systems the SSD would speed up access to the
> system files the first time you used them after a boot, but then after
> that the SSD would never be used again for that file until the next
> boot.  Of course, I am making the assumption here that most system
> files are only read and not written, but an attempt is made with SSD's
> to exclude the parts of the "/" partitition that are written in any
> case so I don't think this can be an important argument against this
> interpretation.
>
> The above mental model jibes with my own practical experience which is
> for a system with "only" 4GB of RAM, I do get what I call "morning
> sickness".  That is overnight jobs (the normal ones and also an
> additional one in my case that builds and tests CMake and PLplot on a
> nightly basis) completely exhaust the cache of files that Linux keeps
> in RAM (and the disk cache that is part of the HDD hardware) so the
> initial access by me each day tends to be slow.  But from then on that
> day, the relevant file is cached in RAM so access is quick for a
> system without an SSD.  What I am arguing above is for RAM large
> enough, this morning sickness would go completely away (because the
> overnight tasks would not exhaust the RAM cache), and be turned into
> "boot sickness".  And I just don't think the complexity (e.g., special
> configuration measures required to avoid writes) and cost of SSD's is
> justified just to reduce (not remove) morning sickness, and the
> argument becomes even stronger if an SSD is only going to reduce boot
> sickness.
>
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://vlug.org/mailman/listinfo/discuss_vlug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://vlug.org/pipermail/discuss_vlug.org/attachments/20180128/5914ede7/attachment.html>