Enterprise Mac | Tom Yager | July 2006

MORE ENTRIES

July 2006

July 25, 2006 | Comments: (0)

Now that eMac has been plowed under to make room for 17-inch Intel iMacs' foray into education, Apple is down to two PowerPC Macs, both targeted at the high end of Apple's market: Power Mac G5 Quad and Xserve G5. I hope you don't feel attached to either of them, because they're about to go bye-bye. The order of execution is somewhat in doubt, but my vote is that the last of the PowerPCs will be get disappeared in one ceremony. First, I'll address Xserve and its cohort, Xserve RAID.

I don't see PowerPC Xserve surviving the WWDC keynote. The WWDC program trumpets server admin sessions, and there's little point in covering that ground for a machine wasting away from design neglect. Xserve G5 was so far behind state-of-the-market last Fall that I asked Apple whether its interest in IT was waning. I now consider the matter settled in favor of IT, academia and high-performance computing.

Apple's going to hand us a Xeon 5100 Series (Woodcrest) dual socket, quad-core Xserve, keeping the Xserve name because it doesn't have "Power" in it. I expect the Intel Xserve will keep its chassis, too, because it works. The only thing I'd do is trade the front panel FireWire port for a USB 2.0 port. Inside, though, there's no part of Xserve G5 that's salvageable. The PCI-X bus, DDR memory, slow bus, single-core CPUs and complete lack of out-of-band remote management capabilities put Xserve at an insurmountable disadvantage relative to every dual-socket x86 rack server on the market, even models well below Xserve's price class. If Apple wants to keep charging comparatively elite prices for Xserve, it'll have to rewrite the box's specs from scratch. Of course, Apple started doing that the moment Xserve G5's engineering was idled, so Intel Xserve should show no signs of being hurried to market.

The Xeon 5100 Series platform (with the 5000P chipset) is nothing special out of the box compared to Intel's previous, beefy high-end server platforms. Let's say that Intel left Apple lots of room to design differentiation into Xserve, and Xserve needs it; Apple's wading into a grossly overcrowded market. One third-tier vendor/supplier, SuperMicro, rolled out 30+ server models based on Xeon 5100 Series the day the CPUs launched. $2,000 quad-core Woodcrest rackmounts are as numerous as mosquitos. Meaningful differentiation from the pack is the only way Apple can maintain Xserve's comparatively elite pricing.

Apple never admits to having unhappy customers, but I know that the #1 complaint about Xserve G5 was its lack of lights-out/out-of-band remote management. Having Xserve be completely invisible to the LAN until the OS boots and initializes fully presumes that the system will never crash, hang or fail to boot. I think Apple will spring for a baseboard management controller (BMC) that at least supports Intelligent Platform Management Interface 2.0. A BMC gives administrators emergency access to machines that won't boot or which, say, can't bring up their network links because of IP address conflicts. The BMC runs independently, so no matter what fails (other than the power supply), it'll always answer your call on the LAN or, failing that, the serial port. IPMI is almost ubiquitous in Woodcrest servers, but Apple has a strong software advantage. System makers' IPMI tools are generally so clunky that the feature goes unused. Apple can bake a bit of fresh Java for its GUI remote server administration tools and crawl through the basement window of any Xserve. Ditto for Remote Desktop.

As for networking, I'm about 90 percent confident that Xserve will have at least one 10 GbE copper port on board. 10 GbE switches are expensive right now, $600-$900 per port according to InfoWorld storage guru Mario Apicella. But copper (as opposed to fiber) controller chips are quite affordable. Switch prices are plummeting--the cost was over $10,000/port not long ago--and thinking back on 802.11g (Airport Extreme) and gigabit Ethernet, Apple likes to be out in front with network standards. I'm 100 percent certain of Apple-branded 10 GbE cards for Apple's servers and workstations.

Xserve's server-attached storage will be SATA 2. If Apple doesn't make the drive trays compatible with Xserve G5, it'll have some explaining to do. SATA 2 is backward-compatible with the original SATA used in Xserve G5.

The Xserve applause bait will be Steve's demo of Windows 2003 Server hosted under OS X. He will do the same with Vista when he gets to the workstation, but I hope he does Xserve first. I will attest that it works perfectly on my MacBook Pro. Parallels has an Enterprise Edition coming before the end of the year, and I believe it'll guest 64-bit OSes on 64-bit hosts. Whether Apple wants to celebrate it or not, Windows and Linux will run as well-contained, user mode guests of Apple's server OS. I think Apple will make a fuss about it at WWDC.

