Feeds

back to article AIX 7.1 moves forward to Power7 iron

A new server lineup needs a new operating system to match it, and so next month will see the debut of AIX 7.1 from IBM. And about a month earlier than expected, too. AIX was always the laggard when it came to commercial-grade Unixes, far behind HP-UX from HP and Solaris from Sun Microsystems. And that, along with some pretty …

COMMENTS

This topic is closed for new posts.
Silver badge
Alert

@El. Reg. Don't agree!

"AIX was always the laggard when it came to commercial-grade Unixes"

You need to qualify this. When AIX 3.1 on the RS/6000 was first launced back in 1990, it wa streets ahead of any other commercial UNIX. It has a logical volume manager, an integrated system management utility (remember, this was a time when sysadm ruled the roost for most UNIXes), dynamically loadable device drivers, and was one of the first UNIXes that did a good job of merging SystemV with BSD flavours of commands and libraries (SUN's way of doing this was less transparent).

With the SP/2 in the mid 90's IBM moved AIX into high-performance computing (Deep Blue et. al)

In the late 90's, they were up there with 64 bit systems, and had a nearly seamless 32/64 bit strategy that meant that the kernel you booted did not have to match the binary you were running.

For absolutely years, AIX was the leader in the Gartner manageability surveys.

Power4 systems, available in the early 2000's implemented hardware partitioning. I'm not sure whether HP had this on the Superdome (or whatever they were called at the time), but I remember this being a real marketing differentiator at the time. Power4 also had SMT of a kind.

Power5 systems, available 2004/2005 implemented I/O virtualization, sub-cpu partitioning, and dynamic hardware allocation and de-allocation (this might have been possible on Power4, I can't remember exactly).

IBM were slow on SMP, the initial work being done by Bull with the G/J30s, but when you have systems with single CPUs running as fast as your competitors SMP boxes, what was the hurry.

The only thing that I believe that Sun had was the containers, and to tell you the truth, I never worked at a customer where this caused a problem.

So tell me. What else were IBM lagging behind their competitors.

0
0
Big Brother

re: @El. Reg. Don't agree!

Now, let me see... Let's try to do this in a tidy manner:

1. When AIX 3.1 on the RS/6000 was first launced back in 1990, it wa streets ahead of any other commercial UNIX.

---This is opinion, surely, but we are all entitled to one.

2. It has a logical volume manager,

--- So did Solaris, and if I remember correctly, so did HP-UX.

3. an integrated system management utility

--- Solaris has never really had this, while HP-UX kinda has... I would argue whether

this matters, but to each his/her own.

4. dynamically loadable device drivers

--- Solaris had this when it was released (though early Solaris non-BSD was very

painful) Of course, Sun and AT&T created SVR4 (of which Solaris is based on).

5. first UNIXes that did a good job of merging SystemV with BSD flavours of commands and libraries (SUN's way of doing this was less transparent)

--- This is just opinion. I quite like the way that Sun kept the BSD equivalent commands around.

Sun, having the Father of BSD (Bill Joy) still in house made sure that the BSD advocates

could still do their thing.

6. With the SP/2 in the mid 90's IBM moved AIX into high-performance computing (Deep Blue et. al)

--- Sun purchase the business division of Cray from SGI in 1996 and released the Starfire in

1997... The SP/2 had nothing on the Starfire, especially SMP scalability. IBM was way

behind here. Sun had ignored the high-end SMP market for too long, but then went to the

leader board in one giant leap.

7. For absolutely years, AIX was the leader in the Gartner manageability surveys.

--- Marketing... The vendors pay Gartner for these "ratings"... It's amazing how often the vendor

that funds the study is the one that comes out on top... I'd bet I could go find Sun funded

studies to say the opposite.

8. Power4 systems, available in the early 2000's implemented hardware partitioning.

--- A competitive response to Sun's success with hardware domains on the Starfire system.

Sun was already into their second generation of partitioning at this time.

9. Power4 also had SMT of a kind.

--- That's like saying that hyper-threads are SMT of a kind...

10. Power5 systems, available 2004/2005 implemented I/O virtualization, sub-cpu partitioning, and dynamic hardware allocation and de-allocation.

--- Yes, IBM passed up Sun in this regard (IMHO). IBM has never really gotten the dynamic hw

allocation thing right though. Sun made up a bit for this with Zones. Personally, I think IBM's

solution has way too much overhead, but these systems are so powerful that you can

generally overlook this.

11. IBM were slow on SMP, the initial work being done by Bull with the G/J30s, but when you have systems with single CPUs running as fast as your competitors SMP boxes, what was the hurry.

--- LOL... Tell that to IBM when they were competing with the E10000 from Sun. IBM could not

compete with anything that Sun had. Even on the single proc systems... IBM had fallen

asleep and Sun was reaping all the rewards for it. IBM was slow and could not scale. That

was the facts. You can't forget that.

12. So tell me. What else were IBM lagging behind their competitors.

--- Oh yes, one other thing. Backward compatibility. Solaris, and HP-UX to a lesser extent, have

always kept compatibility between releases. IBM has always seemed to not think this was

a priority. A recompile between versions was and in many cases is a real concern with AIX.

I'm sure I have some of my "facts" mixed up above. It's mostly from memory, so it could be off by a bit, but I don't think by much.

0
1
Silver badge
WTF?

You're timelines are wrong.

1. What were you doing in 1990. I would doubt that it was working in the UNIX field.

2. Sun did not have a logical volume manager at that time, unless you count Veritas, which was not their product Sun Disk Suite was a charged for add on that was released in 1991. Nor did HP until sometime after AIX 3.1 was launched (the HP/UX logical volume manager was derived from the code IBM contributed to OSF if I remember correctly, and added to HP/UX 9.0 in about 1992)

3. HP/UX had SAM. Hmm, not good, and not a patch on Smit.

4. I'm sorry, Solaris definitly did not have dynamically loadable AND unloadable device drivers (I'm not talking linking here, I'm talking device drivers) at this time. I was having to sysgen systems to tell it what devices were included in the Kernel. And I would ask when you think that Solaris was launched, bearing in mind that Solaris 1 was a packaging option including Sun OS 4, and was not the label for the entire OS until Solaris 2 which was SVR4 based in around 1992.

5. Sun OS was a BSD derived OS until Solaris 2 so of course it implemented BSD commands. It had a veneer of SystemV on some commands until the SVR4 initiative that was not Sun's idea (remember this). The way that you effectively chose which type of commands and environment you used was poor. You may not think this was important, but as you pointed out, this could just be an opinion.

6. I'll give you Starfire. I had forgotten about that system. As I pointed out, however, the single processor power negated some of the SMP benefits that other vendors had. But I believe that the cost per TPC was not in Sun's favor on these systems. IBM's closest system at the time was probably the S70, but they were a bit later than Starfire. S80 and p690 (regatta) closed the performance gaps.

7. OK, find them. I don't remember any, because for system management, Solaris was, and IMHO still is in the stone ages. I don't believe that Sun ever had decent hardware error handling system, and patch management appears more primitive than AIX. NFS and automount is better, granted, but even for a hardened CLI user, smit is a great fall-back when you can't remember how to do something you touch once in a blue moon. And dynamically loaded and unloaded device drivers allow you to fix a multitude of problems without needing a reboot. And all of the hot-swap hardware makes management easy.

8. Starfire again. How much were they? All IBM power4 systems were paritionable except for the very smallest.

9. Yes? IBMs SMT on Power4 implemented two separately scheduled hardware threads on a single CPU with multiple instruction units, so more like SMT than hyperthreading. The two threads were not completely symmetrical, which is why I said sort-of.

10. Yes. And dynamic LPARing does work. Very well, in fact, as do hot pluggable disks and adapters. Zones is quite different, and I will admit that WPARs were a direct copy of this functionality. I'm not 100% sure, but I am not sure how well Zones split the allocation of CPU and I/O bandwidth between the systems. LPAR overheads, mainly memory (but not CPU), are quite high granted.

11. Starfire again. And again, how much did it cost? And what was available on the smaller systems?

12. Backward compatibility. WTF. I would bet that a 32 bit executable built on AIX 3.1 on RIOS hardware in 1990 has a greater than 70% chance of still running on Power7 running AIX7 twenty years later. How much more backward compatibility do you want? And once you get to AIX 4.3 and AIX 5.1 it will be getting to more than 95% or more. And IBM make it quite clear what features are likely to prevent an application from working. Many software vendors are still compiling their code on AIX 5.1 or AIX 5.2 knowing that their software will work on all later versions of AIX (an example of this is the AIX Toolbox for Linux Compatibility from IBM, that still proclaims to be compiled on AIX 5.1).

I have VERY RARELY (in fact I can hardly remember the last time) had to recompile a program when switching AIX releases unless I wanted to take advantage of new features of a new processor or compiler.

We both obviously have our own perception of what happened and when, but I still believe that the original statement in the article was wrong.

0
1
Headmaster

Well

Hi Billl

A few minor errors/things I don't agree with, and that haven't been adressed by others.

6) Jup the Starfire was a great machine. You might say that it was too successful as the SPARC boxes of today is to much like the Starfire, they haven't evolved as fast as perhaps other designs.

I know that many today think that the real nice SMP POWER box was the p690. But the real beauty was the S80/S85 which were a pure breed SMP box'es. The latest versions had 24 Cores and 48 Threads running at the same time so they did get closer to the 64 of the 10K than people remember.

8) The partitioning on the p690 wasn't hardware partitioning, it was Logically partitioning in firmware, it is basically what have evolved into the hypervisor of the POWER7 hardware of today. But the real big jump came with POWER5 and it's hypervisor in 2004, that was quite a jump. And all to many people today still don't understand how to use it properly.

9) The first POWER machine to implement Threading was the RS64-IV which had an implementation of coarse grained multithreading, that was called HMT. Much like later SPARC-64 and Itanium Montecito.

