June 25, 2008 | Comments: (0)
RTFM: Good advice in troubled times
Don't search for answers. Reach for knowledge.
Back when five bucks' worth of dinosaur squeezings bought you a misspent weekend, working in technology required desks, and the reason for desks was to have a place to lay out your manuals. Massive hole-punched tomes ending in "Guide" and "Reference" were techies' bread and butter. It was so taken for granted that you had manuals that RTM (we'll go F-less now that we know what we're talking about) became shorthand for "go look it up; you might learn something by accident."
Sounds haughty, doesn't it? It often was. RTM was a blow-off when uttered by wizards and gurus who had no penchant for teaching. These snobs missed out, because nothing tops the feeling of accomplishment shared with someone you've mentored, and that road has to start in a book. I'd loan them the book and tell them where to start. I knew that anyone who borrowed the book would show up shortly with their own copy and a fire in their eyes.
Glancing over at my bookshelf now brings to mind the delivery of a System V UNIX from a company called SCO. The box was bigger than the company, and infinitely more durable. Hauling an x86 operating system (not a system, mind you) indoors on a dolly is a notion foreign to most InfoWorld readers. But I owe those cheap cardboard three ring binders, and many more like them, a hefty hunk of my lifetime earnings, and the stirring of passions that keep me in this field even now. Something about having a sagging shelf full of books stare you down every time you sit at your desk tasks you to learn. No matter how smart you get, there's always a page in there you haven't read, and on each page of consequence, there is a detail or source of inspiration that you've missed.
You can go into a manual looking for an answer, and come out with knowledge. These days we so easily confuse the two, and it shows. Using software for illustration, we can all agree that they don't write it like they used to. The reason is that developers don't allow themselves the time to look things up before they use them. Statement completion, context-sensitive help, generated code, unit testing, and automated analysis came about expressly to eliminate research and experimentation from the development cycle. The result, I think, speaks for itself. How many rookie coding blunders that lead to security vulnerabilities grow out of inadequately understood usage of a method or resource?
My affection for paper manuals is not rooted in eco-insensitivity, although I do believe that a felled tree is a fair trade for a filled brain, and probably the path to that end with the smallest carbon footprint. However, a MacBook Air can carry the equivalent of several Banker's Boxes full of manuals. Is there something magical about paper?
It dates me to say so, but there is magic in paper. The simplest example I can think of is the difference between leafing through a book and scrolling through a PDF file. When you're aimlessly flipping through the pages of a printed manual, your eye captures information faster than your brain processes it. You end up going back to material that you flipped past and saw only for a fraction of a second, but which your brain registered as a subject of interest. I don't get that from PDFs except where the flow is disrupted by a chapter title or illustration. Even with framing and shadows to simulate dimension, it takes a lot of practice to train your mind into seeing a GUI window as an object that it should snapshot and analyze as a unit. You've got an advantage if a computer was the most common vehicle for visual communication when you learned to read.
Here's where you expect me to say that I print the manual. No. MacBook Air is the right home for my manuals. These days, when I go looking in a PDF manual for an answer, I read the whole thing. By doing this, I am training myself to snapshot and scan scrolling PDF pages as they fly past. It isn't the medium that makes RTM good advice. It's the approach. Don't go to documentation looking for answers. Go looking for knowledge, and the answers will come along for the ride.
Posted by Tom Yager on June 25, 2008 03:00 AM
May 21, 2008 | Comments: (0)
AMD's server roadmap burns through Intel's fog
Intel CEO Paul Otellini's memorable "shame on us... mea culpa, we screwed up" March 2007 speech to Morgan Stanley investors came after his company's marketing fog machine could no longer conceal the truth that, depending on your point of view, Intel was peddling technology that it knew to be somewhere between four and eight years behind AMD's. AMD told you so, and so did I, but Intel's marketing is capable of overpowering reason. Intel manages to thrive by setting expectations that match its technology, and raising those expectations every two years by just enough to make you see your Intel-based PC or server as wanting. Otellini got stuck apologizing because AMD got a chance to show buyers Opteron's potential. The market's expectations followed, as they naturally will when people buy technology that never needs replacing. Given the choice between buying well and buying often, the market chose the former.
Intel's smokescreen is back in overdrive. Those who do a light amount of homework before buying are getting Intel's same old message: Higher clock speeds, bigger cache, manufacturing process shrink, and faster front-side bus make the world go 'round. That latest speed bump makes your one year old computer look pretty sad (on paper). And when Intel goes "tock," it's rip and replace time to get those extra cores and the broader bus. Intel put the cherry on top by getting everyone worked up over CPU power draw to the exclusion of total system power draw. Intel sets the market's agenda. It tells buyers what matters.
AMD designs technology that will enable the workloads that you'll be running in two or three years. It strikes many as improbable when I tell them that AMD-based hardware, servers in particular, get faster over time as operating systems and application developers start unlocking the potential of the platform. When I say this, I may not take enough care to point out that AMD is committed to raising that potential between major revisions of its CPUs and whole system platforms. Intel can't catch up because AMD presents a moving target with meaningful point enhancements between major architecture revisions. AMD ticks and tocks as well, but it's the market that swings AMD's pendulum.
AMD is getting bolder about letting the market, in this case, IT, know that even through the gathering fog, AMD has a clear picture of what matters most to system buyers. You don't hear much about it these days, but price/performance matters. AMD's record-making results with Quad-Core Opteron on SPECweb2005 sets a realistic bar for server performance, a record that, notably, Intel misses by a hair. But Quad-Core Opteron comes in 41 percent lower in cost than quad-core Intel Xeon in two-socket servers. AMD servers cost less to build. Whether these savings will be passed on to you as a lower total system price is up to the OEM and its tendency to maintain artificial price parity between its similar Intel and AMD offerings. Not that I'm suggesting there's any pressure to do that.
AMD's not handing performance per watt to Intel. AMD's published benchmarks show quad-core AMD systems skunking Intel Core 2 Xeon on floating point synthetic benchmarks, by margins of between 13 and 50 percent, but quad-core Opteron lags Core 2 Xeon's integer performance by an impressive margin. Intel's butt-kicking compiler scored quad-core Xeon an earnest 20 percent lead over Quad-Core Opteron on SPECint_rate2006 (peak). The best AMD-targeted compiler from Portland Group couldn't close the gap. But interestingly, when the playing field was leveled a bit by using the gcc open source compilers, AMD pulled to within 9 percent of Core 2 Xeon on SPECint_rate2006 (base). The likelihood that you'll encounter architecture-optimized applications in the wild is mighty slim, but AMD gets candor points for showing this shortcoming of its own making. If AMD cares about closing the integer benchmark gap, AMD needs to contribute benchmark-winning optimizations to GNU.
AMD counters the gearhead-level speeds and feeds derived from synthetic benchmarks with IT-relevant load metrics. In Web transactions, virtualization, and parallel workloads, Quad-Core Opteron outperforms quad-core Xeon by margins of 9 to 16 percent. But there's a point worth noting: AMD scored these wins with a 2.3GHz CPU and 2MB of Level 3 cache. Intel lost out to AMD with quad-core Xeon CPUs running at 2.83GHz with 12MB of cache. The configuration differences between the two architectures give AMD what you call headroom. AMD is holding manufacturing process shrink, CPU clock speed, bigger cache, and additional cores as cards to play on IT's behalf when the time is right.
The time is right. Later this year, AMD will roll out "Shanghai," a Quad-Core Opteron built on a new 45 nanometer process, matching Intel's in scale while using a simpler method. Shanghai raises the ceiling on CPU clock speed to a level that AMD didn't disclose, and lowers power at idle by 20 percent. That's a ridiculous metric for a two-socket server, but in an eight-socket server, the likelihood that a socket will be idle is higher. AMD surprised me by borrowing a page from Intel's playbook, doubling its Level 3 CPU cache to 6MB. That will make a serious difference in the performance of applications optimized for Intel CPUs.
I was particularly struck by AMD's claim that Shanghai would deliver 25 percent faster times for world switch (switching from one guest OS instance to another) than the present Quad-Core Opteron. This, combined with a 10 percent boost in memory bandwidth, will give AMD a leg up in virtualization.
Shanghai marks the server debut of the coherent HyperTransport 3 (cHT3) bus. cHT3 is faster and more scalable than the HyperTransport 1 bus implemented in present Quad-Core Opteron servers, which probably contributes to reduced world switch time and increased memory bandwidth, both measures that are sensitive to the speed of the interconnects among CPUs.
The Shanghai CPU, which AMD projects will be available this year, will be a drop-in replacement for Quad-Core Opteron. Given where the economy is likely to be when Shanghai shows up, chip swap-upgradeable servers are a really smart investment.
I've saved the best part for last. If AMD hewed to Intel's "tick tock" strategy, which dictates a substantial architecture revision (tock) every other year, then with Shanghai, 2008 will certainly go down as an AMD "tock." In 2009, an architecture revision code-named "Istanbul" will carry AMD's 45 nanometer Opteron to six cores. In 2010, AMD will knock Intel's tocks off: A 12-core large scale enterprise CPU named "Magny-Cours" is slated for the first half of that year, and will deliver on AMD's big iron availability and reliability strategy. A 6-core edition of this CPU, "Sao Paolo," will roll out at the same time. I'm setting up a separate briefing for these parts, because believe me, they're game changers.
AMD is always cautious about projecting too far ahead, fearing that system buyers might suspect Intel-like obsolescence by design. AMD is smart to come out swinging by laying out present and future technology despite the risk, but amid the excitement over architectures to come, the value of AMD's long-term commitment to buyers can't be set aside. The Quad-Core Opteron server you buy today will upgrade to Six-Core, and even when 2010 comes around, 2008's Quad-Core Opteron servers will remain state of the art relative to Intel. New systems based on that platform will still be sold, and parts will remain plentiful. Isn't it nice to see clearly again?
Posted by Tom Yager on May 21, 2008 03:00 AM
May 07, 2008 | Comments: (0)
The Green Delay: A timely proposal for IT energy conservation
"I hope I'm dead before I'm 50." This was said in an entirely unemotional, matter-of-fact fashion by someone who had gotten a poorly timed, age-appropriate, red state public school treatment of both sides of the global warming debate. Is it, as was presented, more likely that natural cycles and the law of averages are to blame for melting glaciers and freakish weather? Either way, his lesson came one day before the horror in Myanmar. It awakened memories of Thailand and New Orleans. It put a different timbre to the voices decrying $120-per-barrel oil when the solution that seems so obvious to a kid--if you can't afford it, don't buy it--isn't on the table.
This young man knows me, and he knows that I take as a point of pride that InfoWorld is uniquely outspoken on matters of green computing, and that my dedication to that cause predates InfoWorld's. When I write about it, I stay away from suggesting that there is any sort of "save the planet" global imperative that should drive IT toward consolidation and the purchase of more energy-efficient equipment. By pursuing energy-conscious policies, what a company conserves is capital. As energy prices inevitably rise, kilowatts, BTUs, and square feet rise above nickel-and-dime concerns. I reach out to the pragmatists with the message that conservation makes fiscal sense. I don't mind sneaking my agenda through the side door.
Journalists must always be aware of the cost of taking sides on a controversial issue, ever conscious of the fact that doing so alienates a portion of one's audience. I can't write for those who see conservation as a purely fiscal issue, because that encourages offsetting the impact of a lazy approach to energy conservation with reductions in head count, withdrawal of community projects, raising the prices of products and services, or targeting a narrower, more elite market that can afford to underwrite energy waste as a cost of doing business.
Frankly, the trouble with dressing my energy agenda in a suit of pragmatism is that it isn't getting the message across. While I'm preaching consolidation as a means of reducing energy costs, too much of IT, and too many of the server vendors who supply it, use that call to justify overconfiguration. A four-socket, 16-core rack server with a pair of 1-kilowatt power supplies can do the job of two eight-core servers with a pair of 700-watt power supplies. The trouble is, those eight-core servers are only a year old. Buying a bigger, hotter server isn't about consolidation; those eight-core servers aren't taken off-line. The new server is added to the pool of virtual machines that are ready for duty at a millisecond's notice. We may ride into the purchase of higher-density servers under the flag of consolidation, but we typically skip the second half of that exercise that involves turning off the machines we intended to replace.
It's not helping.
It's tempting to push conservation off on the big, heartless companies that are least likely to do it, but like all social change, this one needs a grassroots kick, and I have an idea. I call it the "green delay." Customers that hit your Web site, along with internal users that poll for e-mail every 10 to 30 seconds, demand near-instantaneous responses to their requests. When a Web site takes more than 7 seconds to be ready for interaction, it's said that a great many users will go elsewhere rather than wait the few additional seconds it might take to put up clickable buttons. Sure, time is money, but when did we start calculating the value of our time in increments of seconds or even milliseconds?
I think it's time to consider the flip side of the time/money equation: Time is carbon. Our impatience with technology isn't about money, and on the scale of seconds or milliseconds, is not justifiable as business necessity or competitive advantage. Whoever I am, whoever you are, we are the people who need our data right away. We need file shares to mount instantly. Our SQL query tables must populate instantly so that we can start scrolling through 500 results a few seconds sooner. Let someone else who doesn't pay as much for a particular service or technology do the waiting. The cell network is plugged up with all those consumer voice calls, and my IM and BlackBerry messages, and my mobile browser sessions, aren't going through fast enough to suit me.
I realize that for a guilt trip to work, it needs to be more concrete and specific. I have a specific proposal, a painless one that actually addresses two problems at once. Outside first-shift business hours, e-mail servers don't need to offer a quick response. E-mail protocols were designed to accommodate multihop modem links between sites and batch transfers scheduled several hours apart. In other words, the worldwide network of e-mail servers is already optimized for green operation. Let's take advantage of that. Instead of treating e-mail like instant messages when recipients can't possibly read them, let there be latency.
Figure out how few physical servers need to be online outside business hours to ensure that messages from other time zones are received by the start of the next business day. It's OK for e-mail connections to time out because fewer servers are on a hair trigger to answer SMTP connection requests. E-mail transfer protocols require that servers keep attempting delivery, not for seconds or hours, but for days. The beauty is, your users won't notice. You can crank e-mail capacity up again when your people are back on the job.
If you make e-mail wait, you gain another benefit. Spammers have zero patience. When a chunk of spam doesn't get to you on the first try, it moves on to a more eager target. E-mail-enabled attacks, like dictionary scans of user names, require fast response to each attempt. Wouldn't it be great if, by IT adopting a more ecologically sound approach, more spammers slammed into our drawbridges?
There I go again, presenting a pragmatic angle on social responsibility. I can't make this one too easy. The important part of any IT conservation effort is to set the goal of powering servers down as often as, and for as long as, possible. It's nice that a server with a 1,000-watt power supply can idle at 300 watts. A server should idle at zero watts, and it can. Modern servers will power down and back up on preset schedules. Intelligent power controllers, like iBootBar from DataProbe, can control system power via script, telnet, modem, and browser interfaces so that servers that need help can power up other servers on the LAN.
The point is, every second spent waiting for a message or a Web site can make a difference. Time really is valuable. We can't take for granted that we have an unlimited supply of it regardless of our actions.
Posted by Tom Yager on May 7, 2008 10:06 AM
October 09, 2007 | Comments: (0)
Sun's T-2 (Niagara 2) servers launch to an enthusiastic reception
In the high end of the server industry, where UNIX holds sway and demanding applications go for configurable firepower, Sun has struck a blow with two deceptively powerful servers that, of all things, pack all of their mutlthreaded into rack and blade options.
Sun's T5120 and T5220 servers, based on Sun's UltraSPARC T2, and, remarkable, single-socket servers.This doesn't place them in the bargain class, though, because at clock speeds below 2 GHz, T2 servers and blades are sweeping award-winning performance even against a few of Sun's own high-performance rivals. According to Sun, a T6320 server blade creates a physically-extensible solution of unrivaled speed, consolidation density and power efficiency. It its' boasts are to be believed, then UltraSPARC outperforms competing blades by up to 40 percent, while saving more than 30 percent in power utilization.
Sun's magic with UltraSPARC T2 is Chip MultiThreading (CMT), allowing a single-socket server or blade to outperform competing solutions, even scoring a win in SPEC''s demanding floating point benchmarks.
Specific pricing wasn't available at the time of the pre-briefng, but it is expected to be roughly in line with UltraSPARC T1 systems. Ballparking, a spokesman offered "$9,999 and up."
Sun's servers run Solaris UNIX and Linux, while the new Sun Management Center 4.0 manages servers and virtualization containers across servers. With SMC 4.0 and a new installer in Solaris, Sun boasts a tenfold decrease in typical deployment time.
Posted by Tom Yager on October 9, 2007 12:06 AM
September 10, 2007 | Comments: (0)
For the past year, I've been immersed in research on server microprocessor and system architectures. There have been genuine breakthroughs on so many fronts. IBM's POWER6 is built around 4.7 GHz processor cores that outpace the latest Itanium in single-core performance, while advancing POWER simultaneously toward power efficiency and mainframe functionality. POWER6 is able to adjust the power utilization of CPU and core sub-components with each clock cycle, and it does so based on its own analysis of computing and I/O load rather than the operating system's. Sun's UltraSPARC T2 proves that by focusing on total throughput, a one-socket server with a comparatively low clock speed can rival, and even outperform larger, more costly, more power hungry servers. IBM and Sun put the lie to notions about RISC having run its course.
I've never seen as much new, exciting and remarkable technology emerge from microprocessor chipmakers as I've seen in the past twelve months. I've never seen computing's goalposts moved so far in such a short span of time.
For most of a year, I've also been deep in learning about AMD's new server CPU architecture, Barcelona, which makes its debut today, 9/10/07, as quad-core Opteron. I've experienced Barcelona as PowerPoint decks, block diagrams, chip masks, and discussions with AMD's CTO, engineers and Fellows. Those technical discussions weren't accompanied by remarks about Intel. AMD was bearing down on AMD's best to date. I believe that I have as deep a conceptual understanding of Barcelona as any non-engineer outside AMD, and the more I learned, the more convinced I was that I was looking at a mind-blowing architecture. Barcelona's design goals overlapped concepts executed by Sun and IBM while keeping the architecture 100 percent compatible with legacy ("standardized") x86. I developed grand expectations for Barcelona, but AMD cautioned me not to expect too much in the way of trouncing Intel in benchmarks. AMD's marketing played down the reach of Barcelona's redesign, but this didn't line up with what AMD's engineers were teaching me.
I laid my hands on Barcelona for the first time just three days ago in the form of a two-socket server with a pair of 2 GHz quad-core Opterons, model 2350. The details of that system and the results of my early testing will follow very shortly, but where Sun and IBM had me saying, "wow", "that's remarkable; who dreamed this up?" I looked at the details of Barcelona, wondering where AMD could make its mark in a field already filled with such beautiful engineering.
Now, sitting on the floor in front of Barcelona (by remote control), I am speechless. I'm running all eight cores, full-out, and watching a watt/ammeter keep a record. The evening started with an all-night burn in. During that burn-in, with all cores kicking at 100 percent, I didn't expect when I saw: 2 amps, measured at the outlet, or just 300 watts. When the workload dropped to idle the power utilization came in at 1.3 amps, or 149 watts. I continued with the testing proper, which is not yet in a state that permits me to share the results, and verified those results.
This is not a wimpily-configured box: 8 GB Registered ECC DRAM, on-CPU I/O, memory and SMP node controllers. There are two banks of RAM for each socket, and as I'll explain when I get to the results, each socket's shared third-level cache turned out to be a major win.
After all the tech magic worked by AMD, it's the price that got my blood boiling: $389! That's desktop chip money. So AMD is blazing trails in more ways than one.
It's Barcelona day, week, month, and who knows how long after that. I'm jazzed.
Posted by Tom Yager on September 10, 2007 06:43 AM
May 29, 2007 | Comments: (0)
Microsoft is right: Developers don't need PDC '07
Microsoft axed its Fall Professional Developers Conference (PDC), and it's got the blogosphere all a-twitter with speculation about the reasons. If they accepted the reasons that Microsoft gave--developers already have access to what they'd get at PDC--there wouldn't be any controversy.
Microsoft is right: Developers don't need PDC '07, and there's a fair argument to be made that developers don't need PDCs, period. One major reason to attend PDCs past was to nab the CD packs containing preview releases of Microsoft's developer tools, OSes and Windows Server System components like SQL Server and Exchange Server. Those previews are no longer hot property. Everyone with broadband access can download pre-release Microsoft products and trialware of its shipping software.
Where PDC as a learning, networking and hobnobbing experience is concerned, Microsoft's Communities bring it all together, and you can birds-of-a-feather without making yourself presentable. You needn't be sheepish about bailing out of a lame session five minutes in, and nobody cares what's in your other browser window.
Micrsoft still throws one show worth attending. Deep knowledge of OS fundamentals, server performance scaling and system administration, which every Windows developer should have and which is harder to acquire on-line, is the domain of Tech-Ed. That's always been true. Tech-Ed '07 starts next week, but airfare is cheap, registration is still open, there are lots of hotel rooms and I'm sure you can talk your boss into it.
PDC '07's euthanasia does bring the pain to one group. PDC gives third-party vendors of Windows development tools, books and libraries a shot at a captive audience under the Microsoft big top. There are lots of non-Microsoft Windows dev shows, and banner ads and Ad Words are cheaper than booth rental. This gang, too, will get by.
The greatest disappointment voiced by developers is that they'll miss their yearly fix of Microsoft swag. Fear not; it can be replaced. Never let it be said that I don't have my finger on the pulse of the Windows enterprise developer community.
Posted by Tom Yager on May 29, 2007 12:46 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
- A Guide to Rich Internet Application (RIA) Security
