NT's Poor Scalability Performance Might Not Be Caused by an Inability to Scale
Conventional wisdom has long known that Windows NT doesn't scale as well as UNIX. Benchmark after benchmark, multiprocessor NT systems have lagged behind their multiprocessor UNIX counterparts. People have developed many theories to explain the reasons behind NT's poor multiprocessor showing against UNIX. The theories include the relative immaturity of the NT code base and the generic nature of the x86 hardware platform.
However, NT's poor scalability performance might result from the level of abstraction in the operating system (OS) rather than NT's inability to scale. "NT is at a disadvantage against UNIX because Microsoft must maintain a single binary image for a broad range of platforms," said Kitrick Sheets, the chief technical officer at MCSB Technology, maker of AutoPilot P/SA (Performance/Scalability Accelerator). In contrast, UNIX hardware vendors have more control over their particular hardware implementations and can tune the OS in ways that NT hardware vendors can't, such as modifying the memory-management and thread-scheduling functions.
This analysis could go a long way toward explaining the disappointing scalability numbers reported by vendors of early 8-way NT servers. Sheets gave the example of one vendor's Transaction Processing Council Benchmark C (TPC-C) results for its 8-way symmetric multiprocessing (SMP) system. "The vendor's problem was really hardware related. The 8-way SMP system had a memory partition scheme that separated the two processor quads, a scheme that NT wasn't aware of. Without custom tuning the NT scheduler to maintain proper processor affinity, there was no way that SMP system was going to achieve linear results." (Processor affinity is the association between a processor and a thread.)
Products such as MCBS's AutoPilot can address this problem by progressively monitoring various environmental and quantitative factors within the NT Executive. The products then dynamically tune the OS's thread-scheduling and memory-management functions to compensate for idiosyncrasies in the underlying hardware (such as those in the vendor's 8-way design).
Such approaches can help vendors get more out of NT's architecture. MCSB points to commissioned benchmarks that show significant performance improvements from better thread and processor affinity management, especially in OEM configurations. What about scaling beyond 8-way? According to Sheets, "The situation is only going to get worse as vendors try to extend NT past eight CPUs."
This MCSB executive is not alone in his assessment. Most experts agree that, as SMP systems scale beyond four processors, system bus contention becomes a major problem. Not enough bus bandwidth exists to accommodate memory activity from all the CPUs. This situation is particularly true in x86-based designs, in which the system bus often runs at less than 100MHz.
One solution is to design a faster, shorter, more efficient bus. But as Digital Equipment has discovered in its 8- and 12-way Alpha systems (which employ a true, single-bus SMP design), delivering such an implementation is expensive because it requires custom Application Specific Integrated Circuits (ASIC) and highly tolerant signaling materials.
The high cost associated with true-SMP scaling leads many analysts to believe that hybrid designs using interconnected 4-way quads are the wave of the future. In fact, such hybrid solutions are already in use at the ultra-high-end of the UNIX server market. Many technology leaders in the multiprocessing field, including Sequent Computer Systems and Data General, are basing their 16- and 32-way UNIX configurations on the radical nonuniform memory architecture (NUMA), a design that uses separate 4-way SMP system boards linked via a high-speed interconnect switch.
Microsoft has publicly voiced its opposition to NUMA-based designs, pointing to the difficulty that some companies have in adapting applications designed for SMP scaling to the disjointed, quad-based environment. Microsoft advocates the continued development of true-SMP designs and the use of clustering as alternatives to the more radical interconnect approach.
Many analysts agree, noting that Intel's forthcoming Deschutes architecture and vendors' development of high-speed, low-cost system bus architectures will help alleviate the SMP performance bottleneck. In the meantime, companies deploying current generation 8-way designs need to be aware of the architectural compromises being made in the name of reducing production costs. In the case of systems based on Intel's Corollary and similar quad-based architectures, SMP isn't always SMP. Companies might need to invest in additional software performance technologies before they can achieve near-linear scalability.
—Craig Barth
Driver Drought Threatens Mobile NT
Customers who want to use Windows NT on mobile computing platforms are finding it hard to locate supporting device drivers. Although NT supports many Microsoft and third-party devices, some advanced combo cards are still Windows 95-specific. An example is 3Com's EtherLink III LAN +33.6 Modem PC Card. A quick search of the 3Com Web site at press time failed to yield an NT 4.0-compatible driver.
Users will find little relief in the current generation of third-party mobile computing add-ons from vendors, such as Softex and SystemSoft. Once thought to be a promising option for notebook users, these products do little to address the NT driver shortage.
For example, consider the Softex PC Card Controller for NT, which requires you to use custom device drivers that are compatible with Softex's hot-swap and power-management features. Softex ships a limited set of generic drivers on the installation disks. However, these drivers address only a small subset of the myriad PC Card devices on the market.
Some customers have pointed to NT 5.0 as the ultimate solution for NT-based mobile computing. However, early experience with the NT 5.0 betas has not supported this prediction. NT 5.0's Plug and Play (PnP) support (an integral part of PC Card functionality) will require a new set of device drivers based on the Win32 Driver Model. Microsoft has made the controversial decision not to support the Advanced Power Management (APM) standard. Microsoft will instead mandate that NT 5.0-compatible notebook systems implement the newer Advanced Configuration and Power Interface (ACPI) architecture. Customers with APM-based systems, which represents the vast majority of NT-capable notebook computers, will be left out in the cold. Maybe customers still need those third-party APM and PC Card vendors after all.
—Craig Barth
Microsoft Tweaks Early Adopter and Service Pack Programs
Microsoft is expanding its Early Adopter Program and rethinking its Windows NT Service Pack program. Microsoft is revisiting these programs in an effort to have faster time-to-market cycles for new operating system (OS) releases.
The Early Adopter Program originated with the Exchange Server 5.0 beta program. The program has since been carried over to the NT 5.0 beta, with several sites already deploying the OS in a production setting. Microsoft has traditionally limited the program to a select group of its largest customers; however, the company is hinting at plans to expand the program in the near future. Under the current Early Adopter Program, Microsoft gives enterprise customers early access to key OS technologies and encourages them to deploy these releases into production environments. Microsoft then monitors the sites and works closely with the customers to isolate and correct potential problems. By exposing new products to real-world testing early in the development cycle, Microsoft gains valuable field data and the customers get to experience the new release firsthand.
In addition, Microsoft is hinting at plans to create a Service Pack team. This team would test and verify incremental NT updates to dramatically increase the speed with which Microsoft releases new Service Packs. Currently, Microsoft releases a new Service Pack, which includes various bug fixes and incremental upgrades to core NT services, every quarter. However, the latest NT Service Pack, SP4, has been delayed until the second quarter of 1998 because Microsoft redirected resources to the NT 5.0 project.
Many analysts point to the SP4 delay as justification for creating a Service Pack team. As of early March, the Microsoft's NT FTP Web site listed 29 post-SP3 hotfixes. (Hotfixes are problem-specific patches released by Microsoft to address issues that arise between Service Packs. The FTP Web site is at ftp://ftp.microsoft.com.) According to analysts, if Microsoft had had a Service Pack team in place to oversee testing, Microsoft would have likely made SP4's original target date of December 1997.
However, before customers raise their glasses to the new Service Pack team, they might want to consider just what an accelerated release schedule will mean to them in terms of support costs. Many enterprise customers already complain that Microsoft is trying to do too much with the current Service Pack program. These customers point to the number of add-ons--new features that force systems administrators to treat each new Service Pack as an OS upgrade--that have been bundled into the latest releases.
You could argue that all the add-ons in SP1 through SP4 constitute an entire point upgrade to NT. This ongoing abuse of the Service Pack concept (Service Packs were supposed to be just maintenance releases) has left customers leery of any plans to improve the program. The increasing number of Microsoft applications relying on new functionality introduced with the latest Service Pack is not helping IS planners keep up.
Perhaps Microsoft is using the wrong justification (i.e., faster time-to-market cycles) to gain support for the new Service Pack team. First, Microsoft needs to convince customers that a dedicated testing team will mean better quality Service Packs, with fewer add-ons that might disable existing systems.
—Craig Barth
Previous
