Page 1 of 1

fitlet-T - Will it have ECC memory support?

Posted: Mon Nov 30, 2015 3:13 am
by Arwen
The SoC that's supposed to be used in the model fitlet-T, seems to support ECC memory.
(Of course, I say "supposed to" and "seems to", because the fitlet-T has not been released.)

If you did support ECC memory in the fitlete-T, I would likely upgrade from my fitlet-H. Which
is really an upgrade from a fitlet-iA10... It's just the intended use, media server NAS, is using
ZFS which works better with ECC memory.

Re: fitlet-T - Will it have ECC memory support?

Posted: Thu Dec 03, 2015 6:44 am
by irads
fitlet-T does not support ECC RAM. The ECC SODIMM is different than non-ECC one which is installed in fitlet-T.

Re: fitlet-T - Will it have ECC memory support?

Posted: Sun Dec 06, 2015 12:41 am
by Arwen
irads,

Does DDR3 SO-DIMM ECC memory use a different socket?

It's been hard trying to find that out. I know standard size DDR3 DIMMs for server
boards can sometimes take either non-ECC or ECC memory. Same socket.

Re: fitlet-T - Will it have ECC memory support?

Posted: Mon Dec 07, 2015 4:42 pm
by mbirger
Both, ECC and non-ECC SO-DIMMs use the same mechanical form factor connector, but their pinout is different. DDR3 SO-DIMM with ECC uses a different protocol with additional 8 bits of Error Correction Code.

Please refer to this doc for differences:
http://www.intel.com/content/dam/www/pu ... -paper.pdf

Re: fitlet-T - Will it have ECC memory support?

Posted: Wed Dec 09, 2015 3:59 pm
by Arwen
mbirger,
Thank you. That link explains it better. Full sized memory DIMMs seem to use the same pin
out for both non-ECC and ECC memory. Thus, some server boards can take either depending
on the need.

It's a shame the DDR3 SO-DIMM socket wiring is not compatible between non-ECC and ECC
memory. I hope they fixed that with DDR4 SO-DIMMs.

One reason why people want ECC memory is that they may use the computer both for a long
time, and as a server. Some file systems like Linux's EXT2|3|4 don't do too badly with
corruption. If the corruption, (like due to memory bit flip before writing to disk), is minor, the
rest of the data may be okay. Annoying you can't detect what's failed, but all file systems of
the past had that problem.

Enter today, with 2 error detecting and potentially correcting file systems, ZFS and BTRFS.
Both can detect problems AFTER they enter the disk I/O stream. But, if a bit flipped in
memory BEFORE the block checksum is calculated, then it does not know the block is bad
and treats it as perfectly good :-(. Quite a problem if it's a superblock or equivelent.

PS: The note about ZFS and BTRFS potentially correcting is related to redundancy. Basically
if the file system is mirrored, (or RAID-Z/RAID-5, or better), and a disk read fails the
checksum match, the disk block is recovered from the redundancy and supplied to the
program. Then the corrected data is attempted to be re-written to the failed location.