What of Xserve RAID? Can Apple leave it alone and just bump up its capacity as drives get denser? Here again, not if it wants to maintain its current price level. Now that 300 MB/second SATA 2 is available, the 133 MB/second parallel ATA used in the current Xserve RAID is outclassed, and PATA components will eventually get scarce. I'm about 95 percent sure that SATA 2 will be the drive bus of choice for Xserve RAID.

My 90 percent prediction is that the network transfer interface to Xserve RAID will get upgraded to 10 GbE iSCSI. iSCSI is SCSI over IP, which makes an Ethernet-connected storage device look like it's hanging from a plain old SCSI controller. Administrators will appreciate being able to plug Xserve RAID into their 10 gigabit switches. I haven't verified this, but I'm told that organizations that can't afford 10 GbE switches can go port-to-port (server direct to Xserve RAID with no switch) using copper cable. The only question in my mind is how many 10 GbE ports they'll put on Xserve RAID, because Ethernet trunks beautifully: You can bind multiple physical interfaces into one much faster logical interface, and you can keep going until you run out of either ports or cables. Apple could do Xserve RAID with fiber 10 GbE, but Mario tells me that over the short runs common to server rooms, there's no substantial performance difference between copper and fiber. If Apple requires that Xserve RAID customers go out and buy 10 GbE fiber switches ($$$$), it'll find Xserve RAID a hard sell. Those who can afford 10GbE fiber switches won't be shopping for sub-$15,000 storage arrays.

I predict 60 percent probability that Apple will license the code from ADIC that allows Xsan to host non-HFS (e.g. Windows, Linux) filesystems. ADIC sells it separately, but practically nobody, even inside ADIC, knows about it or can figure out how to buy it. As a result, the market for Xsan is much smaller than it could be given the quality of the solution.

Just for fun, a couple of parting long shots: It'd be fun if Apple offered a tiny removable external hard drive for Mac clients, based on 2.5-inch, 1.8 or 1-inch drives that are planted into drive cartridges. My desire for this was born when I tried to squeeze Final Cut Express HD and Garage Band with all of the Jam Packs together on one 100 GB MacBook Pro drive. "Jam Pack" indeed. I'd also like to see Apple sell OS X Server for non-Mac x86 servers. With Windows and commercial Linux as alternatives, I'd pay $999 for an unlimited OS X Server license in a bllink, and I wouldn't be in this dinky minority of people who know how powerful Apple's server software is. Lock the thing down with a USB dongle; server customers won't complain about that any more than Pro Apps users do. Apple, go after the seats. Your client OS isn't worth the trouble of trying to protect for use on non-Macs, but Server can be protected and it is worth it. Installed base is everything.

Thanks for hanging in with this long post. More soon.

Posted by Tom Yager on July 25, 2006 04:20 PM

July 11, 2006 | Comments: (0)

What is this Windows of which you speak?

Forget Vista. Everyone else has. Windows XP 64-bit and Windows 2003 Server R2 64-bit will be the foils for Leopard and Leopard Server, and at a core level. Microsoft is frankly in good shape. It has assembled a quorum of 64-bit device drivers and is up to speed with install-time support for most AMD and Intel 64-bit x86 CPUs, and for homegrown and 3rd-party chipsets. ISVs (independent software vendors) are slow to climb aboard, as they always are, but all key hardware vendors have bought in and those all-important grassroots users are on board. Leopard will enter a market where Microsoft has an established 64-bit installed base regardless of Vista's status.

That Leopard will land in the middle of a substantial installed base of 64-bit Windows seats is actually a boon to Apple, because it doesn't have to waste days and dollars to educate buyers on the basic virtues of 64-bitness and virtualization and just-in-time compilation and other things Leopardian. Instead, Apple can do what it's always done: Take for granted that prospective buyers have sufficient knowledge of Windows and PCs. With one magical line of ad copy, Apple can assert, convincingly, that since Tiger already bests XP and Vista and rivals Win2K3 Server, Leopard being the better of Tiger leaves Windows well behind.

