Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

First official SAP R/3 benchmarks on Linux

Hemos posted more than 15 years ago | from the fun-with-testing dept.

Linux 120

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. "

Sorry! There are no comments related to the filter you selected.

For those who don't know, SAP R/3 is... (1)

Anonymous Coward | more than 15 years ago | (#1686101)

SAP R/3 is a suite of applications (for Windows NT, UNIX, OS/400, or AIX) that covers the whole spectrum of business operations: Human Resources, Asset Management, Sales and Distribution, Quality Management, Financial Accounting, Business WorkFlow, Plant Maintenance, Project Systems, and more. Businesses tend to use a mix of different software to manage these operations, but R/3 attempts to do it all under one roof. [...] The result is you have all your ducks in one software row: invoices, purchase orders, shift schedules, inventory, shipments, payments, and bills are all in one system rather than scattered all over the office.

Quoted from an article called "What is SAP?" [techsightings.com] posted at TechSightings.com

...however many people feel that SAP's popularity is due more to agressive marketing and Amway-style recruiting of clients and consultants to adopt R/3.

Re:Realistic benchmark? (1)

net-fu (85849) | more than 15 years ago | (#1686102)

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!)

Re:Rain. (1)

JAZ (13084) | more than 15 years ago | (#1686103)

It was an accident I swear.

please don't beat me, I'll be good

Re:SAp (1)

tposselt (62882) | more than 15 years ago | (#1686104)

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

Re:SAp (1)

angelo (21182) | more than 15 years ago | (#1686105)

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...

Re:Need "full solutions packages" (1)

Vidar Hokstad (87953) | more than 15 years ago | (#1686106)

SAP ported R3 because they got requests from customers, so obviously the demand is there.

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.

See same about large mission|safety-critical apps. (0)

Anonymous Coward | more than 15 years ago | (#1686107)

(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.

SMP and Points of Failure (1)

Greyfox (87712) | more than 15 years ago | (#1686108)

IMHO having a box with more than 2 to 4 processors is just silly anyway. For the price of all that big iron, you can get a lot of little iron and distribute it around, insuring that you don't have a single point of failure. All the processors in the world won't help you if someone spills coffee in the machine or something like that. For most applications where benchmarks are done, having a single point of failure is just stupid.

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?

notice (1)

mistabobdobalina (29109) | more than 15 years ago | (#1686109)

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.

Re:SAP = "the european micro$oft." (1)

aUser (78754) | more than 15 years ago | (#1686110)

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.

Re:SAp (1)

HighFlyer (60002) | more than 15 years ago | (#1686111)

SAP has been unkindly described as "corporate heroin", because it promises so much at the beginning, but then you become dependent on it, then it never seems to deliver, then it kills you. At least one or two companies have sued the makers because (they claim) their SAP programme was so bad a software disaster that it drove them into bankruptcy.

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.

Re:SMP and Points of Failure (1)

substrate (2628) | more than 15 years ago | (#1686112)

Well, humble opinions aside, not every application in the world can be shoe horned into 2 or 4 processors and not every application will work well over a Beowulf or distributed computing model. This is true regardless of the processor used. The Alpha processor is wonderful and all but its not going to be able to make up for gross architectural deficiencies.

If a problem scales well to SMP but requires a lot of memory bandwidth between non-local processors then distributed computing will not work efficiently. Moving from an IA32 processor to a Alpha processor will only result in more cycles being spent idle waiting for data to come in across the network interface. In real high performance systems processor speed is only a small part of the equation for overall system performance if you're actually in a scenario where that high speed system is appropriate. Look up Amdahl's law in Hennesy & Patterson's Computer Architecture: A Quantitative Approach second edition and work through some of the problems.

These systems also have redundancy, fault tolerance and fault isolation built in to them. When you accidently dump your coffee into them they'll be recovering before your manager sends you on the way to your next job operating a cash register at the local McDonald's.

Re: Meaningless rubbish (not) (1)

HighFlyer (60002) | more than 15 years ago | (#1686113)

[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.

Re:Now, the real question is... (1)

droesen (86699) | more than 15 years ago | (#1686114)

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 [mailto]

Re:Info and ideas (re:Linux and scaling...) (2)

DragonHawk (21256) | more than 15 years ago | (#1686115)

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. :-)

Re:SAp (1)

aUser (78754) | more than 15 years ago | (#1686117)

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.

Linux SMP (1)

substrate (2628) | more than 15 years ago | (#1686124)

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.

SAP DB (1)

MKaufmann (58554) | more than 15 years ago | (#1686125)

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.


Re:Need "full solutions packages" (1)

sammy baby (14909) | more than 15 years ago | (#1686126)

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.

Info and ideas (re:Linux and scaling...) (3)

DragonHawk (21256) | more than 15 years ago | (#1686127)

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?

Disturbing... (1)

jonnythan (79727) | more than 15 years ago | (#1686128)

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.....

Re:Rain. (0)

Anonymous Coward | more than 15 years ago | (#1686129)

LART LART LART LART
*screams*
LART LART LART LART
*silence*
That's better!

Q about PPC-based SMP (1)

Tekmage (17375) | more than 15 years ago | (#1686130)

Any word on when LinuxPPC will run the SAP benchmark on one of these [sky.com] ?

The thought of a flock of 4,096 MPC7400 (aka G4) processors running the penguin, with 16 terabytes of shared memory...

Re:Linux and scaling... (1)

Aussie (10167) | more than 15 years ago | (#1686131)

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.

Re:Scaling... (1)

clawson (5082) | more than 15 years ago | (#1686132)

...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?

Scaling... (1)

doobie (2546) | more than 15 years ago | (#1686133)

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.

2.2.11 has bad memory leak (0)

Anonymous Coward | more than 15 years ago | (#1686134)

They used the 2.2.11 kernel that is known have the worst TCP memory leaks.

Not unexpected. (1)

bgarcia (33222) | more than 15 years ago | (#1686135)

Remember, the linux kernel itself might not be very good at SMP, but multi-threaded applications will work very well.

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...

Tidbit mentioned by Bob Young (1)

tilly (7530) | more than 15 years ago | (#1686136)

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

Re:Linux and scaling... (0)

Anonymous Coward | more than 15 years ago | (#1686137)

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.

Re:Linux and scaling... (1)

Sxooter (29722) | more than 15 years ago | (#1686138)

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!

Re:SAp (1)

JordanH (75307) | more than 15 years ago | (#1686139)

Usually, SAP installations are multi-million projects that involve business processes redesigns and other unpleasant stuff for people involved.

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.

Re:Linux and scaling... (1)

LL (20038) | more than 15 years ago | (#1686141)

Troy Baer [slashdot.org] 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 [openmp.org] , 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 [llnl.gov] , 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 [sgi.com] 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 [nmt.edu] 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

Re:Bann? (0)

Anonymous Coward | more than 15 years ago | (#1686143)

What in the world is Bann? Where can you get it?

Re:Realistic benchmark? (1)

CigarBuff (61105) | more than 15 years ago | (#1686145)

> 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.

SAP (or other GP packages) as a Y2K solution. (1)

Ungrounded Lightning (62228) | more than 15 years ago | (#1686147)

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.

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?

SAp (1)

mTor (18585) | more than 15 years ago | (#1686154)

Sap is that financial/admin package right? I hear that SAP consultants get huge amounts of cash ;)

The sweetness of SMP Linux will prevail!! (1)

jdwilso2 (90224) | more than 15 years ago | (#1686155)

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!

Re:SAp (2)

kees (6972) | more than 15 years ago | (#1686156)

Right. SAP started out as a financial/logistics
packages, but by now has evolved into a huge
ERP (Enterprise Resource Planning) packages.
Basically, SAP is supposed to allow you to
monitor/control almost every aspect of your
business process. Usually, SAP installations are
multi-million projects that involve business
processes redesigns and other unpleasant stuff
for people involved.

Bringing SAP to Linux is a major breakthrough
for Linux in business though.

Yay! (1)

EmilEifrem (11066) | more than 15 years ago | (#1686157)

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.

Rain. (2)

Signal 11 (7608) | more than 15 years ago | (#1686158)

Umm, not to rain on anybody's parade - but this article is *really* scant on details. What distro did they use (some optimize packages, some don't)? Did they compile the kernel with -O6, or use what came with the distro? There's dozens (nay, hundreds) of kernel tweaks you can apply to give you increased performance - one that comes to mind is the minimum timeslice which if you adjust upwards can help on hardware with small cpu caches. I don't believe anything until I see some raw data - I want numbers, and lots of 'em.

More details! More details!

--

Quad Xeon III (1)

theLabRat (31958) | more than 15 years ago | (#1686159)

Yeah, but,
I don't think anything wouldn't scale well on a box like that.

mmmm..... Quad Xeon III



-----

Now, the real question is... (1)

Noryungi (70322) | more than 15 years ago | (#1686160)

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"! =)

Linux and scaling... (1)

krynos (1706) | more than 15 years ago | (#1686161)

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).

It's good to see that (1)

nahdude812 (88157) | more than 15 years ago | (#1686162)

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 $)

This is a good PR bench (1)

arivanov (12034) | more than 15 years ago | (#1686163)

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...

Good thing... (1)

jerrytcow (66962) | more than 15 years ago | (#1686164)

they didn't measure gigaflops, the (us) government would never let this machine be imported.

Even more details (2)

Twinky (32219) | more than 15 years ago | (#1686165)

If you want to compare, look at this Top-20 List [ideasinternational.com] of Benchmark results. The results we are talking about are listed on Rank 12.

Re:Quad Xeon III (1)

jdwilso2 (90224) | more than 15 years ago | (#1686166)

That is an extrodinarily good point, but when you consider that Linux performed better on this system than any other OS, does it mean that Linux scales well, or that it's just better on all levels? :o)

Re:Linux and scaling... (1)

barleyguy (64202) | more than 15 years ago | (#1686167)

As far as 128 processor SGI's, it would be cool if SGI would contribute some of their IRIX multiprocessor code to the open source community. Would that be better than the current 2.3 stuff?

Re:Rain. (1)

theLabRat (31958) | more than 15 years ago | (#1686168)

Yes, I agree.

No links, no pics, no motor home, not a single luxury. No wait. That's Gilligan's Island.

Anyway, I assumed they used SuSE Linux, seeing how this article is on a German site, and the tests done by a German company. Hmmm... SuSE comes with a 2.2.10 kernel, though. 'Course, it's not that hard to find kernel sources and make a new one.

But, as usual, I'll probably be wrong. Foolish assumptions. Ugh.



-----

SGI to the rescue (0)

Anonymous Coward | more than 15 years ago | (#1686169)

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.

Paranoid as I am... (2)

alsta (9424) | more than 15 years ago | (#1686170)

I read on slashdot that there was an alledged `secret joint venture' between Siemens and Micorsoft. Are they perhaps making a groundlevel marketing issue here before they `unveil' their new distribution?


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

This gives me a warm feeling inside... (4)

thimo (36102) | more than 15 years ago | (#1686171)

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!

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!!! :-))) (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 :( )

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

More data needed. (0)

Anonymous Coward | more than 15 years ago | (#1686172)

Who cares... It's Linux. Isn't that all that really matters ??

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.

Re:SAp (2)

jsm2 (89962) | more than 15 years ago | (#1686173)

Usually, SAP installations are
multi-million projects that involve business
processes redesigns and other unpleasant stuff
for people involved.


Wow, do they ever!

SAP has been unkindly described as "corporate heroin", because it promises so much at the beginning, but then you become dependent on it, then it never seems to deliver, then it kills you. At least one or two companies have sued the makers because (they claim) their SAP programme was so bad a software disaster that it drove them into bankruptcy.

First thought: The idea that Linux could in some way facilitate this process fills me with the same ambiguous dread I would feel if I heard that it had been adopted as OS of choice by the Bosnian Serbs.

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.

It would be nicer, of course, for the ERP system to be put in, bit by bit, by the people who know their local area best (the employees), and in response to their own needs. That way you could develop the management/information/computer nexus through a kind of "open" co-operative, non-hierarchical structure ... remind you of anything? No, not socialism, the other one.

If I were the betting type, I'd guess that if Open Source creates any billionaires, it'll be in something like ERP, or these other "mega-app" projects where the development model currently used is so obviously screwed. Call it the "GNUERP" project or something, and make sure taht the software tools are built around (and mirror) a set of management practices resembling ESR's "Bazaar" essays. It won't be me -- I don't have the energy or motivation. But it might be Eric Raymond . . .

jsm

SAP = "the european micro$oft." (1)

dermond (33903) | more than 15 years ago | (#1686174)

while that benchmark is good as it telles ppl about the performance of linux i want to say a few words about that SAP.

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:

  • it is huge and bloated and expensive and one needs lots of $$$ to pay people who know this huge and bloated thing (consultants) to have a chance to make use of it.

  • people use it because everyone else uses it and when everyone else uses it it can not be bad (this is one similarity with m$)

  • maybe there are cases where the use of this thing makes some sense but i guess most ppl would be better of if they hire one ore 2 dedicated programmers who built a custom solution for the company there the company would have the source and would not depend on a propritary solution. after all for most companys the only use is a small number of database tables anyway.. (of course the company would have to take care that the source is well documented so it does not get to much dependent on the programmes who implemented it.. why?:
    • coders are cheaper then consults their knowledge is not so much spezialised.
    • if you have to customize sap and you have to code towards possible bad documented interfac/api then it could be more work then doing it all by yourself.




just my EUR 0.02.

mond.

Re:Quad Xeon III (0)

Anonymous Coward | more than 15 years ago | (#1686175)

This is ridiculous. I saw absolutely nothing in their press release that indicates anything at all about Linux scalability. In order to draw any type of conclusion we would have to review data for a single processor Linux box as well, or a two processor box, etc. Additionally, to think that anything wouldn't scale well on a four-processor box is just ignorant. There are operating sytems that are designed to scale from 1000 to 1500 processors. Do you think that these scale well on a four processor box? I don't think so.

Re:Even more details (1)

Shane (3950) | more than 15 years ago | (#1686176)

It's running Oracle. Not SAP/3 :)

. . . flamebait? (1)

Wakko Warner (324) | more than 15 years ago | (#1686177)

Some moderators really need to be beaten. This is flamebait?

Badly.

- A.P.
--


"One World, one Web, one Program" - Microsoft promotional ad

Re:Info and ideas (re:Linux and scaling...) (2)

Salamander (33735) | more than 15 years ago | (#1686178)

>Now, I imagine that we could define multiple "levels" of locks in the kernel...

Yes, this has been done many times, and it works great. I know NT has multiprocessor and uniprocessor kernels that are distinguished from one another in pretty much the way you describe, and I thought Linux had build flags to that effect too (but there I'm less certain).

One gotcha: it's a good idea to install the MP kernel if the hardware is MP-capable even if it only actually has one proc installed. Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo. MS screwed this up with NT, burning lots of people who installed with a single processor and then upgraded to two later. You pretty much have to reinstall the OS. IMX, copying ntkrnlmp.exe from your install CD over ntoskrnl.exe works, but I wouldn't count on that being universal. Some platforms may have separate HAL modules, and MS may have extended their broken thinking to drivers since I last tried this.

Re:Disturbing... (1)

Quigley (18976) | more than 15 years ago | (#1686179)

Maybe I'm just on crack, but like every other post in here points out Linux's deficiencies with anything more than 2 or 4 processors. If that isn't open admission I don't know what is.

I also don't think people are questioning the benchmark because 1) its a lone proprietary application, closed-source to boot, and 2) how many of us really care about SAP performance compared to the amount of us that care about web serving/smb performance?

Re:SAp (0)

Anonymous Coward | more than 15 years ago | (#1686180)

Hey, man -- mainframes are cool and the fees are a lot more reasonable (well, how about reasonable for the first time) these days. If you need a mainframe, you need a mainframe. On a more germain topic, how can I get a beta of R/3 for Linux to work with my beta of DB2 for Linux? On a less germain topic, it sure is upsetting how easily you can intimidate pretty women with shop talk. You just start chatting and they look very insecure, then they leave. Bummer.

Re:SAP (or other GP packages) as a Y2K solution. (0)

Anonymous Coward | more than 15 years ago | (#1686181)

Sorry about your Rod, man. So, umm, Lorena -- is she seeing anyone now?

Re:Meaningless rubbish (0)

Anonymous Coward | more than 15 years ago | (#1686182)

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.

Re:SAP = "the european micro$oft." (0)

Anonymous Coward | more than 15 years ago | (#1686183)

Well, I have experience with both, and I have to say that SAP works well in two environments: 1. Everything is so broken that it cannot get worse, so even a poorly running SAP setup is loads better. 2. You are growing so fast that you need something to give you structure, TOMORROW BY 10:00! For all other large companies, COBOL is still king because it works, works well, is plenty fast, and people know it. The death of COBOL is greatly exaggerated.

Re:SAP = "the european micro$oft." (1)

dermond (33903) | more than 15 years ago | (#1686184)

for the huge money the software costs and the consultants cost one can pay a lot of programmer hours... btw: of course programmers who do not find accounting boring would be better there.. i did not say that i want to do that stuff..

Re:Linux and scaling... (0)

Anonymous Coward | more than 15 years ago | (#1686185)

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.


A couple of things to keep in mind:

* Scaling well on a massive scale (eg, 64-processor support like Solaris) is not necessarily a good idea. It *has* to hurt your low-end performance, given all the additional locks that are needed.... At some point, Linux is probably going to have to decide what it wants to target.

* SGI's 128-processor boxes are ccNUMA, not SMP. That's an entirely different subject ;-).

SMP and Scaling FUD... (0)

Anonymous Coward | more than 15 years ago | (#1686186)

Yep, Linux scales to 4 CPUs. Then its dead. Or, so the story goes.

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.

Well, Linux didn't scale well on SMP... (0)

Anonymous Coward | more than 15 years ago | (#1686188)

...back on the 2.0.x days.

Dumb comparison... (0)

Anonymous Coward | more than 15 years ago | (#1686190)

They are using different databases, I bet it would be evn faster with an Oracle or DB2 as the engine.

Re:SAp (1)

tposselt (62882) | more than 15 years ago | (#1686191)

On the mainframe fees, I don't know about the cost for a new system, but I know lots of shops that are paying literally millions in fees for relatively small mainframe systems. On the women front, sorry, no help.

Re:Need "full solutions packages" (1)

sammy baby (14909) | more than 15 years ago | (#1686193)

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.

Re:Rain. (1)

Hall (962) | more than 15 years ago | (#1686194)

What distro did they use (some optimize packages, some don't)?

Who cares... It's Linux. Isn't that all that really matters ?? Anyways, what distros come with kernel 2.2.11 ? RedHat ships with 2.2.5, Mandrake with 2.2.9. Sorry, but I don't know about any others.

Did they compile the kernel with -O6, or use what came with the distro? There's dozens (nay, hundreds) of kernel tweaks you can apply to give you increased performance

Again, assuming that no distros ship with that new of a kernel, they likely compiled their own. Did they use the "-O6" flag ? If it helps, why shouldn't they.

Isn't it a benefit of Linux that they can do "dozens (nay, hundreds) of kernel tweaks" ? I think so!

Meaningless rubbish (1)

Jon Peterson (1443) | more than 15 years ago | (#1686195)

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

Re:Even more details (1)

Blitzkopf (21587) | more than 15 years ago | (#1686196)

Then why is there a four processor Primegy server in 11th place?

Re:Rain. (1)

Signal 11 (7608) | more than 15 years ago | (#1686197)

You've completely missed the point of my post - there's no data either way. And *duh*, of course it's a benefit that you can tweak the kernel to your heart's content. Did I say otherwise?

--

Need "full solutions packages" (1)

HenryFlower (27286) | more than 15 years ago | (#1686198)

Who buys SAP R/3 on Linux? Anyone with the money for really huge traditional rollouts of SAP (Anderson comes in and re-engineers your processes aroud SAP for $5M) doesn't want to put SAP on a Linux box. (Besides, that market is well saturated these days). Where I see the market is for:
  • 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.

Re:Even more details (1)

mlefranc (85595) | more than 15 years ago | (#1686199)

Yes, but the only quad servers that are ahead of the mentioned system are Alpha systems, not Intel ones. Not really the same class.

Re:Need "full solutions packages" (1)

Zachary Kessin (1372) | more than 15 years ago | (#1686200)

Maybe the Siemens and SAP folks see this as a way to get SAP into places that they never would have before. Yes you can get a full R/3 package setup for $5 Million. But that is a lot of money. Maybe they see this as a way of lowering the entry point to say $250K. At that price they may be able to get a lot more customers in the door.

I could be wrong but that seems to me a good way to grow your sales.

How accurate is this? (1)

Matthew Vernon (87796) | more than 15 years ago | (#1686201)

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?

Re:Disturbing... (1)

quade]CnM[ (66269) | more than 15 years ago | (#1686202)

First of all, There were problems with the mindcraft benchmark. Anyone in there right minds that looked at the results knew they were skewed way off. So some peaple did some investigations, and found the problems. If you noticed, when they re-ran the tests at ZD labs, there were far fewer flaimers. There were plenty of peaple explaining why Linux dident do as well. If you have noticed many developers have taken it up to fix the problems.

Also note that they dident realy compare these results to NT directly. For all I know, the latest NT results were taken a year ago on a Quad Xenon 400 1M Cache. All this proves is that a Linux machine is capable of hanging with the big boys like Sun (as long as you dont get to the E10k stage) IBM, and the like. For all I know, they could test W2K tomarow, and beat the pants off of Linux.... But this would definatly prove that using Linux isn't a bad choice by any means.....

Realistic benchmark? (4)

CigarBuff (61105) | more than 15 years ago | (#1686203)

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!

memory my dear friend, memory ! (1)

johnjones (14274) | more than 15 years ago | (#1686204)

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, Linux, money, and performance (1)

Anonymous Coward | more than 15 years ago | (#1686205)

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).

Yesterday's Software (1)

Philageros (57698) | more than 15 years ago | (#1686206)

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.

Re:Linux and scaling... (2)

Troy Baer (1395) | more than 15 years ago | (#1686207)

As far as 128 processor SGI's, it would be cool if SGI would contribute some of their IRIX multiprocessor code to the open source community. Would that be better than the current 2.3 stuff?

Probably a little. SGI has some engineers working on improving Linux's SMP scalability, but Linus has seemed to be wary of accepting patches from them. 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. The memory systems on SGI and Compaq/DEC Alpha SMP systems are often twice as fast or more and switched.

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. 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.

--Troy

Re:Even more details (0)

Anonymous Coward | more than 15 years ago | (#1686208)

Can't read anything. Don't have Windows.

SAP too expensive for a linux environment (1)

aUser (78754) | more than 15 years ago | (#1686209)

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):

(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 /.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?

So lets conclude that, making abstraction of the odd exception, businesses will never run their business backbone ERP systems on Linux.

Re:SAP DB (1)

tposselt (62882) | more than 15 years ago | (#1686210)

Yes, SAP bought rights to the Adabas DB a couple of years ago. SAP DB is Adabas, as far as I know. But let me go to the source - I have a friend in SAP working in the Adabas group, I'll ask him to confirm.

And no, basically no one in the US uses SAP DB. I've done about 10 SAP installations, and in that whole time no one from SAP has mentioned SAP DB/adabas, and none of the customers have asked for it.

Re:Need "full solutions packages" (1)

fwr (69372) | more than 15 years ago | (#1686211)

Are you sure about that? Depends on how many people would be using the system. What's the list price of Windows NT Server (or two, one for SQL Server) with enough client licenses for all the users to connect. Then you probably want to add a separate PDC and BDC apart from the SAP servers. The you have the cost of the upgrades that might be necessary on the workstations. It gets to be expensive. Didn't you see that article that mentioned a cost of up to $3000 just to upgrade to Windows 2000, let alone any cost for a system such as SAP...

Re:Quad Xeon III (1)

mkettler (6309) | more than 15 years ago | (#1686212)

I would argue that to assume that an app will scale to four processors is quite ignorant, not the other way arround as you claim. In order to scale nicely to multiple processors your work needs to be dividable amongst processors. Some applications achieve this through threading, and others use multiple processes to get the job done but not all applications are coded to do this. One of the big improvements in the 2.2 kernel was improvements to allow more of the kernel code to spread nicely over multiple cpu's. This work on the kernel is by no means complete, so even the kernel is unlikely to be as scalable as it could be.

Sometimes dividing a job up into multiple tasks to work on multiple processors can even cause a *decrease* in overall performance compared to a single cpu box. This is mostly seen in systems such as the orignial pentium (not ppro or pII) on a HX or similar chipset. This arangement has its l2 cache shared by both processors and accesing it causes somewhat expensive bus contention. Should both processors be working on a computation involving a dataset/codeset much larger than the L1 cpu cache they can degrade performance to a point where it would be faster to remove the extra cpu. Now I'll agree this is a much more difficult condition to create within the ppro/pII processor family, but it does outline that scaling to multiple cpu's is not a trivial task.

But really weather or not it scales to four cpu's efficently isn't the point of the article. As I see it the point is that for this particular test, linux performs better than it's competition on a quad-xeon. This would imply that linux is scaling to the four cpu's better, and taking better advantage of them.

SAP facts (2)

tposselt (62882) | more than 15 years ago | (#1686213)

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

Linux climbing the benchmark pages... (3)

Sun Tzu (41522) | more than 15 years ago | (#1686214)

The Linux test score of 241 users appears to have made the top twenty on ideasinternational's 2-tier SAP benchmark list [ideasinternational.com] . (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. ;)

Process management software is WAY overrated (1)

metawronka (90656) | more than 15 years ago | (#1686215)

Just creates bloat and more endless layers of hierachical control when a more decentralized information management approach is better.

Re:Rain. (1)

JAZ (13084) | more than 15 years ago | (#1686216)

I'll probably get moderated to hell for being redundant. but we need lots more info to use this with our PHBs.

how much higher?

what kind of benchmarks were used?

what was tested?

exactly how did other machines fair?

If I'm going to argue that our multi-million dollar SAP solution will run better on linux versus solaris7/NT4/DOS3.3 I gotta be able prove my point before it will even be considered.


bottom line : this is the information age, and I want more!!

Configure for local optima and recompile (1)

FreeUser (11483) | more than 15 years ago | (#1686217)

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. :-)

Re:Process management software is WAY overrated (0)

Anonymous Coward | more than 15 years ago | (#1686218)

The comment above this is a bunch of crap.
What a flamebait comment

Re:Rain. (0)

JAZ (13084) | more than 15 years ago | (#1686219)

I'll probably get moderated to hell for being redundant. but we need lots more info to use this with our PHBs.

how much higher?

what kind of benchmarks were used?

what was tested?

exactly how did other machines fair?

If I'm going to argue that our multi-million dollar SAP solution will run better on linux versus solaris7/NT4/DOS3.3 I gotta be able prove my point before it will even be considered.


bottom line : this is the information age, and I want more!!




Re:Rain. (1)

Signal 11 (7608) | more than 15 years ago | (#1686220)

I'll probably get moderated to hell for being redundant.

Well, you know, that does tend to happen when you post the same thing multiple times... ;^)

--

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?