Slashdot Mirror
D.H. Brown Associates Attacks Linux
Scott Stevenson
writes "A News.com article describes a study which
dings Linux for poor SMP support, access to only 1 or
2GB of memory, and lack of clustering. Of course, it
doesn't say anything about NT's uptime issues on a
per-machine basis." Also says that hard data
isn't available on Linux being reasonably crash proof.
What everyone is posting about here is just the summary. The full report, much larger, and probably including some hard data, is available if you want to buy it.
Regarding fbsd's smp, according to
http://www.freebsd.org/~fsmp/SMP/benches.html
At this point in development of the SMP kernel we do poorly in many benchmarks. We have been concentrating on other issues
such as stability and understanding of the low level hardware issues. As we start to work on areas that improve performance
benchmarks are useful for gaugeing our progress.
Though this may be out of date, there are notes in the 3.0 release readme that indicate that SMP is not yet done in freebsd. Comparing the two doesn't seem fair to either.
-Peter
== Just my opinion(s)
I'd like to mention the rumors that I've been hearing, though not to contradict the report.
Ext3fs is supposed to be ext2fs w/ the option to use a jounal, or to act as a traditional ext2fs.
Sounds cool to me.
-Peter
== Just my opinion(s)
The 2gb is correct on the intel platform. Putting linux on an alpha or an ultrasparc changes the picture. I've been told that the other 2^31 bits of ram are reserved for virtual memory.
Actually, is the mips r4k and r10k addressed as a 64 bit architecture? If so, then that also has through-the-roof amounts of addressable ram.
Anyway, the point is that since linux is not shackled to one architecture the review is dead wrong on this point.
-Peter
== Just my opinion(s)
Actually, Apache does technically use thread pooling, but more precicely it is "process pooling". The difference being that each process is given its own address space, execution state and OS resources, whereas a thread/task just gives seperate execution state to each thread: they all share the same address space.
p s.gz
On most OS', Linux included, creating many processes is understandably a lot more heavyweight (and inefficient) than creating lightweight threads. This isn't really that noticable under light/moderate loads, but when the server is under heavy load and threads are being spawned on a near per-request basis, you'll notice Apache's performance degrade significantly vs. Netscape Enterprise server, Zeus, or even Java web server (which uses user-level threading typically).
Here's a good paper by Doug Schmidt on web server threading models.. it's about 2 years old so Apache is probably a LOT better now, but it explains the issues & shows benchmarks clearly:
http://siesta.cs.wustl.edu/~schmidt/INFOCOM-97.
-Stu
I agree with your sentiment. While their treatment of NT in this study is erroneous in some ways, D.H. Brown has dissed NT significantly in the past, so I think that's why I'm not concentrating on that aspect of the study as much.
:)
Of course, in Linux vs. NT debates it certainly is disappointing to seem them cast as near-equals, which obviously isn't true. (though must debates don't always have to be about NT vs. Linux)
The thing is, why haven't there been any real studies about Mean Time Between Failures of Linux vs. NT? Sure, it's a difficult subject to tackle in a controlled fashion, but enquiring minds want to know
The evidence of NT's up/downtime is mostly anecdotal as well! [or it's just marketing spew]..
-Stu
cool, glad to hear it.
-Stu
a lot of systems that have extremely high uptimes (over 2 years) are internal business systems and probably wouldn't be on such a survey.
for instance, some mainframe systems have had uptimes of 5+ years.
-Stu
Read those comments again. 2 GB *is* the limitation of physical RAM.
-Stu
the AS/400's we had over at a medium-sized financial services company that I worked for in Canada had 1 gig of memory and 512 megs of memory.
They were upgraded a year later to 3 gigs of memory and 1 gig, respectively. Oh, and the second machine was JUST a developer server.
I know of a major bank that has 4+ gigs of ram for their Internet & Telephone banking computers.
Such is life in big business. $50 solutions for $5 problems.
-Stu
Most of the evidence I've seen is anecdotal, and I too would like some hard numbers about Linux+Apache+mod_perl vs. NT+IIS+ASP .
:)
My anecdotal experiences tell me that overall the Linux solution would be better, but I know that IIS does thread management a lot better than apache [thread pool vs. thread-per-process] & hence typically serves up pages quicker when under lighter loads. Under heavier loads, NT will crash
-Stu
As I think I've said before, I don't mind the unfavorable comparison to the high-end Unixes. As has been pointed out, Linux isn't trying to compete with the likes of Solaris or Tru64 Unix (except in the areas where these OSes are deployed where they are extremely overqualified). So, most of D. H. Brown's study doesn't really bother me.
What kills me is the little proviso: "...as well as Windows NT".
That's where the FUD really spreads. Linux's strengths compared to NT are dismissed as "anecdotal" or "unproven", while NT's strengths are taken at face value.
The reliability thing is especially critical. In my view, this is one of the major things that elevates Linux over NT: its stability under heavy load. This is something that I've observed time and time again as an NT and Linux admin.
And what really sucks is that everyone is willing to do a quick search for studies on Linux's reliability (turning up nothing), but no one is willing to do the studies. So, lazy people like these ding Linux with "unproven stability", while also dissing Linux on not having side-of-the-box features like "high-availability clustering", and assume that NT is more stable because it has these "side-of-the-box" features, even with its proven instability.
The problem is that most admins prefer a single, stable box over an HA cluster where it makes sense. Sure, HA clusters are great for business-critical databases, but why should an HA cluster be needed for everything to get even basic reliability?
And the worst part? No one seems to be willing to do the studies. So Linux loses in these asinine assessments every time.
You know, I shouldn't really be pissed about this. We've come a long way already without the benefit of positive hype, and I don't doubt that Linux will prove itself in some enterprise setting and show all the naysayers. And even if it doesn't - even if it's the best-kept secret in the IT world - it'll keep going strong.
But I do get irritated at people who publish irresponsible studies like this when my bosses at work tell me that they won't trust an "unreliable" solution like Linux and force me to deploy NT instead. If they forced me to deploy Solaris, AIX, or Tru64, I'd be a bit happier. But when NT is ranked alongside these systems, I get pissed, because it isn't even in the same league.
> Hmmm... I thought that at some point Intel made
> it possible to do 36 bit memory addressing on the
> i686 processors. This would allow access to 8 GB
> of memory. Of course I could totaly be off my
> rocker.
Yes, but that involves gross hacks, thanks to
yet-another-f*cked-up-design-from-youknowwho.
NT mm engineers screamed "yuck" loudly, but will
add support for that because they will be paid for
the job.
Linus (and "official kernel team") won't mangle
Linux mm to support this. 3rd parties may, but
anyone needing such amounts of memory should use
clean 64 bit architectures anyway.
There are several efforts to list maximum and average uptimes. There's even a section in the high-availablity mini-howto on this.
Fud. fud. fud.
Even assuming the article is 100% correct, by not giving an alternative which is superior, you're being hypocritial, and admitting that linux is the superior solution by omission.
--
Wouldn't it be nice to never fsck again? Or, atleast, to be virtually guaranteed that foregoing extreme funkyness, data will never be needlessly corrupted.
In a journaling filesystem, changes to files are not activated until they have been cleanly completed. Thus, if half the change is still in the cache when the power supply dies, no part of the change actually occured. Many journaling filesystems also keep preset numbers of revisions in the history of a file, making it very easy to back yourself out of a mistake.
There is a performance hit, 7 to 14 percent depending on what you're doing if i remember the specs on adding JFS to WarpServer 5. But journalling filesystems are a must for many data wearhousing applications where you simply can't afford the possibility of corruption.
All in all, this article doesn't look anti-linux. It's not particularly useful, and doesn't go out of it's way to encourage anybody to use linux, but honestly, look at what it's actually saying.
There's no hard data regarding the performance scaling of SMP linux systems. Well, there isn't. Whaddaya want? publishable results are more expensive than you think. If they had done their own research in-house you would have jumped all over them for it, no matter what they said. It would have been a serious issue of credibility for them.
There's no hard data on long-term reliability of linux. There isn't. See above.
Then there's the issue of "high availability" with linux. This was an "ask
All the tools and parts are there. Somebody just has to expend the resources to build the things this report is missing.
This is just like television, only you can see much further.
Check out one of the links on that page:. ni.rel
"Unix trounces NT" http://news.com/News/Item/0,4,29416,00.html?st.ne
Judging from the two articles, it seems DH Brown is a big fan of old school unix. So yeah, if your company can afford AIX/Solaris/etc, they seem to be suggesting you should pay for the reliability and scalability. I don't mind linux not matching up to the big boys yet...in fact, I'd rather see that at this point, this way Sun can ship Linux and help improve it while maintaining a high-end product that still rakes in the bucks. That way linux is seen as a great entry-level product going up against NT, and the cadillac is there when you start making money.
I'd rather see linux grow as a desktop OS, and hopefully the big companies will start to filter up some of the linux gifts that make it a better desktop OS (ie improvements in gnome/KDE, word processors and PIMs etc.) and maybe toss some money that way.
A few months ago, Linux was "relegated" to being useful only as a non-critical webserver - now it's usable for: "file and print servers, Web servers, low-cost number crunchers for scientific computing, and inexpensive, limited-function "thin" client computers."
And so far as the other criticisms... Enterprise computing is still uncharted territory for Linux. It's going to take time before people start accepting it as being as stable as the other Unixes... But at least it's now being considered in the same league.
SMP - I forgot where I read it - maybe on the FreeBSD site - but FreeBSD outperforms linux SMP by 17% - so obviously there's room for improvement, no?
The other limitations may only be a hardware issue (memory support, etc...) but they're still an issue. Just because Linux is hampered by the hardware it runs on, it doesn't mean that it's not an issue affecting the adoption of Linux in the enterprise workspace.
Overall, the article, in my eyes, more pointed the way towards where Linux needs to go in the future. Too bad it's on CNET where if it's not good, it's gotta be bad...
-----------------
OS X server has been out what, 3 weeks? Before that, Apple didn't have a server platform. Apple also has an extremely busy site. Switching OS's on a site that get's that many hits is no trivial matter.
That's wonderful. I still don't see this being a real common thing.
I thought this was comparing Linux and NT on intel hardware for common applications. The memory argument starts to head into the area of Intel, Sun, SGI/Cray which I think was beyond the intent.
. Quit playing Monopoly with Bill. Switch to one of many non-Microsoft products today.
Good point. There are likely a lot of /.ers that haven't bothered to go to the source (or got hit with the /. effect and couldn't). As a matter of public record, we are all arguing the executive summary. If you go to the site, you have to fill out an ID form to get the summary. You are then invited to purchase the full report, for $995.00 (not $9.95). Nobody I know has coughed up the k-buck, so we're all looking at the executive summary. Normally, I'd be peeved at people judging the book by its cover. However, the above shows the extenuating circumstances. I'd love to see the real report, but I wouldn't love it that much. Does anybody have access to the full report, or money to burn for same? I'd assume that a repost would be mondo illegal, but some intelligent points from it would be appreciated. Until then, we'll have to argue the stuff that we can read.
--The basis of all love is respect
Windows NT Server Enterprise Edition can support user address spaces up to 3GB for specially made executables. Vanilla Windows NT allows user address spaces of 2GB. I'm not positive, but I believe NT can use a full 4GB of physical RAM. I've also heard that there is a really obscure version of NT that employs some sort of hoarfy paging scheme to use the x86's 36 bit addressing mode for physical RAM (in my opinion this feature is quite useless). Note that I hate NT.
x86 Linux has a 960MB user address space limit in a default kernel. It is possible to recompile a kernel to allow 2GB of address space per process. Linux has a tradeoff between physical memory installed and user process address space, their sum cannot exceed 4GB. Hence allowing 3GB of address space for user processes limits you to 1GB of physical RAM making this kernel configuration mostly useless.
My understanding is that Linux on 64 bit Alpha encounters difficulties around 2GB of physical memory due to PCI limitations. This doesn't sound that fundamental an issue, but it isn't a simple kernel recompile to fix it. Hopefully this will be ironed out soon.
Brian Young
bayoung@acm.org
Linux has a 4GB address space. One gigabyte is dedicated to the kernel.
WinNT cannot give 4GB to an application; that is
another lie. You need a special configuration of NT server just to have as much memory as what Linux makes available.
Secondly, Linux is a 64 bit operating system on 64 bit machines. It's a pure lie to say that some commercial UNIX can have 128 gigabytes of memory and compare that to Linux on Intel. I mean, for crying out loud, doh!
Missing from Linux are high-availability features that would let one Linux server step in and take over if another failed;
I'm not an expert on the subject but I've seen the high-availability howto at www.linux.org/help, so I know it's possible. Can somebody else comment on the subject?
full-fledged support for computers with multiple processors;
uhhm, did they even test this??? Last I checked Linux beats the crap out of NT on SMP...
and a "journaling" file system that is necessary to quickly reboot a crashed machine without having to laboriously reconstruct the computer's system files.
OK, that's true. Linux doesn't have jornaled file system. On the plus side, it doesn't crash very often... NT does have a journaled file system, but for some reason it took longer for NT to test the file system after the crash then for Linux to run fsck after the maximal mount count.
Currently Linux can't use more than 2 gigabytes of memory, and in some cases only 1 GB. Windows NT, on the other hand, can address 4 GB of memory
This is either a deliberate lie or a lack of knowledge (or both). First notice that he doesn't specify the hardware. It is assumed that there is only x86 in the world. Also notice the difference between "use" and "address". Linux *can* address 4 gig of RAM on x86, just like NT. The memory is split between kernel and user memory. By default the split is 2-2, but you can change it to 1-3 (1 for kernel 3 for user) by recompiling the kernel. NT works in *exact same way* with only one difference: you can't recompile the kernel. In order to get a 1-3 split you need to buy "enterprise edition".
Now, Linux also runs on 64 bit platforms, such as Alpha, SPARC and PPC, and it can take full advantage of 64 bit memory architecture. On these platforms Linux can address 2^64 bytes of memory -- I don't even know how much that is...
NT also runs on Alpha. But (surprise, surprise!) it's memory model is 32 bit. That means that even on a 64 bit platform NT cannot address more then 4 gig of RAM!
This whole article is pure BS. Notice that they pretty much just say "Linux sucks" without thorough comparison of any kind. Does anybody know where to send email for rebuttal?
___
If you think big enough, you'll never have to do it.
Data point - I'm aware of a couple NT boxes, and one Solaris x86 with 2GB. So its more like 99.5%.
While that may be top end now, look forward a few years, and it will be much more common to see this amount of memory on x86.
I'm not really aware of the issues involved in this, but I'm sure if turns out be a problem with Linux, they can slipstream a fix in to 2.3.666 or whatever. Commercial operating systems would probably do it at a major version upgrade, which NT won't see for a while after 2000 finally ships.
--
Business. Numbers. Money. People. Computer World.
It's true that Win2000 junks the Domain security model, but that has nothing to do with high availablity or journaling.
(A WinNT Domain is a common list of user/groups shared by a number of computers for login and ACL purposes.)
--
Business. Numbers. Money. People. Computer World.
It seems news.com provided an review of a review...
It's pretty bad that their report, news.com's, is uneven, though it highlights both strength and weakness. It doesn't explain their own reporting, much less Brown's.
Someone mentioned the pdf; is it available?
You have to pay for the real report... and there's a form I just filled out for an executive summary...
I can accept their claim that for 'enterprise computing' that other unices beat it, but not that 'Windows NT holds an advantage'. Price/performance, stability, and interoperability, from hearsay all over the web, seems to be Linux's strength against NT deployments.
Linux definitely seems to lack in robust SMP, or as they say, 'non-trivial SMP scalability', except I'm not so sure that NT qualifies. Isn't NT limited to 2 or 4 processor Intel solutions, which are themselves not quite so hot for enterprise level computing? As compared to bigger Sun or Alpha solutions? Maybe someone can correct me and tell me about a distribution of NT that runs on 32 processor Intel or Alpha machines at a reasonable cost and at reasonable performace and up time?
As for journaling, high availability clustering and such, I guess that much is true or under development... But I still don't believe that they think NT satisfies their requirements for an enterprise level computing solution!
Anyone care to correct me?
AS
-AS
*Pikachu*
The fact of the matter is that Linux's SMP support isn't on par with Solaris' (4 CPU's vs. 64), Linux's high-availability clusters aren't on par with *any* commercial UNIX (yet), and Linux's filesystems aren't journaled. (yet)
Some day (Kernel 2.4/3.0) all these features will probably be there, but let's not start touting vapourware over other solutions. Open source can only combat FUD if the code IS THERE. Right now, it isn't.
"Use the right tool for the right job" - Linux [on Intel especially] isn't it for sites that need extreme scalability & high availability. (A Sun Ultra 10k, AS/400 parallel cluster or S/390 mainframe is better suited to those environments.)
Ditto for sites that need to run a transaction processing monitor (like BEA Tuxedo) or a high end application server (like Apple's WebObjects). Though, this is changing... I think BEA is thinking of a Linux port... and WebObjects on Mac OS X Server is pretty sweet.
[ though not 100% open source, but nothing open source comes even close to Tuxedo or WebObjects in terms of performance, elegence, reusability & developer tools. Perhaps the GNUstep project will adopt the WebObjects framework as another pet project.. ]
-Stu
Executive summary pdf link:d f
http://www.dhbrown.com/dhbrown/downldbl/linux.p
This contains FUD at higher level than that found in ZDNet.
Pay attention to how SMP and Linux is "covered" on pages 7-9
begin quote:
By boosting the number of locks to somewhere between 10 and 100, the Linux 2.2.5 kernel used by OpenLinux 2.2 should improve its SMP scalability somewhat. But while Linux 2.2 systems can boot on an SMP system with up to eight processors, useful SMP deployment at current levels of granularity has not yet been proven. Little industry-standard or even proprietary benchmark evidence has emerged that demonstrates the performance improvements of
database or Web server applications running on SMP systems under any Linux distribution. Although Linux has been tested on a variety of SMP systems, booting on eight-processor systems is far
different from demonstrating improved performance on mixed throughput workloads or multi-threaded database applications.
:end quote
Rather than doing RESEARCH and STUDY, they merely report the # of CPUs used in previously published NT and Commercial Unix benchmarks. (They do not print the actual benchmark results here). The number of CPUs used is a virtually useless comparative benchmark. Since they selected two benchmarks where there are no previously published Linux results, they report nothing for Linux. This is used to portray Linux as hopelessly inferior, without actually having to do any work. Check out how they put Linux at 0 CPUs on the graphs. I thought only Microsoft would do something so obviously corrupt and shameless.
Method: Claim Linux is inferior. Do no benchmarking yourself, but make the lack of data for Linux sound ominously bad. Put in some fancy graphs of useless values selected only for their ability to make Linux look worthless at first glance.
It is amazing people will pay DHBrown for a report of this quality.
Here's the article.