POWER4 didn't have any multithreading, unless you choose to use the SUN term CMT, Chip MultiThreading, which basically means that you have more than one core per chip.

The fist POWER processor to implement SMT was POWER5, in POWER6 multithreading was enhanced allowing the core to issue instructions to two different threads at the same time, in POWER7 a 4 way SMT threading was added.

10) Well didn't get dynamic hardware allocation right ? Sure it's hard to wrestle memory away from a machine that wants to use it :)= But otherwise it IMHO the most dynamic platform when it comes to virtualization. You can actually turn SMT on and of on the fly, and adding and removing virtual processors, adapters etc takes seconds.

Now I think the whole virtualization adds overhead thing is a misunderstanding. If I carve my machine (be it a T5440 or a p690 or a SD using domains Lpars or n/vpars) up into slices I will loose all the idle capacity in all the partitions. When I use virtualization I get access to this, hence often this means that I get access to the 60-80% idle machine time that a Partitioned UNIX machine often has.

11) the G and specially the J series were terrible. I remember once, a place where I worked, we had a Highnode (J50) with 4 cores running as DB servers, the failover machine was a thin node PW2SC 160MHz, in a cluster test one of the UNIX guys forgot to fail back to the high node, next the day the people who used the machine complained that their queries were broken cause they finished to fast. The thin node was just much faster at single threaded workloads.

