Processor Utilization Difference Between IBM AIX and Linux on Power(ibm.com)
ibm.com
Processor Utilization Difference Between IBM AIX and Linux on Power
http://www.ibm.com/developerworks/library/l-processor-utilization-difference-aix-lop-trs/index.html
4 comments
It's entirely possible back in those days that you had a tiny LPAR (VM) for your CVS data on a big pSeries box that was shared with a bunch of other resources.
On top of that, it wasn't uncommon to connect those tiny LPARs to shared storage RAID arrays with hundreds of machines on the same array, and allocate them a tiny chunk of two or three disks, and deal with all the contention there.
During that time period, I worked for a hot second at EMC, and was always fascinated to see these types of configurations - where it was very clear you could get MUCH better price/performance by buying Linux pizza boxes and connecting them to local storage - but back in those days it was not acceptable at big companies to do that.
On the flip side, those pSeries and high-end Sun boxes screamed when they were optimized for high I/O and high performance workloads. 15 years ago, and you'd see clusters of these pSeries boxes processing 400k-500k writes/second and up on Oracle and DB2. Truly impressive stuff for 2000 & 2001.
On top of that, it wasn't uncommon to connect those tiny LPARs to shared storage RAID arrays with hundreds of machines on the same array, and allocate them a tiny chunk of two or three disks, and deal with all the contention there.
During that time period, I worked for a hot second at EMC, and was always fascinated to see these types of configurations - where it was very clear you could get MUCH better price/performance by buying Linux pizza boxes and connecting them to local storage - but back in those days it was not acceptable at big companies to do that.
On the flip side, those pSeries and high-end Sun boxes screamed when they were optimized for high I/O and high performance workloads. 15 years ago, and you'd see clusters of these pSeries boxes processing 400k-500k writes/second and up on Oracle and DB2. Truly impressive stuff for 2000 & 2001.
Hm, no not really. The cvs daemon had the whole machine for itself.
Hm, bullshit. Seriously.
Seriously not bullshit.
To be fair it can be due to a crappy cvs port or related to something that cvs do that does not work well on the non-unixy memmory mapped io model on AIX.
To be fair it can be due to a crappy cvs port or related to something that cvs do that does not work well on the non-unixy memmory mapped io model on AIX.
I've used AIX since it ran on the RT. I've used CVS since a buddy said "hey...this guy has some shell scripts that work better than SCCS" (i.e. the late 80s). I've done OS performance analysis for decades. I'm quite clear on how those boxes perform. Quit doubling down on the bullshit that an unloaded 660 with server class I/O is outperformed by a mobile P3 cramming data down a laptop IDE bus. It never happened. What happened is something like what mattzito described and you just have no idea how real systems are deployed and managed.
I wonder if this may be attributable to the difference between a CPU bound versus an IO bound workload? I imagine CVS is doing a fair amount of IO, which on a laptop with local disk (and no competing workloads driving IO) may be able to handle pretty effectively.
There were no competing workload and no virtualization on the AIX either. We didn't need it (yet) for other things.
One possible effect of your email may have been that people simply did not attempt to check in their work until you had 'sorted things out'.
That way you'd have reduced load and therefore a snappier system.
That way you'd have reduced load and therefore a snappier system.
No, we stayed on the laptop. It was eventually moved from the other site to a proper server room, still with a sticky note on it. We might have forgotten to mention this fact to some people though...
So going to production for you is moving a laptop to the datacenter? Yeah. Bullshit.
What? No?
CVS is a version control system. We kept (a copy of ) the source in the laptop.
The actual system we developed was running in machines guarded by hordes of sysadmins grumped up to the proper level, possibly even employed by IBM.
CVS is a version control system. We kept (a copy of ) the source in the laptop.
The actual system we developed was running in machines guarded by hordes of sysadmins grumped up to the proper level, possibly even employed by IBM.
Once upon a time a customer asked why Linux was more efficient on the same Power hardware than AIX. IBM assigned a customer engineer to write a paper explaining this, making sure that IBM's own product looked good no matter what.
This paper may or may not mean anything else.
This paper may or may not mean anything else.
Back at my last employer when we were looking at setting a new server standard platform. I once got pulled into an all-day meeting with our IBM rep and a contingent of IBM sales guys from the Power division and another contingent of IBM Intel server guys. It was pretty comical listening to their conflicting sales pitches and the side conversations during the breaks where the IBM Power guys would bad-mouth the IBM Intel guys and vice versa when the others were out of the room.
I also had some interesting conversations with some of the Websphere product team at the IBM lab in Toronto where they told us "off the record" that we'd get better performance running Websphere Commerce Server on Linux vs AIX according to their internal tests and that they develop first for Linux and port to AIX.
I've always liked AIX and found the tools and overall experience very solid. It's just so darn expensive to scale and maintain it.
I also had some interesting conversations with some of the Websphere product team at the IBM lab in Toronto where they told us "off the record" that we'd get better performance running Websphere Commerce Server on Linux vs AIX according to their internal tests and that they develop first for Linux and port to AIX.
I've always liked AIX and found the tools and overall experience very solid. It's just so darn expensive to scale and maintain it.
...or, making sure that the customer was aware of IBM's own published documentation, linked to in the paper, which explains the difference in how CPU utilization may be calculated by AIX vs. Linux on the same hardware.
You might wish to look at the paper describing how the PURR and SPURR components of recent POWER cpus assist with process accounting.
I understand that there's going to be some inevitable Lintel chauvinism on HN, insofar as it's the most popular platform...but there may truly be other legitimate ways of doing things.
You might wish to look at the paper describing how the PURR and SPURR components of recent POWER cpus assist with process accounting.
I understand that there's going to be some inevitable Lintel chauvinism on HN, insofar as it's the most popular platform...but there may truly be other legitimate ways of doing things.
As true or not true as this may be, it's worth pointing out:
The users are highly likely to continue to measure things the wrong way, and come up with the wrong answers, until you change the way you display numbers.
Regardless of the good or bad reasons[1], telling users to stop reading the numbers and comparing them never works in practice.
[1]they say: "PURR- and SPURR- based processor utilization were introduced. This helps better in the CAPEX planning and actual performance expectation in the SMT8 mode when compared to the single-threaded mode.". I'm not sure i would ever use these numbers directly for capex planning, but okay .....
The users are highly likely to continue to measure things the wrong way, and come up with the wrong answers, until you change the way you display numbers.
Regardless of the good or bad reasons[1], telling users to stop reading the numbers and comparing them never works in practice.
[1]they say: "PURR- and SPURR- based processor utilization were introduced. This helps better in the CAPEX planning and actual performance expectation in the SMT8 mode when compared to the single-threaded mode.". I'm not sure i would ever use these numbers directly for capex planning, but okay .....
so.. a Unix operating system that IBM developed specifically for the rs6000/pseries/power8 servers runs better than Linux. shocking.. even more shocking that the article is hosted on IBM's own site to tell us so.
obviously, AIX has existed longer than Linux, so it's code maturity is better. Linux on the other hand runs on way more processors then AIX has ever existed on. with the flexibility and portability that Linux has to new processors there is going to be a processor specific performance drop.
obviously, AIX has existed longer than Linux, so it's code maturity is better. Linux on the other hand runs on way more processors then AIX has ever existed on. with the flexibility and portability that Linux has to new processors there is going to be a processor specific performance drop.
So supporting more platforms at the cost of performance is a uncontested good? Not for everyone, for every use case. AIX has it's place, just like Linux.
The linux laptop was then connected to a well used wan-connection in another location, and we tunneled to it using ssh, instead of just accessing it on the 100 mbit lan, and sent out an apologetic email notifying the developers that things would be really slow until we had sorted things out with the AIX systems. ( They had to be moved to another location.)
We found to our surprise that the throughput dramatically improved and checkout times where reduced to almost nothing compared to the AIX machine it usually ran on.
Now, maybe CVS is an exceptionally bad workload for AIX or something, but I doubt that it's an uncommon workload. AIX might possibly scale to more CPUs efficiently, but it was a clear disappointment nevertheless.