Slashdot Mirror
Putting Linux Reliability to the Test
Frank writes "This paper documents the test results and analysis of the Linux kernel and other core OS components, including everything from libraries and device drivers to file systems and networking, all under some fairly adverse conditions, and over lengthy durations. The IBM Linux Technology Center has just finished this comprehensive testing over a period of more than three months and shares the results of their LTP (Linux Test Project) testing."
Just put a link to each box on /. and wait 24 hours.
Anyone know if the test will be repeated with kernel 2.6.x?
You want to put any OS to the ultimate test, you should run cheap generic hardware. I swear it's an industry conspiracy that generic parts struggle a boat load. If your parts don't come from the big boys (DELL, gateway, etc), you are likely going to see issues down the line.
Get some ECS motherboard, generic RAM... bang. You're in for the evening.
> You're thinking Microsoft Works.
I'm thinking it doesn't.
Why do you trust IBM's Linux Technology Center to evaluate Linux?
I seem to recall getting random crashes with cheapo memory, and it was a pain to track down the offending component. Of course, one would assume that IBM wouldn't go for cheapo components, but still: how does one point the finger at the software, instead of hardware? Is it just repeatability?
This is nice to hear, but it would be even more valuable if the same tests were performed on a variety of operating systems in order to compare the results.
Brian
My Company
Second off, If this were M$ testing 2k3 and publishing the paper, everyone here would be crying foul. But because its, "Linux" it must be 100% unbais and true.
I've been using Linux for 8 years now including under high stress enviroments, 3d graphics rendering mainly, and from experiance I have see very good things from Linux. We have had software glitches before, but the core software maybe has caused 3 - 5% of our downtime. Over 70% of our downtime involves human error and about 25% of failures are due to hardware giving out.
Still what my customers are wanting to see isn't benchmarks as "So easy Grandma could use it" in Linux. While the people in the datacenters want to know how well Linux will bear under a load, most end-users and SMB's don't need to worry about it, they just need something easy to use that works.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
The people performing it have a vested financial interest in having it turn out a specific way, notably positive. If the test resulted showed poor reliability, then I would understand trusting it because it would go against the motives of the people performing it. Since the test affirms their business model, no matter how documented it is, it should be suspect.
It doesn't appear to be a test rigged to make one platform look better than the other.
It looks a bit skewed to me. Many of the test results depend on the computer systems meeting expectations of the people testing it, particularly in overload cases. Since the people who tested work in the Linux Technology Center, their expectations stand a greater likelyhood of being consistant with the system.
Take C/C++ and Java. Someone who regularly works with C/C++ knows certain libraries (notably the character ones) return ints for status in the form 0 being false and not 0 being true. If someone expects that, the system meets expectations and passes. If someone comes from a different background, say Java, he or she may not expect that, and the system would consequently fail the test of meeting expectations. I would like an evaluation from somewhere in-between, not someone whose years of experience allow them to gloss over what might be problems for another person.
- because the test methodologies are documented
- because it's disclosed up-front that it's IBM Linux Team testing Linux (ie no hidden conflict of interest
As opposed to the usual (ie in the Microsoft World)Visit CryptoGnome in his home.
So, ya reply to one point but ignore the rest? I think his (ultimate) point is valid. If the test was rigged, the folks involved with developing the kernel would catch on and take IBM to task for fudging the results. No, I'm not talking about the Slashdot/Fark crowd. I'm talking about REAL developers.
Also, Linux has weathered some unfavorable (and honost!) critiques before. Linus Torvalds said it best when he said (and I paraphrase since I am too lazy ATM to look up the actual quote) that it doesn't matter if there's negative publicity in the press about Linux. It just meant he got his bug reports from the Wall Street Journal as opposed to the regular kernel mailng list.
--- Journals are boring; Go to my web page instead
95% success ratio... does that mean that 1 in 20 programs I run segfaults or what? What do they mean by "failure"? Not finishing given task in predefined time? Getting the results wrong? Hanging?
Sorry but that means nothing. Even if there -was- a comparison to other systems, it would still mean nothing. 95% success ratio, 78% happiness factor and 93% user satisfaction.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
I think IBM used SuSE instead of Redhat because IBM Global Services and SuSE have been partners for almost two years.
Maybe you should stop hmmmmm'ing about these great mysteries and start googling.
Beware blue cats moving at
FTA
The tests demonstrate that the Linux system is reliable and stable over long durations and can provide a robust, enterprise-level environment.
Ok, now i dont mean to troll here, so mod down if you wish, i really dont care.... BUT...
I am a linux user/programmer/lover for the past few years now, and i wanna see a company that is not SO IN LOVE with linux say what have just been said by IBM above.
In other words, i dont want to see companies who sell Linux, or who have benefit in selling Linux praise it. Does any one of you know of someone who fills in these criteria. Sun for one is not very fond of Linux, nor is MS ofcorse (despite the fact sometimes i doubt they have code in their stuff from Linux...)...to make a long story short
It would be really nice if such a judgment came from someone else besides IBM/REDHAT/ORACLE...
The lunatic is in my head
software fails the same way in controlled instances
...) happen. There's also the not-initialize type of problem where the behaviour depends on whatever was there in memory before. There are probably many other ways for software to fail at random, including obscure combinations of events.
That's true... in theory. In practice, there are many ways software can fail in random (in the weak sense) ways. Many of these are related to timing. For example if you have many threads and fail to lock things properly, the result will depend on when the tasks are preempted. You can also have different results because of the way the interrupts (disk, net,
I'd say that the only kind of software that can't fail randomly is single-threaded and doesn't rely on any input other than regular files (and even then I'm not sure it's enough).
Opus: the Swiss army knife of audio codec
"The Linux kernel properly scaled to use hardware resources (CPU, memory, disk) on SMP systems."
Sorry, but how can the scaleability of the CPU resource be proven on a 2 CPU system? Show incremental results on 1, 2, 4, 8, 16, 32 etc. etc. and then CPU scaleability may be proven.
This is NOT an anti-Linux troll, rather the evaluation needs to justify it's outcomes or it starts to look like something from a company starting with M.
The very reason Linux has already made so many inroads into coporations in the first place is because of its reliability and stability, and not because some marketing campaign has churned out the words on header paper.
Another point is that I personally expect the sytems I administer to run for a darn side longer than 30, 60 or 90 days unless I need to restart them because of a kernel upgrade. When my last bunch I worked for went tits-up, our SAMBA file server had a 790 day uptime, and had run the SAMBA daemons reliably throughout, as well as doing internal DNS and DHCP. That's what your average Linux sysadmin expects from a Linux server box.
A Linux desktop being used for all manner of things though is completely another story: if I muck around with the Linux install on my laptop, as I do because that's what I do, then I expect to break it from time to time, and so "reliability" is not measured in the same way on a desktop/laptop system, IMHO.
The ideal environment for Linux is as a networked server, where it can get on with doing what it was setup to do, and will continue doing so until someone pulls the power plug on it. In that context, there are few OS's playing on the same field that can rival it for reliability and stability.
I've been using an old P120 laptop as a firewall/router for my house for the past several years running 2.2.something. I wondered why it rebooted after noticing an uptime of only a day or two, but found that instead I was experiencing the uptime rollover bug (at about 500 days; Windows used to crash on a similar bug after 48 days). About a month ago, it stopped giving out DHCP addresses. I went downstairs to investigate, as I couldn't log in remotely, and found that the hard drive was making that nasty clicking sound. I eventually managed to ssh in (sshd and sh were in ram; I just waited for the logging to time out). I was able to kill syslog and cron, and now dhcp is again giving out addresses.
It's been running just fine for a month now with a dead hard drive.
(Yes, I'm getting a replacement because it won't survive an extended power outage on that ancient battery.)