Apple has established a brilliant new marketing strategy: Apple only needs to compete with its own prior best. Flat lack of mention of competing x86 systems relieves Apple of the burden of competing for hardware mind share with Dell, IBM, HP and such. AMD learned that it's nearly impossible to market against a competitor that won't even acknowledge your existence.

And Apple's got another trick up its sleeve...

Posted by Tom Yager on July 11, 2006 08:12 AM

July 08, 2006 | Comments: (0)

Power Mac G5 Quad now, or something that runs Windows later?

A commenter writes:

Thanks Tom for making a serious case for Mac in the enterprise. You do an awesome job. The Quad sounds very interesting as far as capability for semi-server configuration and high-end users. However I wonder what applications in the Mac world would really take advantage of it and who would use it.

Thank you (all) for making this such a successful and enjoyable effort.

With regard to applications for a Mac client with big guns, they are too numerous to recite. I can name a few categories typified by an insatiable hunger for greater firepower: Video and audio, photography, high-resolution graphics, advertising and publishing, Web design, animation, 3-D rendering, scientific visualization, medical imaging, modeling, film editing, compositing, simulation and biosciences, for starters. More mainstream applications include commercial software development, grid and service-oriented architectures, database management, CRM, J2EE app design and deployment, and generally anything one would do with Linux or Solaris, but which one would rather do using a consistent, simple and productive user/admin environment.

I switched over two years ago and I am still "wowed" and do not need any convincing, however with the introduction of Universal and being able to run Windows in parallel, I wonder what is the place for a Quad G5 in the enterprise. I also wonder why IBM and Motorola didn't push the development further before Apple turned away.

Windows on a Mac comes down to convenience, not necessity, when running Windows is a slow and expensive pain in the neck. Now that Windows is cheap and easy to run on a Mac, we feel compelled to use it even though our actual need for Windows is no greater than before.

Quad runs no risk of being eclipsed by its replacement. Software optimized for G5 will have a solid performance edge over the more conservatively-optimized, 32-bit x86 Mac apps that will prevail for some time to come. On specs, Quad has less in common with other Macs than it has with expensive, late-model 64-bit Intel and AMD dual core/dual socket workstations. Next year, Quad will be no one's idea of last year's model.

As for Freescale/Motorola and IBM, my speculation is that Freescale begged to get fired by missing one delivery target after another for its much-hyped 8641D dual-core PowerPC. IBM ended up being the baby thrown out with the bath water. I imagine that there was a faction at Apple that did not root for Intel in Apple's high-end systems, and I see Power Mac G5 Quad, shipped well after the Intel decision was made public, as their parting shot.

Intel would have crawled over broken glass to snatch Apple's first workstation away from IBM. It's all speculation, but just the same, praises be to whomever shielded us from a Netburst Xeon Mac workstation and server.

Another point I mentioned before is why Intel with its poorly planned shared resources when AMD would have made a better performant?

Very few Mac users think about busses and on-chip memory controllers and glueless interconnects. That suits me, because that's what I get paid to do. I trust that Apple's engineers will make the most of the suppliers the company selects, and I know that Mac users will follow wherever Apple's software goes. One thing's certain: Any Intel CPU chosen by Apple will be showcased best in the Mac, and that's putting it politely.

Posted by Tom Yager on July 8, 2006 06:09 PM

July 08, 2006 | Comments: (0)

Heirs to the G5 throne: First, learn to tell Core from Core

200606271331 You've seen that Intel is now delivering its new desktop and server/workstation CPUs based on the Core Microarchitecture. "Hey", you say, "Core Microarchitecture...I know that one! That's what Apple's been using to build Intel-based Macs." If that's you, you won't be moving on to our lightning round, but don't fret: you have lots of company. Despite their deceptively similar names, Core Duo (and Core Solo, a.k.a. Tiny Tim) are not built on the Core Microarchitecture. Core Duo is a modified 32-bit Pentium-M, with the primary modifications being two discrete CPUs on one physical package, 3rd-generation streaming SIMD instructions, shared Level 2 cache and virtualization technology (VT). That reads like an overhaul, but the base architecture--execution units, pipelines, registers, level 1 cache and so on--hasn't changed. Core Duo/Solo's cores match those of the Pentium-M. Only Core Microarchtecture, hereafter known simply as Core, has the new Core Microarchitecture core.

All of this coring around would be funny if weren't actually as confusing as I've portrayed it.

