ECC or non ECC memory
Oct 6, 2009 at 8:23 PM Post #31 of 62
Quote:

I guess you nay-sayers can refute google?


4,000 errors a year in a machine that's up 24/7/365 (or even 5 9s) is amazingly low. This is also in Google's environment - they're known to use cheaper hardware and leave stuff running hotter than most companies. And again, it doesn't make a difference in home machines.
 
Oct 6, 2009 at 10:25 PM Post #32 of 62
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
...except when you're ripping or copying files.

and then, bit errors sneak into your data files and unless you check, you'll happily be copying and keeping bad files.



Heh yeah, I'm sure you know what a checksum is (and how such algorithms work)? Heard of AccurateRip?

You can easily verify if something went wrong (Not that there is a need to!) and this actually happens automatically at rip-time if you use e.g. EAC or similar tools.

Most filesystems also incorporate checksums or similar algorithms to detect errors.



Quote:

Originally Posted by Arainach /img/forum/go_quote.gif
And again, it doesn't make a difference in home machines.


Exactly.
 
Oct 6, 2009 at 10:58 PM Post #33 of 62
Quote:

Originally Posted by xnor /img/forum/go_quote.gif
Heh yeah, I'm sure you know what a checksum is (and how such algorithms work)? Heard of AccurateRip?

You can easily verify if something went wrong (Not that there is a need to!) and this actually happens automatically at rip-time if you use e.g. EAC or similar tools.

Most filesystems also incorporate checksums or similar algorithms to detect errors.



you totally 100% miss the point.

and you get things wrong, too.

wrong: redbook has NO checksums. go check (lol). dvd, now THAT is a true filesystem but redbook is not a filesystem, its simply a stream of data. this is why 'ripping' is an inexact art. you can know that you get the same block over and over again on re-reads but that does NOT mean its the true bit-block.

how you missed the point: even if you used zfs and had lots of checking done, how on earth does that fix the errors that hit the ram chips while the data is in memory?

