I don't suppose it means anything that Cray's next supercomputer is going to be an Alpha Linux cluster...
Honestly though, Linux lacks the tools to make this sort of thing a straightforward setup. Configuring Linux from the ground up gets you there, but that's a tedious process that most people don't want to go through. ("What, Linux from Scratch? Ummm...can I have ReliantHA, please?") Also, as of glibc 2.1.3, the basic GNU/Linux system as a whole was not completely POSIX compliant. Some of the missing POSIX features (like atomic file locking, which finally works in glibc 2.2) are actually very good features to have;)
I don't know what Caldera's claim on Linux threads vs SCO threads is all about. If Linux threads don't actually share the code segment's space (which I doubt) then there could be a performance hit, I suppose. A lot of people insist that the Linux __clone() call (the basis for Linux threading) is not "real" threading, but I fail to see where it differs or takes a significant performance hit.
There's a reghack-NOT-patch for your particular scenario. I had similar problems under Win2K until I applied this fix--crashed every few hours, especially in 3D games. It's chipset independent--happens with VIA, SiS, ALI, AMD, you name it. I applied this fix, and Win2K now actually gets uptime comparable to WinNT. That's not saying much, I know...
Interesting that it only happens with Win2K. Says something about that O/S...like maybe it was rushed out of the door? Not like that's anything new from MS.
Folding works, I guess...but having the cable actually separated pin by pin and rounded is even easier to work with.
Btw, you can actually get cables pre-rounded. IDE (40-conductor), floppy, and SCSI are all available in a rounded form. For LVD SCSI, that's actually a fairly common form to get it in, since LVD cable starts off as individual twisted-pair wires anyways. For other cables, you just have to either look around a bit harder than usual or be ready to have your cables custom punched from appropriate parts (I use AMP). Custom punching cables really isn't that hard, btw, but the tools and the bulk supplies are a bit costly if you just want a few cables.
As for ATA66/100 (80-conductor)...that stuff has very delicate signaling. Folding or stacking the stuff causes erratic performance drops; I don't even want to think of what rounding would do to it. If you ever want to see these performance drops in action, run WinBench's Disk Inspection Tests and watch the Disk Transfer Rate graph during the test.
First, I have to say, this situation is ridiculous. Thankfully, MS doesn't rule the world enough to force us to use MS SQL (although they'd like to think they do), and as I don't use MS SQL, I have no reason to complain about the license. This benchmark-NDA would be a real thorn if I had to use MS SQL (or Oracle), though.
This being said, the whole thing is a chess game of billion-dollar egos. Larry Ellison is, in a roundabout way, launching FUD at MS. The best way for MS to refute Ellison's claim is by having him disclose the info he's gathered or conjured; if MS doesn't demand that, it could make it seem like MS is scared of the results. Instead of refuting Ellison's claim, MS is whining about technicalities. I think Larry's winning this round of ego-chess, unless he's bluffing.
I can't actually provide links, but I can provide some Linux common-knowledge.
As most Linux specialists probably know, the kernel calculates a rough estimate of the system's speed in BogoMIPs (bogus MIPs) when it is first initialized. This figure probably gets used a lot for imposing delays etc., especially I/O wise, where an I/O wait period is much smaller than the x86 clock chip's maximum speed. I can't be 100% certain of this because I'm not a mighty kernel hacker yet =P.
A word of technical detail on the x86 clock chip (skip if bored): every x86 chipset since the PC (I think) has at the very least a single system clock chip on it which gets split into three separate clock master signals. One is for DRAM Refresh (so you can't monkey with that one--much); another is equally vital, although I don't remember exactly what it does. The third is spare for system use, but is by default used for maintaining the BIOS software clock, whether a Real Time Clock (RTC) circuit is present or not.
This third signal can be set to a pretty high frequency, but it is sometimes not high enough to impose I/O wait periods in hardware drivers without making those wait periods longer than necessary and impacting system performance. I think this is usually where BogoMIPs get used...
The bad thing about BogoMIPs is that they are only a rough figure of performance and often get used as a more precise measure than they really are (usually not in a stable kernel though).
The bad thing about BogoMIPs and PowerNow is that BogoMIPs will become even *less* accurate than before. This is probably a very serious problem, as up until now, the kernel has been able to assume that a CPU will stay at the same speed it had at boot time and thus assume a fair degree of consistency in the actual BogoMIPs rate at any time. This assumption is no longer valid with PowerNow.
So...my guess is that this PowerNow thing WILL cause a severe problem--not just with Linux, but possibly with many other operating systems as well. This problem could be worked out, though; the kernel is capable of monitoring CPU clock frequency, so that clock speed at any given time, combined with clock speed at the time of BogoMIPs calculation, could be used to calculate a factor to apply to the original BogoMIPS calculation and thus get a fairly accurate current BogoMIPS calculation. This would probably impact performance a bit.
I'd guess that in future kernels, you would see the "Support PowerNOW!" config option within the CPU Features submenu of the kernel config script. For those who don't know about this (and are actually interested in knowing), check the Kernel-HOWTO at Linuxdoc.org.
Hoo...all that karma whoring. I feel dirty now...I think I'll take a shower.
This still doesn't cover the issue of intermittent failures, though. Think on this: if memory were obviously good or bad, then bad memory would probably not even pass the initial memory check in a system. Yet bad memory often does pass even the most strenuous checks, even with ECC enabled (I had this problem myself). And if the "good/bad" status falls about such a hazy line, how effective can any piece of software be at singling out a defective chip?
This BadRAM patch will probably improve the situation, of course, but it can't pick out every bad chip thrown at it unless it checks every chip for eternity. Obviously, that's not going to happen...so...system reliability is still compromised, if only less so.
That's about as low-level as it gets unless you're actually coding all the software yourself. It's not actually a distribution, per se, but rather a manual that tells you where to get the basic software source tarballs, how to compile and install them, etc.
Slackware is good too. All stable release software, all compiled with reasonable options.
Hmmm I have to side with the RedHat basher on this one. I have used RedHat 5.1, 5.2, 6.0, 6.1, and 6.2, and their quality started to take a nose dive at 6.0. The reason I have used them anyways is because where I work, that is all Engineering ever has approved for sale (without trying any other distros, I add, except Mandrake). Of course, even though I'm the only one there who knows Linux well, they don't listen to me =/.
5.1 and up have issues with LILO (sometimes it won't install during the initial install script), but nothing that couldn't be worked around. 6.0...the issues seemed to get a little better. 6.1...Samba didn't work in some cases, DHCP was flaky, etc. etc. 6.2, the problems are worse. 7.0, I believe the phrase is "look out below." RedHat posts fixes, of course, but I prefer a distro that's fairly stable right out of the box. FYI, I run Slackware and Linux From Scratch.
Ummm...Slackware 7.0 and Linux From Scratch runs completely stable for me. Part of this may be that of all the software I have, only the nVidia Detonator driver, the 2.2.16 AGP patch, and the DPT SmartRAID V driver are classified as "beta."
As for fsck, I had to run fsck about 20 times the first time I installed LFS (debugging my own custom system boot scripts and/etc/inittab). Aside from finding a few inodes with bad dtime, the filesystem was repaired flawlessly, and the system remained rock-solid.
As for compiling problems, I had a minor problem compiling the kernel at first, until I moved genksyms to its proper location (something the LFS book left out). Everything else was solved by actually following the accompanying documentation.
As for RedHat, I would never use it as an example of the stability of Linux. RedHat is loaded with beta software. What's bad is that unless you're looking close, you won't notice the "beta-ness." (i.e. you see kernel version 2.2.14-5.0, think "2.2.14=STABLE," and put the appended "5.0" out of your mind. Trust me, 2.2.14-5.0 is at least part beta).
Slashdot Mirror
I don't suppose it means anything that Cray's next supercomputer is going to be an Alpha Linux cluster...
Honestly though, Linux lacks the tools to make this sort of thing a straightforward setup. Configuring Linux from the ground up gets you there, but that's a tedious process that most people don't want to go through. ("What, Linux from Scratch? Ummm...can I have ReliantHA, please?") Also, as of glibc 2.1.3, the basic GNU/Linux system as a whole was not completely POSIX compliant. Some of the missing POSIX features (like atomic file locking, which finally works in glibc 2.2) are actually very good features to have ;)
I don't know what Caldera's claim on Linux threads vs SCO threads is all about. If Linux threads don't actually share the code segment's space (which I doubt) then there could be a performance hit, I suppose. A lot of people insist that the Linux __clone() call (the basis for Linux threading) is not "real" threading, but I fail to see where it differs or takes a significant performance hit.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
OT: in case you want to try Win2K again...
There's a reghack-NOT-patch for your particular scenario. I had similar problems under Win2K until I applied this fix--crashed every few hours, especially in 3D games. It's chipset independent--happens with VIA, SiS, ALI, AMD, you name it. I applied this fix, and Win2K now actually gets uptime comparable to WinNT. That's not saying much, I know...
Interesting that it only happens with Win2K. Says something about that O/S...like maybe it was rushed out of the door? Not like that's anything new from MS.
Kelledin Tane, the Dreaming Minstre
"All your base are belong to us."
Folding works, I guess...but having the cable actually separated pin by pin and rounded is even easier to work with.
Btw, you can actually get cables pre-rounded. IDE (40-conductor), floppy, and SCSI are all available in a rounded form. For LVD SCSI, that's actually a fairly common form to get it in, since LVD cable starts off as individual twisted-pair wires anyways. For other cables, you just have to either look around a bit harder than usual or be ready to have your cables custom punched from appropriate parts (I use AMP). Custom punching cables really isn't that hard, btw, but the tools and the bulk supplies are a bit costly if you just want a few cables.
As for ATA66/100 (80-conductor)...that stuff has very delicate signaling. Folding or stacking the stuff causes erratic performance drops; I don't even want to think of what rounding would do to it. If you ever want to see these performance drops in action, run WinBench's Disk Inspection Tests and watch the Disk Transfer Rate graph during the test.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
First, I have to say, this situation is ridiculous. Thankfully, MS doesn't rule the world enough to force us to use MS SQL (although they'd like to think they do), and as I don't use MS SQL, I have no reason to complain about the license. This benchmark-NDA would be a real thorn if I had to use MS SQL (or Oracle), though.
This being said, the whole thing is a chess game of billion-dollar egos. Larry Ellison is, in a roundabout way, launching FUD at MS. The best way for MS to refute Ellison's claim is by having him disclose the info he's gathered or conjured; if MS doesn't demand that, it could make it seem like MS is scared of the results. Instead of refuting Ellison's claim, MS is whining about technicalities. I think Larry's winning this round of ego-chess, unless he's bluffing.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
I can't actually provide links, but I can provide some Linux common-knowledge.
As most Linux specialists probably know, the kernel calculates a rough estimate of the system's speed in BogoMIPs (bogus MIPs) when it is first initialized. This figure probably gets used a lot for imposing delays etc., especially I/O wise, where an I/O wait period is much smaller than the x86 clock chip's maximum speed. I can't be 100% certain of this because I'm not a mighty kernel hacker yet =P.
A word of technical detail on the x86 clock chip (skip if bored): every x86 chipset since the PC (I think) has at the very least a single system clock chip on it which gets split into three separate clock master signals. One is for DRAM Refresh (so you can't monkey with that one--much); another is equally vital, although I don't remember exactly what it does. The third is spare for system use, but is by default used for maintaining the BIOS software clock, whether a Real Time Clock (RTC) circuit is present or not.
This third signal can be set to a pretty high frequency, but it is sometimes not high enough to impose I/O wait periods in hardware drivers without making those wait periods longer than necessary and impacting system performance. I think this is usually where BogoMIPs get used...
The bad thing about BogoMIPs is that they are only a rough figure of performance and often get used as a more precise measure than they really are (usually not in a stable kernel though).
The bad thing about BogoMIPs and PowerNow is that BogoMIPs will become even *less* accurate than before. This is probably a very serious problem, as up until now, the kernel has been able to assume that a CPU will stay at the same speed it had at boot time and thus assume a fair degree of consistency in the actual BogoMIPs rate at any time. This assumption is no longer valid with PowerNow.
So...my guess is that this PowerNow thing WILL cause a severe problem--not just with Linux, but possibly with many other operating systems as well. This problem could be worked out, though; the kernel is capable of monitoring CPU clock frequency, so that clock speed at any given time, combined with clock speed at the time of BogoMIPs calculation, could be used to calculate a factor to apply to the original BogoMIPS calculation and thus get a fairly accurate current BogoMIPS calculation. This would probably impact performance a bit.
I'd guess that in future kernels, you would see the "Support PowerNOW!" config option within the CPU Features submenu of the kernel config script. For those who don't know about this (and are actually interested in knowing), check the Kernel-HOWTO at Linuxdoc.org .
Hoo...all that karma whoring. I feel dirty now...I think I'll take a shower.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
This still doesn't cover the issue of intermittent failures, though. Think on this: if memory were obviously good or bad, then bad memory would probably not even pass the initial memory check in a system. Yet bad memory often does pass even the most strenuous checks, even with ECC enabled (I had this problem myself). And if the "good/bad" status falls about such a hazy line, how effective can any piece of software be at singling out a defective chip?
This BadRAM patch will probably improve the situation, of course, but it can't pick out every bad chip thrown at it unless it checks every chip for eternity. Obviously, that's not going to happen...so...system reliability is still compromised, if only less so.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpgLinux From Scratch.
That's about as low-level as it gets unless you're actually coding all the software yourself. It's not actually a distribution, per se, but rather a manual that tells you where to get the basic software source tarballs, how to compile and install them, etc.
Slackware is good too. All stable release software, all compiled with reasonable options.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
Hmmm I have to side with the RedHat basher on this one. I have used RedHat 5.1, 5.2, 6.0, 6.1, and 6.2, and their quality started to take a nose dive at 6.0. The reason I have used them anyways is because where I work, that is all Engineering ever has approved for sale (without trying any other distros, I add, except Mandrake). Of course, even though I'm the only one there who knows Linux well, they don't listen to me =/.
5.1 and up have issues with LILO (sometimes it won't install during the initial install script), but nothing that couldn't be worked around. 6.0...the issues seemed to get a little better. 6.1...Samba didn't work in some cases, DHCP was flaky, etc. etc. 6.2, the problems are worse. 7.0, I believe the phrase is "look out below." RedHat posts fixes, of course, but I prefer a distro that's fairly stable right out of the box. FYI, I run Slackware and Linux From Scratch.
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg
Ummm...Slackware 7.0 and Linux From Scratch runs completely stable for me. Part of this may be that of all the software I have, only the nVidia Detonator driver, the 2.2.16 AGP patch, and the DPT SmartRAID V driver are classified as "beta."
As for fsck, I had to run fsck about 20 times the first time I installed LFS (debugging my own custom system boot scripts and /etc/inittab). Aside from finding a few inodes with bad dtime, the filesystem was repaired flawlessly, and the system remained rock-solid.
As for compiling problems, I had a minor problem compiling the kernel at first, until I moved genksyms to its proper location (something the LFS book left out). Everything else was solved by actually following the accompanying documentation.
As for RedHat, I would never use it as an example of the stability of Linux. RedHat is loaded with beta software. What's bad is that unless you're looking close, you won't notice the "beta-ness." (i.e. you see kernel version 2.2.14-5.0, think "2.2.14=STABLE," and put the appended "5.0" out of your mind. Trust me, 2.2.14-5.0 is at least part beta).
Kelledin Tane, the Dreaming Minstrel
http://kelledin.tripod.com/scovsms.jpg