4 ms·

Does it make any difference if you're using your desktop to compile stuff?

by gyrgtyn 10y ago

ddingus 10y ago
If you want to be sure it's right, yes. Here is the thing: Without ECC, or even simple parity on the RAM, the CPU cannot validate a data transfer. In the 90s, a place I worked for had a server running non parity, non ECC RAM. That machine was fast and cheap. But it would demonstrate the most bizarre problems, from time to time. A fresh OS install would fix it. Then a year or so, off the farm again. I saw no error correction, had it replaced with a very similar machine, no issues. The argument was, it's only the possibility, and only once in a blue moon... The bigger the RAM, the faster we do stuff, the sooner "once in a blue moon" tends to happen. I did put that box on my personal network, and under Linux (was win NT before), seemed fine. In the syslog, after a year, there were various kernel messages, each recovered, but there was something to recover from... Win NT would blue screen a lot. That's different today with better kernel software from Microsoft, but the point is no error correction comes with no real way to understand where some trouble may have come from. And that was doing light duty stuff. Didn't trust it for a build, frankly. We get fast, quality, cheap. Pick two :D more generally, the fact that the CPU cannot know if it's transactions with RAM make any sense, unless ECC or even simple parity are present, should be a worry today. Our processes are small, clocks fast, density high. We are pushing it on all fronts! Best employ error correction. And, back in the day, the Apple 2 had no parity on its RAM, the first IBM PC did. Even those much larger, more robust circuits, clocked slowly, would throw bit errors. The IBM guys knew that from their experiences.
- Zardoz84 10y ago
  > I did put that box on my personal network, and under Linux (was win NT before), seemed fine. In the syslog, after a year, there were various kernel messages, each recovered, but there was something to recover from... Win NT would blue screen a lot. That's different today with better kernel software from Microsoft, but the point is no error correction comes with no real way to understand where some trouble may have come from. Haha, I remember my first steps with Linux in 1998/99. I got a faulty hard disk of 100MiB that on Windows was constantly getting errors. How ever, when I try to use it on Linux, I found that was working without any issue.
  - ddingus 10y ago
    Yeah, good times back then. :D I ran a Win, IRIX, Linux network in my cube. Had, like 5 machines all doing various things. Here's another similar thing: Someone handed me a 33mhz SGI Indigo. "What can we do with it?" I compiled a little program called "amp" to play Mp3 files, just wondering... That thing could actually play 256kbps files, shared over NFS, while also offering a desktop. Someone else made a little app that could select tunes, start, stop. I could tell the bitrate based on the CPU load. Put that and the SGI mixer on the screen, and it was the department tunes. I took it home at one point, where it continued to do that task well into the 00s CPU utilization was 95 percent, but ran all day long for weeks, not a stutter. The general point being, a UNIX, Linux could do magic on trash, old, odd, slow, gear and not miss a beat. An old Pentium 90, running RH 5.2 served up the web pages while also acting as firewall and doing mail. That thing was literally a dumpster dive. It had NT on it, and just would not run no matter what. Linux did, with a stream of kernel chatter in syslog. A console window (tail -f) showed this stream of scary looking text the whole time. crazy! That was a stunt. Worked. Should not have. Did a few months duty, the real machine queued up, just in case.
ddingus 10y ago
Today, one can buy good hardware and get a seriously long run time on it. A spend for a fast, robust, ECC machine is worth it. During the rapid ramp up early on, price arguments were stronger because replacement came much sooner. Today, particularly on desktop, one can get a killer machine and run it more than long enough to factor out the cost of ECC.

Does it make any difference if you're using your desktop to compile stuff?

by gyrgtyn 10y ago

Does it make any difference if you're using your desktop to compile stuff?

If you want to be sure it's right, yes. Here is the thing: Without ECC, or even simple parity on the RAM, the CPU cannot validate a data transfer. In the 90s, a place I worked for had a server running non parity, non ECC RAM. That machine was fast and cheap. But it would demonstrate the most bizarre problems, from time to time. A fresh OS install would fix it. Then a year or so, off the farm again. I saw no error correction, had it replaced with a very similar machine, no issues. The argument was, it's only the possibility, and only once in a blue moon... The bigger the RAM, the faster we do stuff, the sooner "once in a blue moon" tends to happen. I did put that box on my personal network, and under Linux (was win NT before), seemed fine. In the syslog, after a year, there were various kernel messages, each recovered, but there was something to recover from... Win NT would blue screen a lot. That's different today with better kernel software from Microsoft, but the point is no error correction comes with no real way to understand where some trouble may have come from. And that was doing light duty stuff. Didn't trust it for a build, frankly. We get fast, quality, cheap. Pick two :D more generally, the fact that the CPU cannot know if it's transactions with RAM make any sense, unless ECC or even simple parity are present, should be a worry today. Our processes are small, clocks fast, density high. We are pushing it on all fronts! Best employ error correction. And, back in the day, the Apple 2 had no parity on its RAM, the first IBM PC did. Even those much larger, more robust circuits, clocked slowly, would throw bit errors. The IBM guys knew that from their experiences.

Zardoz84 10y ago
> I did put that box on my personal network, and under Linux (was win NT before), seemed fine. In the syslog, after a year, there were various kernel messages, each recovered, but there was something to recover from... Win NT would blue screen a lot. That's different today with better kernel software from Microsoft, but the point is no error correction comes with no real way to understand where some trouble may have come from. Haha, I remember my first steps with Linux in 1998/99. I got a faulty hard disk of 100MiB that on Windows was constantly getting errors. How ever, when I try to use it on Linux, I found that was working without any issue.
- ddingus 10y ago
  Yeah, good times back then. :D I ran a Win, IRIX, Linux network in my cube. Had, like 5 machines all doing various things. Here's another similar thing: Someone handed me a 33mhz SGI Indigo. "What can we do with it?" I compiled a little program called "amp" to play Mp3 files, just wondering... That thing could actually play 256kbps files, shared over NFS, while also offering a desktop. Someone else made a little app that could select tunes, start, stop. I could tell the bitrate based on the CPU load. Put that and the SGI mixer on the screen, and it was the department tunes. I took it home at one point, where it continued to do that task well into the 00s CPU utilization was 95 percent, but ran all day long for weeks, not a stutter. The general point being, a UNIX, Linux could do magic on trash, old, odd, slow, gear and not miss a beat. An old Pentium 90, running RH 5.2 served up the web pages while also acting as firewall and doing mail. That thing was literally a dumpster dive. It had NT on it, and just would not run no matter what. Linux did, with a stream of kernel chatter in syslog. A console window (tail -f) showed this stream of scary looking text the whole time. crazy! That was a stunt. Worked. Should not have. Did a few months duty, the real machine queued up, just in case.

ddingus 10y ago

Today, one can buy good hardware and get a seriously long run time on it. A spend for a fast, robust, ECC machine is worth it. During the rapid ramp up early on, price arguments were stronger because replacement came much sooner. Today, particularly on desktop, one can get a killer machine and run it more than long enough to factor out the cost of ECC.