the only way to truly fix this is data integrity where metadata is checked at EVERY hand-over (device drivers, ram, disks, everything!). linux has some work in that area (I've not seen it in freebsd yet) and I believe solaris can do that kind of checking. regular MS os's can't; they simply do not have the kind of architecture to allow for 'hand off' meta data. its only been in linux for a year or so, or something very recent like that.

at least having ECC will ensure that you minimize the errors to the data WHILE the data is in ram.

lots of things go thru ram. having the ram be a bit more sure is only going to help. the 'speed loss' may matter for games, but I'm not at all talking about gaming, here. I never was.
 
Oct 6, 2009 at 11:00 PM Post #34 of 62
Quote:

Originally Posted by Arainach /img/forum/go_quote.gif
4,000 errors a year in a machine that's up 24/7/365 (or even 5 9s) is amazingly low. This is also in Google's environment - they're known to use cheaper hardware and leave stuff running hotter than most companies. And again, it doesn't make a difference in home machines.


home machine: tend to be undercooled, run by amateurs and using cheap hardware with essentially no PM done by the operators.

nice try, though.
 
Oct 6, 2009 at 11:05 PM Post #35 of 62
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
home machine: tend to be undercooled, run by amateurs and using cheap hardware with essentially no PM done by the operators.


home machine: doesn't run an enormous search engine and database that is servicing hundred of thousands (if not millions) of requests and is constantly hammering the crap out of storage and memory.

nice try, though.
 
Oct 6, 2009 at 11:42 PM Post #36 of 62
a bit error that goes uncorrected is serious.

to me.

apparently not to you. that's fine. but you can't argue you have a BETTER system; in fact your system is less robust. unless the error hits are zero, ANY number of hits that get corrected vs let pass could be a click in a song.

people here are really anal about cables and stuff like that. I find it unimaginable that people would say 'oh well, just rerip the song' if they get clicks in it due to an error in ram.
 
Oct 7, 2009 at 12:03 AM Post #37 of 62
Oh my god. Oh man linuxworks. If you actually work at a company running servers (or like...anything) you should definitely be fired and a normal person should replace you.
 
Oct 7, 2009 at 12:06 AM Post #38 of 62
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
I find it unimaginable that people would say 'oh well, just rerip the song' if they get clicks in it due to an error in ram.


Your ECC- will not help you in ripping music out of cd's... dear lord, how dumb can you be?? Have you actually read anything you've typed??
 
Oct 7, 2009 at 12:13 AM Post #39 of 62
Quote:

Originally Posted by linuxworks /img/forum/go_quote.gif
Slashdot | Google Finds DRAM Errors More Common Than Believed

"A Google study of DRAM errors in their data centers found that they are hundreds to thousands of times more common than has been commonly believed. Hard errors may be the most common failure type. The DIMMs themselves appear to be of good quality, and bad mobo design may be the biggest problem."

I guess you nay-sayers can refute google?



Congrats, you've ripped an article out of context to justify your point. It's very deplorable of you.

Quote:

how you missed the point: even if you used zfs and had lots of checking done, how on earth does that fix the errors that hit the ram chips while the data is in memory?


If a RAM error occurs (and that's a LARGE if), then the check between a second read and the first read won't match. It will read multiple times until it does, it fails, or list the rip as inaccurate depending on one's settings.

Therefore your point is mostly lost on the "ripping music" segment. For the issue to be substantial you would need consistent memory errors in multiple memory blocks, and at that point you're already talking changing the memory module because it's suffering from issues that will eventually cause more substantial problems consistently. And let's be honest, ECC isn't used to fix consistent errors caused by most likely a failing module, if the issue's large enough (which it would have to be to mess up ripping) then it isn't going make a lick of difference.

Quote:

home machine: tend to be undercooled, run by amateurs and using cheap hardware with essentially no PM done by the operators.


Actually, you'll find that Google uses notoriously cheap hardware in clusters to do what they want. Probably why they're having problems with motherboards . . . but that contradicts your position
tongue.gif
 
Oct 7, 2009 at 12:23 AM Post #40 of 62
Quote:

Originally Posted by maarek99 /img/forum/go_quote.gif
Your ECC- will not help you in ripping music out of cd's... dear lord, how dumb can you be?? Have you actually read anything you've typed??


I'll ignore your snide remark.

how ecc helps with ripping: data is stored in ram for a time between rip and write to disk.

do you deny that bit errors occur? do you think that its impossible that the bit error happens while the song data is still in ram?
 
Oct 7, 2009 at 12:31 AM Post #41 of 62
Quote:

Originally Posted by maarek99 /img/forum/go_quote.gif
Oh my god. Oh man linuxworks. If you actually work at a company running servers (or like...anything) you should definitely be fired and a normal person should replace you.


one more abusive message and this thread will be yanked.

you want that?

then please stop with the insults.

I have MORE than enough server experience to know what I'm talking about, thank you very much. if you doubt it, pm me and we'll take this crap talk offline.
 
Oct 7, 2009 at 12:58 AM Post #42 of 62
Quote:

Originally Posted by Arainach /img/forum/go_quote.gif
4,000 errors a year in a machine that's up 24/7/365 (or even 5 9s) is amazingly low. This is also in Google's environment - they're known to use cheaper hardware and leave stuff running hotter than most companies. And again, it doesn't make a difference in home machines.


I would consider ANY memory errors a bad thing and consider them to "make a difference in home machines". If you do not, that is completely your choice. When it comes to stating that it "does not make a difference" and recommending against ECC is another story. If you would like to use non-ECC memory, nobody will stop you. If you recommend people stay away from it, well, that should be their choice and they should make an informed decision based on facts, not what some consider worthwhile.

Quote:

Originally Posted by maarek99 /img/forum/go_quote.gif
Your ECC- will not help you in ripping music out of cd's... dear lord, how dumb can you be?? Have you actually read anything you've typed??


Welcome to my ignore list you rude, ignorant prick. I hope you can back up that claim and whoever reads your message knows enough to doubt what people say.
 
Oct 7, 2009 at 1:11 AM Post #43 of 62
Quote:

Originally Posted by FallenAngel /img/forum/go_quote.gif
I would consider ANY memory errors a bad thing and consider them to "make a difference in home machines". If you do not, that is completely your choice. When it comes to stating that it "does not make a difference" and recommending against ECC is another story. If you would like to use non-ECC memory, nobody will stop you. If you recommend people stay away from it, well, that should be their choice and they should make an informed decision based on facts, not what some consider worthwhile.


How about practically every RAM manufacture saying ECC is only necessary for commercial servers? Including Crucial, which I linked to earlier in this thread.
 
Oct 7, 2009 at 1:20 AM Post #44 of 62
that's really old fashioned thinking, that only 'business big machines' need data integrity protection.

I have no idea what agenda the ram companies have (that you claim) but they certainly have no business talking people out of this benefit. perhaps their margins are higher for non-ecc ram or that they have a lot more of it in stock and they want to push that?

those are sales entities. you want to trust them to advise you??

the google article does show that ram errors are not 'unusual' and they happen all the time.

putting your head in the ground and ostriching is not helping matters.

do you drive without your seatbelt? you're only going "down the street", so why even use it? what are the *chances* of getting hit in such a short distance?

but you see, that's not the point. the point is that safety is safety. you can rationalize it away but you ARE being less safe if you choose to not avail yourself to tech that can help cover for errors in memory.

memory is the transit for all i/o devices. its the critical path, other than the cpu itself.
 
Oct 7, 2009 at 1:31 AM Post #45 of 62
Quote:

Originally Posted by FallenAngel /img/forum/go_quote.gif
I would consider ANY memory errors a bad thing and consider them to "make a difference in home machines". If you do not, that is completely your choice. When it comes to stating that it "does not make a difference" and recommending against ECC is another story. If you would like to use non-ECC memory, nobody will stop you. If you recommend people stay away from it, well, that should be their choice and they should make an informed decision based on facts, not what some consider worthwhile.


What most posters in this thread are arguing is "Go ahead and buy ECC memory only if there's no difference in price against non-ECC". What linuxworks is arguing, and what everyone is against, is that ECC memory is REQUIRED for a home desktop computer and should be purchased regardless of price.

People are saying to stay away from it because, usually, ECC memory is quite a bit more expensive than non-ECC memory, and that premium isn't justified for a home computer.
 

Users who are viewing this thread

Back
Top