12) AIX has always been good at compability, only really issue was the 4.3->5.1 64 bit code. But that really was a non issue as nobody really used 64bit executables. Well besides Oracle.. and it was actually more a Oracle issue as they didn't provide a 64bit version of Oracle 8.1.7 that could run on AIX5.1

// jesper

0
1

Solaris' binary compatiblity was the Gold Standard

Sun went through so much pain with the Motorola to SPARC transition, and then even more so with the SunOS 4 BSD to Solaris 2 SVR4 transition, there was a "Never Again" declared within Sun's Solaris group. This is what led first to Sun's famous Solaris Application Guarantee, which was actually imitated (the sincerest form of flattery) by IBM a few years ago.

Solaris binary compatibility was so good even drivers worked across versions. Customers got so conditioned to things just working some were quite upset when they found their 32-bit Solaris 2.2 Adaptec SCSI card driver would not work with the 64-bit Solaris 7 kernel. That was a driver bit incompatibility, as the same driver worked fine if one booted the 32-bit Solaris 7 kernel.

IBM had a big problem when they went from the 64-bit version of AIX 4.3 to AIX 5.1. These two versions of AIX were completely incompatible, and it meant for example, you could not move your Oracle 8i database running on an p680 on AIX 4.3 over to a p690 on AIX 5.1 without also moving from Oracle 8i to Oracle 9i. That fiasco is what caused IBM to get its act together on compatibility.