200606271348 For sanity's sake, I'll offer a a couple of tricks that may help you distinguish among Intel CPU types as used in Macs and other PCs. For starters, here's my ranking of Intel's popular shipping CPUs in order of increasing desirability, balancing power consumption, system cost and performance: Celeron, Pentium-M, Core Solo, Pentium 4, Core Duo, Netburst Xeon, Core 2 Duo, Dual-Core Xeon Processor 5100 Series (Woodcrest). I've left off specialty parts like Pentium 4 EE, and you know what the italics in the first sentence are for.

But I think the easiest way to distinguish Core Duo and Solo from Core Microarchitecture is this: Core Microarchitecture is a 64-bit design, Core Duo/Solo is 32-bit. That's not all there is to it, nor is it necessarily the bit that matters most to the broad population of users. Still, I'd like to see Apple use this fact to cut through Core confusion the way it did so effectively with G5. G5 was a wicked chip compared to G4, and Apple bragged about its bus and cache and all, but G5 and 64 shared top billing.

The larger 64-bit Mac issue is one I'm about to tackle. But since Apple hasn't taken to applying its own branding to Intel's CPUs as it did to PowerPC, I'd like to see them do something simple with model names for the purpose of making sure that customers know what they're buying. I'd put "64" in the model names of systems that have 32 and 64-bit implementations, i.e., "iMac 64." There's no need to distinguish the workstation and server. They're 64-bit machines by convention and by competitive necessity.

To re-tease my upcoming post on the subject, Apple has no genuine precedent for a 32 to 64-bit transition. Leopard will be a whole new ball game in that regard, and it's going to rattle the rafters among Mac buyers and developers.

Posted by Tom Yager on July 8, 2006 07:15 AM

July 05, 2006 | Comments: (0)

Answer: Running Core Duo with one core is no help

It turns out I'm pretty good at predicting what I'm going to write the next day.

After a full charge-to-discharge cycle running a 2.16 GHz MacBook Pro with a single core, battery life was not extended. In fact, even though it's difficult to verify, running with one core seemed to drain the battery faster. I have a perfectly rational explanation for this phenomenon, but right this second, I can't bring it to mind. I had it yesterday. Maybe the dog ate it. Don't you hate it when that happens?

I'll remember it, but in the meantime, you can come up with an explanation, post it here as a comment, and tell everyone that I never knew what I was talking about in the first place.

Posted by Tom Yager on July 5, 2006 02:07 PM

July 04, 2006 | Comments: (0)

Does powering down a Core Duo core help power consumption?

In a comment to MacBook Pro in single-core mode, x86 power management, a reader says:

The real question is how much more runtime (regardless of what the battery meter says) can a dual core MacBook or MacBook Pro obtain in single core mode?

If shutting down one core on my 2.0GHz MacBook will give me an extra hour of battery life, heck even an additional 30 minutes, it would be a great tool for times when processing power isn't all that important.

When I wrote the referenced entry back in March, running with a single core made the machine unstable during sleep/wake cycles. I wasn't able to do a true dawn-to-dusk test. But now that I've got the latest OS and firmware, the commenter made me wonder whether testing now would reveal a difference. On average, I go through two full charge cycles during workdays when I'm not in my office and working on the Power Mac G5 Quad. So I'll do the test tomorrow.

I'm guessing that it won't make a huge difference in battery running time. The entire shared Level 2 cache keeps burning when one of Core Duo's cores is shut down, and cache is a big factor in power consumption. That, incidentally, is one key to my dislike of Intel's shared cache.

Like Intel's shared bus, shared cache is not used because it's the smarter approach. It's a design expedient, and, I think, one that will haunt Intel down the road. Traditional partitioned cache allows core and cache to power up and down independently. With multiple cores writing to the full range of addresses in Level 2 cache, you can never power down one core's portion of cache.

If Intel sticks with shared cache into four-core designs, we might have a full 8 MB of clock-speed cache glowing away even when one or more cores are deactivated. While Intel is digging ever deeper into fine-grained power control, AMD will show the greater savings of better coarse-grained control, where entire "city blocks" of circuitry power down while idling or explicitly shut down. AMD's process cross-licensing with IBM will eclipse--sooner than you think--Intel's work on power efficiency.

I'll keep you posted.

Posted by Tom Yager on July 4, 2006 09:28 PM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert