User talk:Taiidan: Difference between revisions
(Created page with "We should add a section for the POWER arch here - Taiidan 1/27/17") |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
We should | == D16 192GB RAM == | ||
Hello there, | |||
Did you verify that claim? We have tried to make the D16 work with 192GB of RAM as you mention in the wiki (because we talked to tpearson too), but it didn't work. Other users made the same experience. | |||
The current status is (or was) that it only works with 128GB of RAM, and that very stable under full load. Unless there has been a recent development I've missed, I don't think that this has changed. | |||
Could you please elaborate on that in order to keep the wiki up to date and stating verified facts? | |||
Thanks, :) | |||
Thomas | |||
---- | |||
I hope you are watching this page | |||
I recently asked tim on the mailing list and he said it would work. | |||
""""""" | |||
-----BEGIN PGP SIGNED MESSAGE----- | |||
Hash: SHA1 | |||
On 01/27/2017 03:27 PM, Taiidan@gmx.com wrote: | |||
> Is anyone using this configuration? does it work reliably? I am asking | |||
> as I don't know if this has been fixed yet. | |||
> | |||
> For a real server platform this is a must have, the ram issues are the | |||
> one valid point that leah made... | |||
> | |||
> - Thanks in advance for any replies | |||
> | |||
We use such a machine here in production, with the caveat that an older | |||
coreboot revision is used. That being said, keep the four slots closest | |||
to CPU1 unpopulated (i.e. fill all 8 slots on CPU0, and the 4 farthest | |||
from CPU1) and you should have no problems reaching 192GB. Those | |||
particular slots appear to have physical routing layer issues caused by | |||
marginal design, and thus far we have had no reason to even attempt a | |||
workaround given the high cost involved. | |||
As always, if someone else would like to try to work around the | |||
corruption issues, they are more than welcome. Populating all four | |||
slots closest to CPU1 with large ECC registered DIMMs is a surefire way | |||
to recreate the instability -- note a training failure is not common, | |||
the main issue is that the marginal routing causes severe memory | |||
corruption when the BKDG-recommended algorithms are used. | |||
- -- | |||
Timothy Pearson | |||
Raptor Engineering | |||
+1 (415) 727-8645 (direct line) | |||
+1 (512) 690-0200 (switchboard) | |||
https://www.raptorengineering.com | |||
-----BEGIN PGP SIGNATURE----- | |||
Version: GnuPG v1 | |||
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ | |||
iQEcBAEBAgAGBQJYi7zeAAoJEK+E3vEXDOFbmOEH/itJEw/sz6Dq4LFSXQqMEKPS | |||
cAY7/YoP8hEfsHBjP+buyKyRyj7Q9988dhrgd4db/cU4QWD5XACYTUTZJMKcnpav | |||
/MwAWpjxOD9IPginTRCUKwvDhhdnt8IQIe2cNV4ujj57nvkOpgPhrM8eR//11HP+ | |||
qtqc7EXUR9RmxIP/cn2GJ7MWZ8+DqJbdmdeTqdF9xo6YkQ2RceYyFbofEoONBN9R | |||
nQgz6wysrgH/jZkhTcwR23TZCcJcx6DV7gEuwHj5K/9iqXWqX+gAr8bMB8rii9HA | |||
zqCYWp1Ihm+hHBfGvxZ4niy5yQyU2Dq+80CjtkN8qiG0c7ThHlk84ZRo5sQDgjM= | |||
=L5ST | |||
-----END PGP SIGNATURE----- | |||
-- | |||
coreboot mailing list: coreboot@coreboot.org | |||
https://www.coreboot.org/mailman/listinfo/coreboot | |||
"""""" | |||
Latest revision as of 04:46, 7 February 2017
D16 192GB RAM
Hello there,
Did you verify that claim? We have tried to make the D16 work with 192GB of RAM as you mention in the wiki (because we talked to tpearson too), but it didn't work. Other users made the same experience. The current status is (or was) that it only works with 128GB of RAM, and that very stable under full load. Unless there has been a recent development I've missed, I don't think that this has changed. Could you please elaborate on that in order to keep the wiki up to date and stating verified facts?
Thanks, :)
Thomas
I hope you are watching this page
I recently asked tim on the mailing list and he said it would work.
"""""""
BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 01/27/2017 03:27 PM, Taiidan@gmx.com wrote: > Is anyone using this configuration? does it work reliably? I am asking > as I don't know if this has been fixed yet. > > For a real server platform this is a must have, the ram issues are the > one valid point that leah made... > > - Thanks in advance for any replies >
We use such a machine here in production, with the caveat that an older coreboot revision is used. That being said, keep the four slots closest to CPU1 unpopulated (i.e. fill all 8 slots on CPU0, and the 4 farthest from CPU1) and you should have no problems reaching 192GB. Those particular slots appear to have physical routing layer issues caused by marginal design, and thus far we have had no reason to even attempt a workaround given the high cost involved.
As always, if someone else would like to try to work around the corruption issues, they are more than welcome. Populating all four slots closest to CPU1 with large ECC registered DIMMs is a surefire way to recreate the instability -- note a training failure is not common, the main issue is that the marginal routing causes severe memory corruption when the BKDG-recommended algorithms are used.
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
BEGIN PGP SIGNATURE-----
Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJYi7zeAAoJEK+E3vEXDOFbmOEH/itJEw/sz6Dq4LFSXQqMEKPS cAY7/YoP8hEfsHBjP+buyKyRyj7Q9988dhrgd4db/cU4QWD5XACYTUTZJMKcnpav /MwAWpjxOD9IPginTRCUKwvDhhdnt8IQIe2cNV4ujj57nvkOpgPhrM8eR//11HP+ qtqc7EXUR9RmxIP/cn2GJ7MWZ8+DqJbdmdeTqdF9xo6YkQ2RceYyFbofEoONBN9R nQgz6wysrgH/jZkhTcwR23TZCcJcx6DV7gEuwHj5K/9iqXWqX+gAr8bMB8rii9HA zqCYWp1Ihm+hHBfGvxZ4niy5yQyU2Dq+80CjtkN8qiG0c7ThHlk84ZRo5sQDgjM= =L5ST
END PGP SIGNATURE-----
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot """"""