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

[Alan W. Irwin]

On 2018-01-28 12:17-0800 Alan W. Irwin wrote:

[...]
> 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.

I should have also mentioned another major assumption in the above
mental mode which is there are no memory leakers (processes that
require more and more memory as time progresses because they forget to
free memory that is no longer required). Such memory leakers starve
systems for memory as time progresses so in this case SSD's would give
noticeably better performance than HDD's.  Note that even if your
operating system is free of memory leakers poorly implemented
javascript files distributed from badly maintained or malignant
websites can also create memory leaks.  For example, I have recently
used the "noscript" Firefox extension to look at the large hierarchy
of different domains used for javascript by complex websites such as
The Weather Network, and even with the best will in the world it must
be difficult for them to eliminate all javascript memory leaks
considering the large number of different companies involved.  But I
am going to start watching that closely since a google search found at
least one instance where a major javascript memory leak occurred for
one of the users of The Weather Network.

Of course, ideally you do manage to avoid running memory leakers
(either from your operating system or via javascript) in which case I
think the above mental model of why SSD's don't help system
performance that much must still be correct.

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
__________________________