IBM M1015 - Desktop hardware

[wintermute000]

for some reason some of the forum members seem to enjoy hazing newcomers.
i will say i am using a HP P410 on a crappy asrock desktop board that only has 1 pcie slot and it says *only supports most graphics cards* in the chinglish manual. but ZFS is best served with ECC ram and if you need to buy a card for use on crappy old hardware i would get a adaptec 5405(4 drives) or 5805(8 drives) and skip ZFS.
going 'low cost' can be done for ZFS but 'going cheap' can not.

Well put. If you don't have ecc then go hardware raid or standard Linux softraid. And a new ecc build is not expensive you can use Pentium cpu for example.
No ecc don't bother with zfs

 

[cyberjock]

The problem isn't with robustness at all. ECC is handled the same for AMDs and Intels. The problem is that it either is enabled and works or its not. Intel's are "relatively" easy to validate that it does or doesn't work. AMD's aren't validated much at all. You have to take them at their word for it. *if* a setup is using ECC then the same mathematical chances of failure are virtually identical for AMD as well as Intel. But that "if" is what screws AMD over. You can't validate it.

 

[Zedicus]

most intel mainboards iether do not allow you to adjust ECC or only let you turn it "on" or "off" however every AMD board i have seen gives you pages of ECC options and the first setting that says ECC enable only allows you to actually enable ECC options or not enable ECC options. it does not actually enable or disable ECC itself.

if you want to plug a bunch of expensive crap together and have something that 'just works' go the OCC route and 'assemble' an intel rig or buy a prebuilt.

if you don't mind rubbing 2 brain cells together to make a spark and you can read chingrish (and you are looking to save possibly thousands of dollars) then i recommend avoiding intel and prebuilts from dell.

also there are ways to tell rather the OS sees ECC or not. so while memtest offers a guestimate, you can make a quite accurate assumption after you get a BSD or *nix OS loaded. (even windows has some utilities that can fairly accurately tell you if the OS sees ECC or not)

i THINK cyberjock has seen numerous builds fail miserably and they have had a few things in common so with out serious investigation he likes to point at typical scenarios. i will agree, since the dawn of computing i have seen a ton of people royally FUBAR AMD builds and then blame it on AMD or the mainboard vendor. truth is, if your the type of person that throws a rig together and loads an OS and never boots into the bios or tunes any hardware settings then you might be better off NOT attempting a complex AMD build right out of the gate (with ECC and multiple NICs, 10gbe?) i spend a solid 2 days to a week with my builds with no hard drive installed booting various flash drive operating systems testing and poking the hardware and making tiny changes eeking every spec of performance i can muster. and if its a gaming rig and i am doing low level overclocking then its closer to a month.

the difference is a lot of intel based (AND ALL INTEL BRANDED) boards give you NONE of these options. and while it will run good as is that is it. besides maybe some overclocking if you have a high end gaming intel board.

think of the intel system as a Ferrari, its an amazing product out of the gate but it is proprietary and it is exaclty like every other Ferrari. while the AMD platform (it is a platform) is more like a Le Mans car. it is a set of rules and YOU must piece perfection together out of a million other vendors parts that are built to 'standards'.

 

[jgreco]

I am having problems imagining what useful BIOS options for ECC there would be beyond:

1) Enable
2) NMI or no NMI on uncorrectable error

The sad fact is that all the useful parts of ECC have to do with what actually happens when an ECC event occurs, ideally you want it logged in the system event log and to have that recognized by your NMS.

It sounds to me like you've seen some bastard board by some idiotic motherboard manufacturer who didn't really have a clue what ECC was and so just exposed a whole bunch of worthless crap in the BIOS and said "See we support ECC!" Which is approximately like a car manufacturer who throws some straps in the car and says "Oh sure we have seat belts!" and doesn't realize that seat belts need to be fastened to the frame to be meaningful.

As for standards? AMD builds to what standards, exactly? The problem with AMD is that they do not really have a complete product offering, so manufacturers have to piece together a system from various parts. I can show you some nightmare Tyan boards that had Broadcom gigE and Adaptec SCSI that played together in the worst possible ways to cause system freezes and crashes...

I also have no idea how going AMD would save you "thousands" of dollars given that a 32GB ECC-capable Intel system only costs around $700.

 

[cyberjock]

Frankly I'm not even sure why you'd not want ECC enabled. Just have the darn memory controller enable it if ECC RAM is installed. The only time I can think of that you'd want to disable ECC features is if you aren't using ECC RAM (duh!) or your RAM is bad and you don't want ECC crying to you (and you'd deserve what you get for operating under these circumstances anyway). So why not just have it use it if it exists. ;)

And Zedicus, yes that is some of it. But that's not *all* of it. Even if I try to piece together what could be a "great FreeNAS build on AMD" the fact of the matters have been discussed to death. So to summarize:

1. AMD doesn't spend money on open source (and especially FreeBSD) like it used to years ago. Not surprisingly their hardware doesn't work as well as Intel.
2. AMD's R&D budget has consistently shrank for more than 6 years running.
3. AMD laid off 1/2 of their open source developers 2 summers ago.
4. AMD has virtually no documentation on ECC support through their CPUs
5. AMD system are *meant* to be cheaper and *meant* to be lower end and you should be considering this when choosing hardware for a 24x7 server.
6. AMD's server market is rapidly shrinking

Put these together and the risk of going AMD seems pretty bad. Even the mode we have that went AMD has admitted that his on-board NIC went from working to non-working on an update. Buying AMD is like buying into a future that is pretty bleak for your server. Do you really want to put your data on a server that may or may not work with your hardware on an update? What if I told you that no AMD CPU in existence would work with FreeNAS 10 (no, that's not the case.. just hypothesizing)? You'd probably be pretty angry because you worked hard to build your server and such and suddenly you are being screwed over by it. For all we know next quarter AMD is going to announce they are exiting the server market. That would spell disaster for people that rely on AMDs for servers. AMD is in serious financial problems right now and anything is possible.

So which do you do.. recommend hardware that has an unusually high propensity for not working in the past, may or may not work today and may or may not work in the future and is based on a company that is having major financial troubles and their solution is to cut out the *very* departments you are about to rely on or spend a little more money and go with hardware that we know has worked in the past, works in the present, is extremely likely to work in the future and is based on a company that has financial incentive and means to help solve a problem that involves their hardware? The answer seems pretty darn obvious to me. ;)

My Intel system in my basement cost me $700 for motherboard, CPU and 32GB RAM. Thanks to me being smart I also never have to worry about a working NIC and I have massive CPU resources at my disposal because of my E3-1230v2. I could have just as easily gone with a Pentium G2020 and saved myself about $150. That would put a build with 32GB of RAM, dual Intel Gb NIC, IPMI, and processing power for FreeNAS at about $500-550. Kind of hard to say no to that, and almost 2/3 of the price tag is the RAM.. which is the same as what you'd buy with AMD.

 

[AlainD]

I am having problems imagining what useful BIOS options for ECC there would be beyond:

1) Enable
2) NMI or no NMI on uncorrectable error

The sad fact is that all the useful parts of ECC have to do with what actually happens when an ECC event occurs, ideally you want it logged in the system event log and to have that recognized by your NMS.
...

I remember memory scrub time interval and options to adapt the scrub speed to memory usage from the applications.
The first seems useful, the other only for a few applications (reasonable default should be in place).