Slashdot Mirror
First official SAP R/3 benchmarks on Linux
droesen writes "The Siemens SAP Competence Center did the first officially SAP-certified SAP R/3 benchmarks on Linux, using a Quad-XeonIII-Box. According to their press release (having some technical details) the result was the highest ever measured performance of SAP R/3 on quad-Intels. Interesting, because according to some voices, Linux doesn't scale well on SMP machines. "
Quoted from an article called "What is SAP?" posted at TechSightings.com
Most SAP developments take place in a multi-server environment. There is a box for code/configure, one for quality test, and one for production. Individual bits are moved between the boxes via "transports". No programming or configuration is done in the quality assurance or production boxes-- rather all code is introduced via the transport mechanism.
Why buy an expensive Sun to be a development box, when you can outperform it with a quad linux machine at a better price?
There are also a lot of companies who thought it wise to install SAP on NT w/ SQL server. General complaints are stability and speed. If these people can upgrade from NT -without purchasing additional hardware- then that could become an attractive option.
SAP on linux would provide proof of linux's stability and speed in a very picky market. What's better is that people may purchase some heavy hitting hardware to run SAP. (Our production box is 2 gig ram / 5 processor Sun supplemented by 3 "application" servers w/ 3 gig ram and 4 processors each. They make good quake servers too!)
It was an accident I swear.
please don't beat me, I'll be good
"Karma can only be portioned out by the cosmos." -- Homer Simpson
A couple of comments. First, I definitely agree with your analysis that SAP projects are 'cathedral style', at least in the sense that there's a limited number of implementations for the whole organization, and it's centrally planned. I guess it'd be nice to have an ERP be evolved in a decentralized manner into existance... but I'm not sure if it possible.
The big benefits of putting in an ERP are usually two fold. One, the current systems are obviously broke in some way (Y2K, expensive licensing fees to IBM for the mainframe - remember them? - etc). Two, the basic business processes are in trouble - such as, everyone in the organization has a total different view of the organization data, or the info from the manufacturing system isn't visible from the HR system, etc. I don't know if you can fix the data decentralization problems with a decentralized approach.
Theo
If things didn't break, you wouldn't learn anything.
The original post in this thread was not offtopic
Anyhoo, I didn't really know for sure what sap was until this point. It seems to me that this is an obvious selling point for siemens from now on...
Lowmag.net
I know that if I were responsible for a SAP rollout, I'd certainly prefer having it on an OS I trusted.
Also remember that Siemens has been a strong Linux supporter for some time, and that Siemens have a VERY strong name in exactly the markets where SAP compete, and especially in Germany. If anyone are able to sell SAP on Linux, it would be Siemens.
(BTW why was this only awarded only a score of 1?)
This is exactly the reason why any company will be reluctant to put any seriously large application on Linux, however scalable it may become - the couple of $K (or maybe 10$K) you save on the OS is minute relative to the cost of the project, software and hardware. They'd always prefer to put a commercial Unix on their boxes.
And if you need a powerful computer for something, why limit yourself like a toy like IA32 when you can get an Alpha Based system and 64 bits today?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
the interesting part of this is how sap is making an end-run around NT...there's a real battle going on in enterprise sw and microsoft is moving up the food chain. right now oracle is target #1 but pretty soon sap is going to get the crosshairs. essentially microsoft is picking apart baan's stuff so they can learn how the enterprise game is played. sap is using linux as a defensive/offensive maneuver. this is the kind of thing thats' going to make linux REALLY legit.
-- your knees hurt, don't they?
You write:
..."
"(in fact i think bookkeeping/accounting etc. is something rather boring..) "
and then:
"one ore 2 dedicated programmers who built a custom solution for the company there
Do you have the faintest idea how much time and money a company can waste with one or two programmers writing a custom solution enterprise-wide, who think that accounting/bookkeeping is boring?
Most of the companies who've implemented SAP found this out first, and then implemented SAP.
People always tend to make this mistake when talking about SAP R/3. It is true that multi-million dollar or Deutsche Mark installations have failed horribly. But that was not because of R/3 bein a bad piece of software. In most of those cases it was because of the changes to the organisational structures necessary to adapt to SAP's approach haven't been done. A company has to review it's whole lot of business processes and every single department is required to adapt to those changes. Companies that fail in this area see SAP only as 'another' IT project. Finance, HR and all the other important areas feel offended by the invasion of 'those computer geeks' into their traditional territories. ANd those are the projects that fail horribly.
Second thought: The reason that SAP programs often fail so badly is that they are the classic "Cathedral" projects. The whole thing has to be done by a bunch of (yes, hugely paid) outside consultants, who have to basically inhale the structure of an entire multinational company, and then configure an application to mirror that structure. And you thought your website was a burden.
You have to use the Cathedral approach when managing a organisation. At least that's true for most current companies. Try to imagine a company without a CEO where every employee makes its own decisions based on their picture of the situation. Btw: Except from the core of the R/3 system (which is written in C/C++) all the applications are available in their source code, although they're written in ABAP/4, R/3's interpreted 4GL.
-- Truth suffers from too much analysis.
[flamebait on]Inform yourself before you put your voice out in the wide web.[flamebait off]
SAP provides very clear instructions on how their benchmarks have to implemented. You can bet that every single vendor tweaks the system as good as they can.
The benchmark therefore provides a very good picture of how Linux performs compared to other platforms/OSs in a real-world application relevant for businesses. This is much more telling than any artificial benchmark for pure performance measuring like the one Mindcraft did.
-- Truth suffers from too much analysis.
I talked to some guys at the Siemens SAP Center and asked them.
Distribution: RedHat 6.0
Kernel: 2.2.11-SAP2 (which is the default Kernel provided by SAP with their R/3 release for Linux). There were no kernel tweaks done by Siemens. [nobody knows what SAP has done with 2.2.11].
Hardware was unmodified Siemens PRIMERGY 870/40, just with 550MHz CPUs. Tomorrow, I will try to get info about this "2.2.11-SAP2" kernel...
Anyone interested in further information about this benchmark may ask Siemens directly by emailing mailto:sizing.r3cc@wdf.siemens.de
I thought Linux had build flags to that effect
:-)
There is a CONFIG_SMP flag which controls SMP operation. If defined, the kernel includes multiprocessor support code, and kernel locks are "spinlocks" which work properly accross multiple CPUs. If not defined, the locks are simple set/clear interrupt calls (since if interrupts are disabled, a single CPU machine is not going to be preempted).
I was advocating going beyond this to defining multiple levels of locking granularity, i.e., allowing you to control how finely threaded the kernel is. That is not currently done, AFAIK.
Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo.
I am fairly confident this is not the case with Linux; if you boot an SMP system with a uniprocessor kernel, the second CPU just sits idle, doing nothing more harmful then wasting power and generating excess heat.
Of course, I have been wrong before. I think.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Those things that make you go hmmmmm...
I think it is, indeed, inappropriate to refer to the "Cathedral and the Bazaar" in conjunction with SAP. The guys who write the linux kernel know very well how to write it, and are wildly enthusiastic about it.
Most people using ERP often don't have a clue how a company works, is supposed to work, how to write software for that, and, most importantly, they are definitely not wildly enthusiastic about writing that kind of software.
Having lived through an Anderson takeover I'm wary of anything they are that closely tied too. They're corporate parasites. They come in, fire most of the staff and replace them with their own consultants. I've seen it happen a couple of times. It's not pretty.
The obscure we see eventually. The completely obvious, it seems, takes longer. - Edward R. Murrow
In most of those cases it was because of the changes to the organisational structures necessary to adapt to SAP's approach haven't been done.
I think you've hit the nail on the here. It's not that the SAP-way is the only way - it's that you have adapt many of your business practices in order to get the returns that are promised. That's why business consultants are usually a more critical piece of ERP implementations than the programmers.
Note that the same principle is true for groupware and intranet projects many order of magnititude smaller than SAP or Baan. I've seen quite a few 'departmental' level project fail because the management structure wasn't ready/willing to do business in that manner. (And then there's the cases where SAP or Baan is being used to solve 'departmental' problems which would better be served by a smaller scale solution. Nightmares.)
Business. Numbers. Money. People. Computer World.
No you're right -- The cost of NT licences isn't even a significant digit when you are considering a SAP implementation. Besides. NT seats are only for SMB connections - application software runs on NT essentally for free.
Of course hardware scalablity matters too, and Linux is largely in the same boat as NT on that issue (x86), which is probably why neither will be that popular for this kind of thing. The smallest SAP implementation I've ever heard of (~100 users) was still on an AS/400 (check the CALs costs for that.) I had no clue that people even considered NT or Linux for SAP until this thread showed up.
Business. Numbers. Money. People. Computer World.
Baan is a company that makes/sells an Enterprise Resource Planning (ERP) package named BaanERP, which is like SAP R/3. Go to their site for more information.
- Consider the straight facts:
- Siemens does sell the hardware.
- Siemens does not produce the R/3 application. R/3 is a product of SAP AG.
- Siemens does not produce Linux, the OS on which it is running. Nor did they produce the "tuned kernel;" that was done by SAP AG.
- Siemens does not produce SAP DB, the relational database previously known as Adabas-D, produced originally by Software AG.
- Add to this the factor that all the other hardware vendors that try to sell systems on which to run R/3 run this same SD benchmark.
- The implication that the throughput is excessive is fairly much irrelevant.
The long and short of this is that while the statistics may not be reasonably used to determine precisely how many "transactions per second" you may expect to be able to process, the results are about as useful as benchmarks get.In other words, they don't sell the software that they are benchmarking.
The use of the SD test is fairly normal, as is the use of really fast networks on which application servers and database servers run.
The R/3 systems that I help administer are connected together using Fibre Channel; there is a major premium on speed of connections between DB server and application servers, because they do a LOT of communications.
In contrast, it usually acceptable to run presentation servers ( e.g. what you'd probably think of as ``clients'') on much slower connections. Users find 56K connections fairly usable, albeit not as good as faster connections...
It's not merely ``benchmarketing.''
If you're not part of the solution, you're part of the precipitate.
There are a few entertaining factors to throw in, for good and for ill on many sides:
- Note that the release of R/3 on Linux uses "SAP DB" as the database.
- As you mention, Microsoft is now ``picking apart" BAAN's software, probably with particular attention to deploying it atop MTS (Microsoft Transaction Server) / MSQM (Microsoft Message Queue) / SQL Server.
- The third issue that has been largely ignored thus far is that all of these folks are pushing hard to build web-based front ends. The company I work at has half a dozen projects on the go to put web-based "front ends" onto R/3 systems for one purpose or another.
Interesting times, to be sure...This used to be Adabas-D, the first "big name" RDBMS available on Linux. It was fascinating to see that SAP AG bought Adabas-D from Software AG earlier in the summer.
The net effect of this is several-fold:
- SAP isn't "feeding" any sales to anyone else out of the deal, as would be the case for an NT-based system, or for an Oracle-based system.
- SAP gets to keep all the money that comes in.
- SAP gets to have more control over the R/3 kernel and its interaction with both RDBMS and OS, which I'd speculate has a lot to do with the decent performance that was achieved.
Net result is that this moves SAP "up the food chain" relative to both Oracle and Microsoft. Good news for SAP; probably irrelevant from the perspective of Linux "community."R/3 does a huge amount of its own cacheing and such, and doesn't make much use of the more advanced features of the RDBMS; the fact that SAP controls the sources to SAP DB means that they can tune it to their requirements, removing any "cruft" that may be K001 but not actually useful for their use of a DBMS engine.
This architecture differs from that of SAP's R/3 in that it makes transactions greatly more visible, and encourages the forward-thinking approach of making extensive use of asynchronous processing.
Contrast with PeopleSoft who, for large installations, make use of BEA Tuxedo, another "message queueing" system in order to improve scalability.
R/3 contains TP management software, but it is much more like CICS, with implicit management of transactions rather than visible management, which tends to result in lesser scalability.
Danger lies here for SAP; Microsoft has indeed copied their technologies from some smart folks, having a source license to Sybase as well as a MQ product that looks like it was directly "ripped off" from IBM's MQSeries architecture.
To that end, SAP's "BAPI" system, which essentially provides a Java front end to many R/3 "transactions," making them more readily mapped to transactions as others would think of them, is an "offensive" action to try to get lots of Internet apps out there.
And Microsoft is waging war with BizTalk, a scheme where transactions are represented in XML form and may be transferred around as such. This looks to be a natural way of encouraging widespread use of MSMQ...
If you're not part of the solution, you're part of the precipitate.
Linux SMP is said not to scale well largely because its all based on a single bus at the moment. It'll scale fine up to 2 or 4 processors or so but not very much farther. A number of reasonably fast processors sharing a common bus isn't a good thing when it comes to feeding those processors data. It also depends on the type of application, for something that stresses the memory interface Linux may scale less well. This isn't slamming Linux or those results, I'm just pointing out that using this as ammunition that everybodies wrong and Linux currently scales well is plain wrong. When Linux gets ported to big iron and the underlying hardware architectures involved you'll start having data that supports Linux scaling well.
Remember that compared to what a present day SGI or IBM machine can do 4 processors represents the very lowest SMP ability. That Linux has picked up the best performance in this class is great, that represents a substantial amount of potential money.
I'm wondering if this "SAP DB" is Adabas-D ?
The version number indicates that and there are SAP installations on Adabas.
Adabas-D was the first full-blown commercial (SQL-) database available for linux.
Maybe. I still think it's pushing it, though. one of the chief barriers to entry for companies interested in SAP is the sheer cost involved (not to mention all the re-tooling of business processes), but changing the underlying OS of the system to Linux just wouldn't represent enough of a cost savings to make it a real factor.
In the enterprise computing market (especially for tasks like SAP deployment), Linux will have to win almost solely on technical merit.
The Linux kernel, like any multiprocessor OS, uses "locks" to protect critical sections of code which are not "thread safe". That is, for operations which will get messed up if another CPU starts monkeying with the same data structures, they put guards around any code that reads/writes those data structures.
:-)
In order to scale an OS kernel to a large number of processors, you need a larger number of locks accross smaller sections of code, so that there is less chance of contention over particular data structures. Solaris does this, which is one of the reasons it scales to 64 processors so well, but seems sluggish on a uniprocessor system. All those locks cary a significant amount of overhead.
Now, I imagine that we could define multiple "levels" of locks in the kernel. The higher the level, the more "fine grained" that lock is. If the locking functions are preprocessor macros, we could setup configuration flags that determine how fine-grained the kernel locks are.
For a single processor system, those macros simply disable/renable interrupts at lower levels, and are defined to by empty at higher levels. For a two or four CPU system, lower levels are spinlocks, but higher levels are empty, avoiding the overhead of a finely-threaded kernel. For a massively SMP machine (16+ processors), higher levels are empty and lower levels are spinlocks.
This would give you a finely-threaded kernel where the scalability wipes out the overhead of the locks on big machines, but does not impact performance on small machines.
No, I have no idea if this will work.
Comments, anyone?
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Not that I disagree with anything being said, but theres a frightening trend here. When an article comes out claiming NT is faster than Linux at anything, immediately everyone on /. attacks it as much as possible, whatever the merits of the study are. Had that study not been "funded" by MS, or had been properly tweaked and NT still at least equalled Linux performance, then there still would have been /. outcry.
On the other hand, no one looks for holes in an article that comes out stating that Linux is blazingly fast. All Linux users [maybe not all, but it is the prominent position] simply sit back and smile, claiming "real proof" is here at last. I haven't seen a single thread discussing what might have been wrong with the benchmarking in any way.....
LART LART LART LART
*screams*
LART LART LART LART
*silence*
That's better!
Any word on when LinuxPPC will run the SAP benchmark on one of these?
The thought of a flock of 4,096 MPC7400 (aka G4) processors running the penguin, with 16 terabytes of shared memory...
--The more you know, the less you know.
Actually, SAP allows you to split your server functions anyway. You can have DB on one machine
and the various functional modules on different
machines. Often the SD module (sales & dist)
is on its own box due to the resources required.
...how many x86, off-the-shelf, 8-way SMP machines are there other than Sequent NUMA machines?
Intel has made 2-way and 4-way SMP accessible. So it is only natural that Linux has been made to work with these systems, flawed as they are by being based on PC architecture.
As far as MS and NT on a 32-cpu SMP machine, they worked with Sequent on that...
How many people can afford a Sun 64-CPU server?
How many Linux kernel hackers work at a place where such a machine is their development toy?
Linux scales GREAT for 2-4 processor SMP systems, but once you start getting into the 8/16/32+ arena Linux starts to faulter, mainly because I don't know of very many Linux developers (SGI?) that have access to machines of those sorts to do development on. Microsoft can throw $10 million (not that it does cost $10 million) to research/develop/code NT for a 32 CPU whatever and not even realise it did that.
They used the 2.2.11 kernel that is known have the worst TCP memory leaks.
The mindcraft benchmarks took advantage of the fact that the kernel's networking code was pretty much single-threaded, while NT's networking code was not. Indeed, the NT kernel was even able to bind each CPU to its own Ethernet port!
This result is good because it shows how lightweight the Linux kernel is. Once we add the same multithreading to the kernel that NT possesses, Linux should be able to blow the pants of NT in a rematch.
99 little bugs in the code, 99 bugs in the code,
fix one bug, compile it again...
I'm a leaf on the wind. Watch how I soar.
In a talk he gave a week ago, Bob Young mentioned in passing that SAP apparently has 5 full-time people working on Linux. Fixing bugs, adding features, finding performance tweaks to help SAP run faster on Linux.
It is nice to see that this is paying off. Perhaps some other application vendors will get the point?
:-)
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Don't forget that the Athlon uses the same bus technology of the Alpha that you are praising here. Just cause intel SMP sucks doesn't mean that Athlon SMP won't be a lot better.
In any case, the scalability of Intel-based SMP systems is currently limited by the memory bus, which is so narrow (800MB/s peak) that a single CPU can saturate it.
Doesn't the AMD K7 use the Alpha switched bus architechture for SMP? I'd like to see what Linux on a four way K7-1000 will do in a years time!
--- It is not the things we do which we regret the most, but the things which we don't do.
Bringing SAP to Linux is a major breakthrough for Linux in business though.
Not many of SAP's traditional user base would choose Linux today. bHowever, I understand that SAP is anxious to get into mid-size to small businesses as that's where they see their big growth potential is.
This is a potentially very big news. SAP had been growing increasingly close to Microsoft. I'm certain that Microsoft would not have wanted these benchmarks published, if at all possible.
I see two possibilities:
SAP doesn't care that they are kicking Microsoft in the shins. SAP also doesn't care that other big Unix vendors won't be happy to see this. This would mean that SAP is betting a lot on Linux.
The groups in SAP who do Linux and benchmarking don't check with their central Strategy and Marketing people, they just push forward. This is not at all unlikely. It's an indication of a healthy enterprise when there are not "institutional controls" that prevent groups from competing against each other.
Either way, it's big news for Linux. There are all kinds of software synergies that this pulls in. Oracle and Baan will need to address this as a competitive threat.
Oracle, Informix and IBM (with DB2) will be even more committed to a Back Linux strategy now as SAP integration is a big market for the database vendors. None of these vendors will want to leave the DB market open to the others in this potentially explosive growth market, so competition from them will be intense.
Troy Baer wrote
Something to keep in mind about the the Origin 2000 (SGI's 128-256 CPU boxes) is that they're not SMP systems. They're ccNUMA machines, and a lot of the "ccNUMAness" (including cache coherence, I think) is handled largely by the hardware.
The point of ccNUMA is to minimise the cost of porting software from uni-processors. The crux of the matter is that it is non-trivial to adapt programs to run on multiple processors efficiently. The ideal is to have a single source tree, add extensions such as OpenMP, then recompile. Kernels are a different matter as they have to be closer to the hardware. It is still a royal pain to code to the wire and manually manipulate the cache and bus protocols but that is what is needed for maximum performance. Apart from special cases such as national defence codes, the commercial imperative is time-to-market which means a ccNUMA machine can address 95% of the issues at reasonable cost would be preferred.
I wouldn't be surprised if you could boot the MIPS version of Linux on (for instance) an Origin with little or no modification. I don't know how well it would scale, though.
As far as I'm aware (correct me if I'm wrong), the SGI port of Linux has so far concentrated on older systems such as Indys and patches for their VisualWorkstation. I suspect it will take a while (2-5 years?) for them to get to the stage of having Linux+IRIX SMP extensions running on their highly scalable systems. Cellular IRIX is a single system image which is different from the way Linux is designed. Perhaps one conceptual integration approach is to follow how RTLinux works in having a separate real-time kernel embedded within the full Linux system. Also there are other multiprocessor optimisations like processor affinity which might take a while to enter into the kernel. SGI staff may be very enthusiastic and dedicated but there is a lot of work involved which will take time.
In other words, nice PR for SGI but don't hold your breath.
LL
On the other hand, those expensive consultancy hours are quite well spend if they figure out which 80% of your business can be automated without reinventing the wheel, so your programmers can focus on that 20% which makes your business unique. And that is what makes SAP so succesfull. But you need people with a more general business overview, and programmers tend not to be that kind of people.
-- Spelling and grammar errors tend to be a sign of erroneous thinking.
What in the world is Bann? Where can you get it?
Well, you can deny it if you want, but the latest released Linux (2.2) still doesn't scale as well as the latest released NT when it comes to adding processors and network cards. (And as far as the real world is concerned, 2.3 doesn't count, because nobody in their right mind would put a development kernel on a production system.)
I'm not complaining about Linux, mind you, because I know that for most purposes it outperforms the competition. (Which isn't really why I use it; I use it because it's
Again, I do think Linux is the best. But your statement just struck me as being so pro-Linux that you almost seem to be denying facts, and I think that's dangerous.
> Why buy an expensive Sun to be a development box...
Why? Because your production box is a Sun box. You don't necessarily (unless you're using the dev box for performance testing) need to buy the same hardware, but do buy the same platform! Just because you develop it on Linux (or any other platform, for that matter), doesn't mean it will transport to your Sun box and run well there. I've seen it happen _many_ times when people decided to go cheap and get NT for dev, qa, sandbox, etc. I've even seen it UNIX to UNIX.
That's great that there are benchmarks, but... errrm, what the hell does it mean? Did Linux do well? Poor? Average? And most importantly, did it, or did it not, whip the hell out of the NT benchmarks?
by Mike Buddha -- Someday the mountain might get him, but the law never will.
On the other hand, rooting out Y2K bugs from all those evolved systems - all one-ofs, most with the programmers gone away - can be a major disaster.
But if you convert your business process to a specialized configuration of a general-purpose package, you can sidestep the issue. If it's a popular enough GP package, the core will be fixed by the vendor (if it hasn't been already). The Y2K costs for the core will have been distributed over a large number of customers.
As long as you're going to thrash the company's DP for Y2K anyhow, why not re-analyze your processes and go to a supported platform? That way you also end up with fresh code, that your current DP employees understand, which fits your current business model, takes advantage of advances in tools, and does it all with a single thrash?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
"is the highest number of benchmark users on a 4-CPU Intel system measured to date. " Not being too familiar with SAP I don't quite get the benchmark result they are trying to convey. Is the number of users a benchmark result or a test case? Isn't the really benchmark result: "241 SD Benchmark User with 1.96 sec sec average dialog response time 1210 SAPS " The question I'd ask would be how does the response time compare with other platforms and against what number of users?
OTOH: those expensive consultancy hours could be even more expensive if they suggest an unnecessary restructuring of your business just to fit the modules that exist in the SAP software.
mond.
I've had some contacts within SAP, and their engineers have been playing with Linux for a long time; though for a long time (at least several years!) it was unofficial and against Management's wishes. For example, for a long time it was a Deep, Dark Secret that they had ported the the SAPGUI to Linux. And I had gotten back channel tips that the original application server benchmarks they ran on Linux didn't do that well because of how they used mmap's weren't well optimized for Linux. This got fed back to the linux-kernel list without my telling folks it was SAP asking for the speedups. (I think I said it was a for a large financial company.)
A small addendum to this: The review was performed
by Siemens in Walldorf. As far as my sources tell
me, Siemens Walldorf == SAP about as much as
Chicago is linked to the automobile industry.
Sap is that financial/admin package right? I hear that SAP consultants get huge amounts of cash ;)
Ha Ha! I have an SMP system and Linux is the ONLY OS that sees significant performance gains! I knew the day would come when the world would begin to see the light!
Nice to hear this kinda stuff. Ever since the Mindcraft fiasko, the NT clerks at work have been harassing me. Let's see how they respond to this.
More details! More details!
--
Yeah, but,
I don't think anything wouldn't scale well on a box like that.
mmmm..... Quad Xeon III
-----
-----
Ping? PONG!
Which distribution did they use? =)
Red Hat, Caldera, Mandrake, Slackware, Debian, SuSE? I think this last one is the best bet, since SAP A.G. and Siemens are both German companies...
Yes, this should be moderated as "flamebait"! =)
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
Not that Linux scale badly on SMP systems, but it could do much better.Linux 2.3.xx is much better, but we're far from the 128 processors some SGI machine could do. In most cases load could be balanced to many servers (Beowulf) rather than one with 128 processors. To scale to more processors design decisions must be made that may have negative impact on uniprocessors machines (you need to choose between supporting high end servers and average Joe user).
I've used SAP, and it's a good program, it'll be even better if it's portable across all platforms like that. Man, what you can do with SAP. (and yes, SAP consultants make mucho $)
Slay a dragon... over lunch!
This is a good PR bench but if you estimate the necessary context switches/running threads they do not come out to be a really heavy SMP exercise. See the presented client numbers for example.
Also in terms of scaling, it has been proven that Linux scales reasonably well on Intel to 4 already. The question is 8 or more and non-intel systems where its SMP still leaves quite a lot to desire. Unfortunately...
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
they didn't measure gigaflops, the (us) government would never let this machine be imported.
If you want to compare, look at this Top-20 List of Benchmark results. The results we are talking about are listed on Rank 12.
Lost in a lot of the excitement of SGI's port of XFS to Linux was their announcement that SGI has made scaling Linux to 64 processor SMP one of their first goals.
Regardless of my paranoia, I am very glad to see that the charts are looking better for Linux. However, speed in my job, however very important, is not the main thing. Performance in my eyes are 80% stability/reliability, and the remaining 20% are speed and versatility. But thats my book.
Anyway, nice to see that the hard work from the kernel hackers is turning out nicely.
Sincerely,
Alexander
Wealth is the product of man's capacity to think. -Ayn Rand
AFAIK the main problems with Linux in the Mindcraft studies lay in the networking part of the kernel. Applications like SAP don't really do that much of networking stuff, it's more reading and writing data to/from the database and doing calculations/sorting on that data. And, we all know 2.2 was made to do reasonably well on 4 processors. So to say I'm really, really surprised by this? No. Happy? Yes!
:-))) (implying that my boss see it the MS way, wanting to replace the nice RS6000's and other Unix machines with Netfinity's and NT :( )
;-)
I work for a company that is heavily involved in implementing/supporting/customizing another ERP product, Baan (you might have heard about it, Boeing uses it heavily, and had some problems with it). Baan is going the MS way, they want to sell mid-sized computers to mid/small-sized companies. Intel based, running on NT and MS-SQL, being the perfect solution. Just two weeks ago we had a visit from a MS marketing guy, telling us, of course, how beautiful the MS solution is, all integrated and all. When asked about Linux and if they see it as a real thread, he replied that Linux they watched Linux very closely, but that Linux hadn't proved itself with enterprise applications. For small businesses that's very important, they don't have the money to have a full-time Linux/Unix expert to support the box and think they *can* do the administration for the NT box themselves. Wrong? I do think so. The perfect solution I see is the remote administrated Linux box. The company I work for, or whatever other company, does your administration, from our office, or on-site if you want and you get to do what *you*'re good at. And now this news has hit the streets, that not only is Linux one of the most stable OS's, it also is really, really fast (faster than NT?), I think I'm going to dance a few rounds around my desk and drink a few virtual beers when I get home! There's hope for us all!!!
Oh yeah, FWIW, if you want Baan, on Intel, but don't like NT, ask Baan to give you the Linux version, they have it, just don't advertise it. Would they be afraid MS would cut funds if they'd advertise Linux?
Thimo
Avoid the Gates of Hell. Use Linux!
No, because if it's scant on details it can be dismissed. I'd dismiss it if I was an NT or OS-X professional. The more details the less they can dismiss it. Of course, this isn't to say that they DIDN'T do this. I mean I know how well Linux runs. I just want details for those who want more proof.
i am not an SAP expert myself (in fact i think bookkeeping/accounting etc. is something rather boring..) but i have talked with a few persons about that SAP thingy..my impression is that:
just my EUR 0.02.
mond.
Badly.
- A.P.
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
You call it meaningless, but in fact it is just about the most meaningful benchmark you'll ever see! It directly tells you how well the application of your choice (SAP in this case) is going to perform on the hardware and OS the supplier is proposing.
SMP is a non-linear computer architecture. How well you can use 1, 2, 4, 8, or 40394 processors is a function of the hardware, your application, OS scheduling, and how your application interacts with the OS I/O subsystems.
I was getting glorious results from a 4 CPU Linux 2.0 box. Oh, wait, I couldn't have because 2.0 didn't have SMP. Or, well, maybe, but only for 2 CPUs. All crap. The application is what scales first, the OS falls a rather distant second. My app scaled to 4 CPUs and it could have made use of 6, but probably not 7. And so it was.
Microsoft wanted to drive 4 100Mb Ethernet drivers full tilt. If that is your application, then Linux 2.2 SMP scales to exactly 1 CPU, not 4, or even 2.
I'm pretty sure the Linux sched loop has a critical section. Therefor, Linux does not become an absolute scaling issue until a single dedicated CPU can't make it through that loop. You might hit the wall with 40394 CPUs, but you aren't even close with 4, 8, or 64.
SMP is YMMV. It is a non-statement to say "OS X scales to Y CPUs." unless that OS has a hard, physical, implementation limit at Y.
If you don't understand SMP, you probably...
1) Shouldn't suggest you do.
2) Shouldn't repeat bad computer science you've heard from others.
and,
3) Should learn more about it.
...back on the 2.0.x days.
They are using different databases, I bet it would be evn faster with an Oracle or DB2 as the engine.
No, I'm not sure. Call it a strong hunch. =)
I'm looking at the Windows NT pricing information now: the Enterprise edition, full product with 25 client licenses, is about $4k. That's a lot of scratch. (Can't find pricing on additional licenses). So, I may be wrong here.
However: given that any deployment of SAP is a huge undertaking (what, with business processes that have to be reconsidered, consultants that have to be hired)... I'm going to stick with my hunch. Given all the ancillary costs involved, the OS is probably still a drop in the bucket.
Right, a benchmark done in lab conditions by a company that just happens to sell the both the hardware and the software they are benchmarking.
So, in no way an independant test of anything much.
And in any case the thruput probably exceeds what would be possible in an office with the normal mix of 10/100 switched/unswitched ethernet.
Stats - magic words that simultaneously operate as gospel facts and 'damned lies' depending on which side you are on.
Wohoo
-----
- Small and mid-tier companies, with a standardized implementation and integrated support services (application, OS and hardware)
- 3rd party application hosting using the 3-tier R/3 versions.
What we need to see to make the first happen is SAP and consulting firms positioning Linux SAP boxes like appliances: reliable, high performance, low maintenance. This implies built-in support, or pass through support contracts to the Linuxcares of the world.Well, it's certainly good news, but the press release is rather scant on details.
I wonder whether everything was heavily optimised for running SAP; it seems rather like Siemens trying to score some good publicity...
Have they ever tried it using a Quad Xeon with NT, for example?
"At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Okay, so how is this going to be refuted by Microsoft? Easy. SAP is a 3-tier architecture. You've got your clients, your application server (SAP R/3) and your database server (Oracle, Informix, DB2, MS SQL Server, etc.).
You can have as many application servers as you want, but you can only have one database (which could be comprised of multiple servers in a load-balancing cluster such as Digital UNIX's TruCluster on Alphas).
This Siemens test had both the application server and the database server on the same box. Not realistic. Not scalable. Not the way real companies use SAP.
Microsoft already has NT benchmarks with over 1,000 concurrent users. As long as your database server can handle it, you just stick 10 application servers (or however many you wish) out there to take the front end load, and boom - your results go up. In fact, I've seen some UNIX results with 40 application servers all hitting the same database.
Also, no companies are going to use this benchmark, since the database Siemens decided on was SAP DB. Years ago, SAP realized that they were too dependant on Oracle (they're the largest reseller of Oracle database servers). So, they set out to write their own database. Then they realized it's not that easy. No one bought it. I had heard that development of SAP DB was killed. Evidently not - it was just ported to Linux. Still, nobody uses it in the real world.
We're off to a great start here, but still have a long way to go. Still, thanks Siemens!
well lets think !
who just added large memory surport to the linux kernel ??
that be SUSE and Siemens hmmm !
they will have used a SUSE distro and their own tweaks
SAP/R3 is a big set of tools and I wonder if SAP are trying to expand into the US and see linux as a way forward it would be relitively easy for them to do the port so why not get some millage out of it and make some money.
redhat wanted to move to germany because of vendors like SAP
looks like to home team (SUSE) made friends fast !
ah well this can only help but say LINUX to upper management
love
john
a poor student @ bournemouth uni in the UK (a deltic so please dont moan about spelling but the content)
SAP -is- a big, huge, expensive financial applications software package. And it's sweet that it's being supported under LINUX.
It's important to realize that although LINUX may crank adequately on a nice SMP machine, it isn't time to wave the flag of victory. The flag of victory is still far away. The battle has just begun, and this is merely a small victory.
The flag of marketing CAN be waved. But as you know, Microsoft waves that flag all the time, and they have a damn big marketing flag.
Now in terms of SAP, my personal opinion is:
SAP consultants, yeah, they make big bucks. That's where you want to be if you associate "cool job" with "size of annual income". But if you associate "cool job" with "cool technology", stay away from SAP! In my humble opinion, of course.
Yeah, some companies believe that years of evolved systems designed for their business can be inexpensively replaced with "general purpose, off-the-shelf" packages. Generally, I think those folks are nuts. I think that it is usually much more expensive to replace old-but-well-optimized applications with a general purpose package, in both the short term and the long term. But it lets the CIO lay off a bunch a people... a short term victory for him (or, very occasionally, her).
Sorry about this rant but I've got the scars.
I had the unfortunate experience of spending 5 months at a company working on a project to replace their old IT systems with a SAP R/3 implementation. The whole thing was a nightmare from start to finish, the process of transferring data into SAP was ludicrously complicated and time-consuming, and SAP itself is a slow, inflexible and non-intuitive application with a clunky early-nineties style user interface.
The project came in way over budget and time, but the saddest thing was the end-users were all very disappointed with what they got.
Yes, SAP consultants DO get LOTS and LOTS of money, though why escapes me (Disclaimer - I am jealous), but I've heard that SAP's revenues are on the way down, and their reputation is in the mud.
It is a well-known fact that an SAP-implementation bill can run up to astronomical levels. The part that goes to OS licenses is minute, compared to what the company will pay (in that order):
...) ...)
/.ers write about accounting and stuff, they seem to find it a boring subject. Companies know this too. Would you get your accounting software from people who are not really interested in accounting?
(1) Front-end business consultants for process re-engineering (usually E&Y, KPMG, AA,
(2) Implementation consultants and customisation programmers
(3) SAP licenses
(4) Oracle licenses (or Sybase, or SQLServer,
I don't mention the costs involved in:
(1) Time from employees involved in the project
(2) Training costs and other costs of transition
These costs are usually not accounted for in the total cost of the project, but are believed to be a multiple of the visible costs.
I don't believe that the OS bill will reach 5% of the total visible costs, in case the company implements proprietary Unix or NT.
Given the amount of FUD spread about Linux, I don't see that many companies invest the amounts needed for the whole project, and have the whole thing run on Linux.
If you want companies to run their business backbone ERP on Linux, the open source world will have to produce their own SAP. However, when I read what
So lets conclude that, making abstraction of the odd exception, businesses will never run their business backbone ERP systems on Linux.
At the risk of total flamebait... I've been working with SAP software for about 5 years now, doing a number of installations, so maybe I can help clarify things a bit here. My view of SAP:
- It's really big: it covers almost all back-office functionality that you would want (everything from accounting to HR to manufacturing automation), and as a result it's huge - about 3 GB of code source alone, for example
- implementing it all for a large organization is very expensive - for Fortune 500 companies, a complete installation will be close to $100m including everything
- but for a small company, with limited functionality, it's not expensive - I've seen it done for $200k at a startup before, which isn't bad considering that it runs the whole business
- it's semi-open source - essentially all the business logic is written in ABAP, SAP's language; all the source code comes with the system (only a minimal amount of core code comes as pre-compiled c exes)
So those are the facts... I'll hold on the opinions.
Theo
If things didn't break, you wouldn't learn anything.
The Linux test score of 241 users appears to have made the top twenty on ideasinternational's 2-tier SAP benchmark list. (That appears to be the Linux/Siemens machine in 12th place.)
;)
Though still a long way from the leader, a Sun 10000 rated at 1410 users, it is closing in on machines like the 12-CPU IBM AS/400 at 330 users.
Geeky modern art T-shirts
Just creates bloat and more endless layers of hierachical control when a more decentralized information management approach is better.
There are many tradeoffs one has to make, whether it is supporting 2GB (or 4GB) memory vs 1 GB, or 128 processors vs. 1. For Linux these kinds of choices have never really been a problem, as one can recompile the kernel at will, optimizing for the local configuration and intended use.
:-)
If I have a uniprocessor machine, I can compile the kernel without SMP support altogether. If I have a 128 processor machine, hopefully I would be able to compile the kernel with SMP support and, additionally, "massively parallel optimizations = Y" or something similar. This is the beauty of having the source available -- we can have our cake and eat it too. With any luck my old i486 will be able to sit next to the latest SGI 128 processor box my boss *will* be purchasing for me (I wish), both running 2.4.x of the kernel. I'll let the new guy have the i486.
The Future of Human Evolution: Autonomy