Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Linux Software

First official SAP R/3 benchmarks on Linux 120

Posted by Hemos from the fun-with-testing dept.
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. "
This discussion has been archived. No new comments can be posted.

First official SAP R/3 benchmarks on Linux More

First official SAP R/3 benchmarks on Linux

Comments Filter:

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

    by Anonymous Coward
    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.

  • 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. (Score:1)

    by JAZ ( 13084 )
    It was an accident I swear.

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

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

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

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

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

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

  • 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]
  • 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 (Score:1)

    by aUser ( 78754 )
    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.
  • 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.)
  • 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.

  • 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 [baan.com] for more information.

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

      In other words, they don't sell the software that they are benchmarking.

    2. 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.
    3. The implication that the throughput is excessive is fairly much irrelevant.

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

    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.

    It's not merely ``benchmarketing.''

  • It will be real interesting to see where this takes Linux, and what impact the availability of R/3 on Linux has on sales of R/3 on NT.

    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.

      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.

        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.

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

      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.

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

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

    Interesting times, to be sure...
  • 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.

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

    by DragonHawk ( 21256 ) on Monday September 13, 1999 @02:59AM (#1686127) Homepage Journal
    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?
  • 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.....
  • 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...
  • 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.
  • 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...

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

  • On the other hand, no one looks for holes in an article that comes out stating that Linux is blazingly fast.

    Looking for competitive flaws in linux is the job of MS and other competitors. Ask any MS salesman if he recommends linux and you'll get "not ready for the enterprise" or some such. And they'll use technical arguments too, those few times they can find some.
  • 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
  • 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.

  • 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 /free/. But it's nice to know that it's also technically superior.)

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

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

  • Re:SAp (Score:1)

    by kees ( 6972 )
    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.
  • >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.

    I don't think it's done in either Linux or NT, but I certainly have seen it done. One variant of UNIX that I worked on could be configured to lock STREAMS modules either globally, per-major, or per-minor. Another did much of its locking using hashed locks; the degenerate case was one bucket, but you could add buckets to increase parallelism.

    The problem that arises with these approaches is that the deadlock possibilities tend to be different at each level of locking, and need to be addressed separately. It's like having to do the locking three times three different ways for the same code. Once finer-grain locking has been implemented for a component or subsystem, the developers would generally prefer to turn their backs on the coarser stuff immediately.
  • That's how SAP benchmarks are done. The platform is loaded up with users (SD = Sales and Distribution) until the response time pushes 2 sec. They have a standard test suite that each user runs - creating SO's, changing SO's, picking goods, etc. Usually they're done by the hardware vendor, they usually tweak the underlying platform all to hell but they're not allowed to modify SAP.

  • SAp (Score:1)

    by mTor ( 18585 )
    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!

  • Re:SAp (Score:2)

    by kees ( 6972 )
    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.
  • 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.
  • 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!

    --

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

    mmmm..... Quad Xeon III



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

  • 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 [ideasinternational.com] of Benchmark results. The results we are talking about are listed on Rank 12.
  • 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)
  • 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?
  • 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.



    -----
  • 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... (Score:4)

    by thimo ( 36102 ) on Monday September 13, 1999 @02:00AM (#1686171) Homepage
    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

  • Re:SAp (Score:2)

    by jsm2 ( 89962 )
    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
  • 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.
  • It's running Oracle. Not SAP/3 :)
  • Some moderators really need to be beaten. This is flamebait?

    Badly.

    - A.P.
    --


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

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

  • 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..
  • Sorry, one other thing. Other platforms - Sun, HP unix, IBM mainframe - can have SD numbers in the 1000's; my last site ran Sun E10000's (previously Cray machines) and those were benchmarked at around 3000 at the time.

    check out http://www.sap.com/ and search for 'Benchmark' for more details.

    Theo
  • 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.
  • >Kernel: 2.2.11-SAP2
    >[nobody knows what SAP has done with 2.2.11].

    Thanks for the info -- but your last sentence seems to imply that SAP did not reveal the changes it has made to kernel 2.2.11? Isn't that a violation of the GPL? Or is it just that they have not published the changes just yet?

    If they do publish the changes, and they turn out to be substantial, this could benefit the entire (GNU-) Linux community and not just SAP/Siemens.

    Do post more information, and thanks for your work!
  • 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. (Score:1)

    by Hall ( 962 )
    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!

  • 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
  • Then why is there a four processor Primegy server in 11th place?
  • 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?

    --
  • 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.
  • Yes, but the only quad servers that are ahead of the mentioned system are Alpha systems, not Intel ones. Not really the same class.
  • 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.
  • 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?
  • 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? (Score:4)

    by CigarBuff ( 61105 ) on Monday September 13, 1999 @02:18AM (#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!
  • 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 (Score:1)

    by Anonymous Coward
    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.

  • 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
  • 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.
  • 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.
  • 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...
  • 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.
  • 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... (Score:3)

    by Sun Tzu ( 41522 ) on Monday September 13, 1999 @02:21AM (#1686214) Homepage Journal
    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. ;)
  • Just creates bloat and more endless layers of hierachical control when a more decentralized information management approach is better.

  • Re:Rain. (Score:1)

    by JAZ ( 13084 )
    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!!

  • 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. :-)
  • 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... ;^)

    --

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close