Have you looked at the HP ProLiant MicroServer?
Cheers,
Henk
Have you looked at the HP ProLiant MicroServer?
Cheers,
Henk
Notice it takes up to 8 GByte ECC memory and supports zfs
via napp-it/Illumos. A hacked BIOS was required to use
the 5th internal SATA port in AHCI mode, maybe that's
no longer necessary with N40L.
The MicroServer is actually a nice little platform, one little bright
spot in the small-home-server market.
It does have some other issues though:
1) It's not particularly low-power, as in, I managed to build some Xeon
based systems that run rings around it for only maybe a dozen watts
more, and some of the NAShead guys over at one of the Linux based
projects have a similar but lower-power platform for a lower price,
2) While it has a remote management card available, it's known to not
work with certain things, including FreeBSD,
3) Various problems noted with the eSATA port, such as the inability
to use an external port multiplier.
On the flip side, some people have tossed one of those 4-2.5"-in-a-5.25"
bay racks into the optical bay, along with a PCI controller, to allow
the addition of SSD's or whatever for NAS use. Pretty cool and the
thing *is* pretty compact.
... JG
Jimmy Hess wrote:
Consider that the probability 16GB of SDRAM experiences at least one
single bit error at sea level,
in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 *
2^30 * 8). In any given 24 hour period, the probability of at least
one single bit error exceeds 98%. Assuming the memory is good and
functioning correctly;
application in the effected space, and moderately important data is
being damaged
well, that's just plain uncool
Having limited knowledge of which consumer devices support ECC memory and which don't I was pleasantly surprised to find out the always on IBM thinkpad I ran for years refused to work with non-ECC memory.
Greetings,
Jeroen
Laurent GUERBY wrote:
Do you have reference to recent papers with experimental data about non
ECC memory errors? It should be fairly easy to do
Maybe this provides some information:
"Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of DIMM memory modules affected by errors per year."
Dear Jeroen,
In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic.
Regards,
Douglas Otis
mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed 2,5d; date
Request for Comments: 3309 Stanford
September 2002
Wed Apr 18 23:07:53 EDT 2012
We are not in a static field... (3309 is one of my favorite RFCs -- but
the specific findings (errors happen more often than you think), as
opposed the general lesson (understand your threat model) may be OBE.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Dear Steve,
You may be right. However back then most were also only considering random single bit errors as well. Although there was plentiful evidence for where errors might be occurring, it seems many worked hard to ignore the clues.
Reminiscent of a drunk searching for keys dropped in the dark under a light post, mathematics for random single bit errors offer easier calculations and simpler solutions. While there are indeed fewer parallel buses today, these structures still exist in memory modules and other networking components. Manufactures confront increasingly temperamental bit storage elements, where most include internal error correction to minimize manufacturing and testing costs. Error sources are not easily ascertained with simple checksums when errors are not random.
Regards,
Douglas Otis
Yes -- that's precisely why I like that RFC so much.
--Steve Bellovin, https://www.cs.columbia.edu/~smb