IBM has cleared innovated tremendously in AIX over the last decade, but they have also copied madly from Sun. Those less transparent Solaris commands? Now available on AIX. Containers ... er, Workload Partitions? Now available on AIX. Branded Containers (i.e., Solaris 8 and Solaris 9 compatible containers in Solaris 10), now available on AIX.

1
0
Silver badge

64 bit (in)compatibility with AIX 5.1

I was going to enter a long, essay type reply to this when I realised that it wasn't worth it.

I was caught by the Oracle 8i to 9i problem (but on Winterhawk SP/2 nodes, not p690's), but I reckoned that this revolved around the lock kernel extension (read device driver) that Oracle added to AIX. There was an IBM documented incompatibility here.

Being a cynic, I always thought that this was just a ploy to make customers pay an upgrade charge to Oracle, rather than a real issue with AIX. It would not surprise me if it were perfectly possible for Oracle to have issued a patch for 8i, but this would have had little financial advantage for them.

IBM issued guidance that said that the kernel extension interface was changing, but this sounds very similar to the Adaptec driver issue mentioned. So no real difference from Solaris there.

The rest of the code may well have worked, but would have been completely unsupportable. IBM claimed in the AIX 5.1 readme that the only reason to recompile 64 bit code was to take advantage of the new features of the new release, which is not unreasonable.

1
0

AIX 5.1 binary compatibility

There was a break in binary compatibility for 64 bit programs only when moving from AIX 4.3.3 to AIX 5.1. Although AIX 4.3.3 supported 64bit programs, it did so with a 32 bit kernel. AIX 5.1 introduced a true 64 bit kernel and one structure had to change resulting in 64 bit programs that were compiled on AIX 4.3.3 would not work on AIX 5.1. This change ONLY affected 64 bit programs.

The number of 64 bit programs were pretty small at that time but they did include Oracle 8 and SAP. Oracle 8 was at nearing it's end of life and was basically in maintenance mode, so Oracle declined to recompile Oracle 8 for AIX 5 and re-release Oracle 8 for AIX 5.1. SAP and other vendors with 64 bit programs did recompile for AIX 5.1.

This structure change in AIX 5.1 did NOT affect 32 bit program binary compatibility, so well behaved 32 bit programs from AIX 4 and AIX 3 continued to run and still do today on AIX 7.

As far as the Binary Compatibility guarantee; despite a pretty spotty history of binary compatibility for Solaris releases, Sun did have a "guarantee" and their sales people beat IBM over they head with it any chance they got. IBM responded with a similar guarantee for AIX 6 and that took all the wind out of Sun's sails on this issue.

The whole guarantee thing is pretty much all marketecture anyway since well developed programs tend to move up well to later releases of operating environments - as long as we are not talking about Java, particularly Java 1.4.2.

0
0
Troll

AIX and Oracle

".. and it meant for example, you could not move your Oracle 8i database running on an p680 on AIX 4.3 over to a p690 on AIX 5.1 without also moving from Oracle 8i to Oracle 9i. "

Yes there was a change in the 64bit execution format from 4.3.3 to 5.1 But hey it's 10 years ago, and to be honest the number of 64 bit executables back then was... well... basically Oracle. So It's not like it was a big problem.

Now the problem with Oracle version 8 was that Oracle never released a 64bit 8.1.X or even 9.0.1 for AIX 5.1. Only a 9.2 and newer. But it was no problem taking your 32bit Oracle 8.1.7 and moving it from AIX 4.3 to 5.1, as long as it was the 32 bit version of 8.1.7. I've seen lots of 8.1.7 run on AIX 5.3, I've even seen some 7.3.4 ones. It seemed that Oracle wanted IBM to force their customers that ran Oracle on POWER to do an Oracle upgrade. It's always smart to make others make money for you.

With regards to Containers, Solaris simply stole it before AIX did :)= I do think the AIX implementation where it's more or less an extension of the workload manager is nice.

Now the good thing about AIX is the fact that all the layers in the solution stack are one of the best on the marked. One component might not be the best but at least then it's second. And it's also a honest OS. It doesn't try to a lot of things, it's simply a UNIX made to run on big RISC servers.

And that is perhaps Solaris'es biggest disadvantage, that there are serious weaknesses in the stack, perhaps the biggest being Oracle. And that is a damn shame.

// jesper

1
0
This topic is closed for new posts.