Operating Systems Functionality

Proprietary systems vendors were, for a long time, considerably ahead of open systems in the level of functionality offered by their operating systems, especially in areas like the number of processors supported in SMP versions, robustness, availability, systems administration, and so forth. But over time, UNIX systems have caught up, and offer SMP, cluster support, and constantly-improving robustness and availability. This maturation of UNIX has thus significantly reduced any functionality advantage proprietary systems may now offer over UNIX (although that very process of maturation has drastically reduced the number of extant UNIX variants). In terms of functionality, we should see the same process happening between UNIX and Windows, as Windows gathers experience.

(There areonline masters degree programs in technology that can be helpbusinesses utilize the newest systems.)

There are five useful technical areas in which one may compare operating systems. We list them here, and then subsequently discuss them at greater length.

� Scalability. As already noted, this is a measure of the ability of a system to match the dimensions of a problem it must handle

� RAS�Reliability, Availability, and Serviceability. These characteristics drive the total availability of the servers and thus their capacity to support the uses for which they were acquired.

� Distributed services and Internet support. Here, we mean the integration of the basic elements that allow operation in a distributed system (these services are, properly speaking, middleware and do not form part of the operating system). Supporting basic Internet capabilities and supporting PC clients fall into this category.

� System management. By this we mean the complete collection of facilities� mainly software�that facilitate the management of the system. One may observe these facilities evolving towards some quasiautonomous decision-taking capabilities (so that the software can react without further human input), which should lead to lower cost of ownership.

� Capacity to simultaneously support various isolated workloads. Since a server is an expensive investment, systems managers are pushed into making each server support many different independent workloads simultaneously. The process of server consolidation, which is the act of reducing the number of (generally distributed) servers deployed in an enterprise to a smaller number of (probably co-located) servers, requires this capability. The management of several workloads according to a given policy (for instance, priority given to certain applications regarding the allocation of resources) is also called workload management. A system�s capability to be partitioned into several independent system to support, in complete isolation, different workloads is another approach to server consolidation. Dynamic partitioning capability (i.e., without stopping the complete system) is a key feature.

Source of Information : Elsevier Server Architectures 2005

Operating System Market Share

The quantitative future estimates from analysts, which we use as the basis for our discussions, must of course�as with any predictions�be taken carefully. Our main goal is to use them to extract and illustrate significant market trends. To start with, consider Figure 3.6, from Gartner Group data from November 2003 and showing server market trends sorted by the operating system provided with the servers.

The strong increase in sales for Linux and Windows is obvious. It is likely that Windows�s growth will be mostly in the midrange, as the high end is the hunting ground for proprietary systems and UNIX. Netware is expected to undergo a noticeable reduction in market.

Linux�s market share is expected to grow noticeably. This OS seems to have a promising future in the domain of dedicated servers (that is, servers which support a single application).

Among the proprietary versions of UNIX, we see that AIX�s share is expected to grow while those of HP-UX and of Solaris are expected to stay stable at best. For HP-UX, the seamless transition offered to customers between HP�s PA architecture and IA-64 is a factor in reducing the erosion of HP-UX�s market share. Since HP has not announced any intention to give access to HP-UX outside OEM agreements, its market share will be strictly limited to systems developed by HP.

For Solaris, we should note that Sun has an IA-32 port. The battle between the different UNIX vendors will be interesting to watch, not least because it looks as though the players will be fighting over a shrinking field as they lose share to Linux and Windows Server 2003.

This shrink in market share is an effect of the competition that Windows and Linux are offering to UNIX systems in the low-end and midrange. The introduction of systems based on IA-64 (Itanium) is likely to relaunch the sales of UNIX on Intel platforms, in particular in midrange and high-end systems. And we should note that the various UNIX variants have had time and experience enough to reach a level of maturity and reliability that allows them to attack enterprise-critical systems, previously the domain of proprietary mainframe systems.

Windows looks set to dominate the market at the lower-cost domain, with its success in the higher end only coming with maturity. The process of maturing is, of course, much aided by the installation of a very large number of Windows systems�provided its vendor can provide the needed support and maintenance, since this exposes the system to a wide range of different situations.

Our thoughts must also encompass the �free software� phenomenon, as evidenced by Linux. Linux has the advantage of being essentially free at the point of acquisition; any problems it might have, compared to UNIX versions sold by the major manufacturers or by major software publishers will be in the level of support available. This risk is being mitigated however, as the same major manufacturers now include Linux in their catalogs and offer support and services for Linux as they do for their own systems. Independent software houses are also offering Linux support and services.

As we have emphasized before, a key element in choice of an operation system is the richness of the applications catalog associated with it. While the talk is encouraging, it remains to be seen just what the actual long term commitment of software vendors to Linux will be. While such vendors are most likely to be interested in the much larger marketplace offered them by Linux platforms, they are not likely to offer their applications in source form to the community.

For certain embedded and specialized systems, Linux has an undeniable attraction. Because such systems rarely are expected to run any extant application, but to execute some well-defined, application-specific applications, the richness of the application catalog is irrelevant. Qualifying such a system is eased by its natural closed character. The applications for such embedded systems may, themselves, be members of the world of free software� for example, the Apache web server, and the SAMBA PC file sharing package.


Market Evolution
As is often seen in the data-processing industry, a balancing effect had moved us from the centralized approach�terminals connected to mainframes� to a distributed approach, embodying minicomputers and of PCs. Unfortunately, the distributed approach, while providing more flexibility tended to give rise to inconsistencies in the company�s data and was hard to administer effectively. Now the world is swinging back towards a more centralized approach (at least as far as the management of data is concerned). �Upsizing� (or �server consolidation�) has the effect of increasing the average size of a server and concentrating a number of independent servers into a single server, whether it be a single large machine or a cluster.


Economic Considerations in the UNIX World
As in other areas, it is difficult for a systems vendor to bear the cost of development and maintenance for server-class UNIX systems if sales are weak. This leads to consolidations, concentrating the industry around ever-fewer UNIX versions. As the few remaining versions of UNIX differ, their uniqueness gives the UNIX market much of the flavor of the traditional proprietary market for high-end systems. And this, quite likely, will benefit Linux, which is not restricted at all in this manner.

Classes with accredited onlinecolleges are an option, to more effectively deal with businessevolution.

Source of Information : Elsevier Server Architectures 2005

64-Bit Architecture

The increase in size of both the data objects being operated on and physical memory and the need to hide disk and network access times by placing ever more information in the memory-based disk or network cache lead to severe pressure on the addressing ability of 32-bit processors and operating systems, which saturates at 4 GB. Some RISC processors�Alpha and PA from HP, SGI�s, MIPS, IBM�s Power, and Sun�s SPARC) support a much larger address space of 64-bits. Alpha was designed to be 64-bits right from its inception, while the others all began as 32-bit architectures and were extended later in life to 64-bits. In practice, Intel�s IA-32 architecture is limited to 32-bit addressing, although AMD has proposed a backwards-compatible extension to 64-bits. (It should be noted that, as defined, the IA-32 architecture allows addressing much more than 32-bits, but structured as 16,384 segments each of up to 4GB, but that no operating systems exist which make use of this feature). Intel�s new architecture, IA-64, is another architecture designed from inception to support 64-bit addressing. The first systems based on this architecture appeared on the market in the second half of 2001 with the Itanium processor (which had been codenamed Merced). The implementation of Itanium suffered so many delays and problems that many industry observers are of the opinion that the first commercially-attractive IA-64 implementation is Itanium�s follow-on, Itanium 2 (code-named McKinley). Systems based on, Itanium 2 appeared in the market in the second half of 2002.

Applications that can make good use of the vast address space offered by 64-bit addressing are primarily databases (particularly for decision support), with scientific applications and CAD programs also able to benefit. The advantages brought by a 64-bit architecture can be summarized as follow:

� The ability to address, per process and in virtual memory, a collection of objects representing more than 4 GB. This removes the need to manage the memory hierarchy explicitly within the application, and simplifies the ability to take advantage of the continuing increases in main memory size.

� The ability to support directly and efficiently files or filing systems whose size is greater than two to four GB.

� The ability to operate on large files placed directly in virtual memory. With a 64-bit address space, there is sufficient room for a substantial number of very large files to be placed mapped into virtual memory, where software can directly access them with load and store instructions rather than I/O operations and with the processor�s built-in address translation hardware doing all needed address translation. And, finally, the movement of data between memory and disk is handled automatically by the demand-paged virtual memory system itself.

� The ability to manage very large physical memories�larger than 4 GB. Memories of such size are principally used as cache for disk-based data; in particular, the performance of database management software depends in large part on their management of the memory hierarchy, which explains why database software generally takes responsibility for the management of disk caches. A DBMS can normally do better than a vanilla memory hierarchy manager, since the DBMS knows a lot about the data it is manipulating (whether a datum is data or index data, for example) and can act appropriately. Simply placing large amounts of (reused) data in memory provides a performance improvement, because it removes the need for the software to perform file-tomemory address mapping and also reduces I/O traffic.

It should however be noted that some 32-bit architectures (hardware and software system) can address physical memories of more than 4 GB and support file systems of more than 4 GB.

Clearly, to make full use of a 64-bit address space one needs�in addition to an appropriate processor�the necessary software: compilers, operating systems, applications. The vendors of 64-bit RISC systems (Compaq, Digital, HP, SGI, IBM, and Sun) offer such a suite. Some initiatives intended to adapt UNIX to IA-64 have fallen by the wayside. By mid 2004, Linux and Windows were the only operating systems planned for Itanium platforms and offered to system manufacturers, although there are 64-bit versions of AIX, HP-UX (available on both PA and Itanium for HP systems), Linux, Solaris, and Windows.

In the second half of 2001, IBM, with its z900 family of mainframe systems, introduced a 64-bit extension to the S/390 architecture, which had its roots in the S/360 system of the early 60s (with a 24-bit architecture). For servers, 64-bit architecture is a necessity, not a luxury. It acts as a foundation for the systems to support the changing needs of the application space and to take advantage of the opportunities offered by technology.

Source of Information : Elsevier Server Architectures 2005

Networks and Network Connections

As the Internet evolves, we can see specialization increasing in the portions of the systems providing communications support. In the mainframe era of the 1960s, communications were directly supported by the systems. This changed in the 1970s, as needs grew, and led manufacturers to produce semi-autonomous communications subsystems coupled to the main system. These were known as front-end processors, and examples include IBM�s 37xx series and Bull�s Datanet.

This trend increased with the rise of local area networks, with the emergence of a new generation of network equipment�routers, concentrators and so forth�that off-load a number of chores from the servers.

Nowadays, we do not expect a server to directly support a variety of communications interfaces, but rather to provide a number of high-bandwidth pipes that carry requests for it to operate on the data it owns.

We expect this trend to continue, especially with convergence resulting in the same network carrying voice (and video) along with data, from the point of view of provisioning sufficient physical resources as well as from the IP point of view. Forecasts suggest a continuing significant increase in data traffic, with voice traffic stagnating; thus, the effects of this convergence will likely be felt more in the telephony industry (makers of automatic telephone exchanges and switches) than in the data-processing industry.

Look for data analyst programs via Guide to OnlineSchools.com.

Increased use of multimedia will impose further demands on servers, because of the need to observe and guarantee temporal properties. This might suggest deployment of specialized realtime operating systems as well as use of special peripherals, such as disks optimized for this type of use. The industry has at its disposal a number of technologies, particularly optical, which will allow it to support demand; increasing bandwidth; reducing latency; the address space increase offered by IPv6; the concept of quality of service, and so on.

A key issue, though, is driving new uses that will themselves make use of the possibilities available and allow these technologies to be deployed.

Cisco, the world leader in networking equipment, envisages the emergence of the intelligent network, whose components are:

� Interconnection with proprietary networks like SNA, DSA or others;

� Broadcast or multicast facilities, allowing one message to be sent to many destinations

� Video services (both video conferencing and video-on-demand)

� Cache services

� Administration

� Voice-related services

� QoS (quality of service)-related services

� Security services

Looking at these a little deeper:

� Interworking with proprietary networks is a necessity while these networks exist

� Some applications would benefit from a multicast capability�one message with multiple recipients (examples of such applications include videoconferencing, updating workstation software, Internet �push� technologies, information replication, and more)

� Expect videoconferencing to grow, since it can reduce travel and thus reduce costs and the polluting side-effects of vehicle usage; however, it is a new form of interaction, and there will need to be a learning curve as individuals adapt to it (video on demand, except for specialty niches such as within hotels, should grow at a much lower rate)

� Caching data in the network improves access to information

� It is difficult to overemphasize the requirements for good administration and security in networks

� The concept of QoS appeared a few years ago, and still needs time to develop fully. It is a fundamental parameter for the usability of a system. In use, the quality�in terms of bandwidth, or latency, for example�of a connection is negotiated, and then the network guarantees that level while the connection is open

When a number of disks are assembled within a single enclosure, but without any special organization (such as RAID) being implemented, the collection is known as JBOD (Just a Bunch of Disks).

Source of Information : Elsevier Server Architectures 2005

Intelligent Disks

We will now look at yet another proposal from researchers at the University of California at Berkeley, a place with a high output in the field of innovative architectures. Their proposal is to do with making good use of the processing capabilities embedded with each disk drive; they call it Intelligent Disks (or IDISKs).

In the early days of magnetic peripherals, the interface provided facilities closely matched to the operations the disk mechanism could naturally perform. This changed; in the 1960s, with processing power causing a system bottleneck, disk units with autonomous data-handling capabilities began to appear, with a concomitant increase in the level of abstraction supported by their interfaces. An example from IBM in the S/360 family was the ckd interface, which, for example, allowed the system to delegate to the disk a key-based search for a record.

The economics of minicomputers and then microprocessors made processing power cheap enough that intelligence began to migrate back into the system proper, and we saw the emergence of standard low-level disk interfaces like SMD and ESDI. The growth of complexity in the peripherals drove the existence of a higher-level interface, SCSI. Implementing SCSI more or less requires a microprocessor and supporting memory, to provide protocol support, cache, local management of the peripheral, management of read/write head positioning, error management, buffer space for SCSI bus transfers and so on. Current technology already makes it possible to integrate, low cost, and low power processing/memory and interface electronics directly with the peripherals themselves, along with system interface support (such as FC-AL). The idea behind intelligent disks is to make greater use of this embedded intelligence, allowing both off-loading of the server and greater computational concurrency. We note here the balance swinging back: new technology allows us to effectively re-implement old ideas.

Various levels of functionality may be envisaged for intelligent disks.; Examples include:

� Off-load database management software, along with necessary supporting OS functions, in a share-nothing architecture implemented across the disks themselves

� Off-load some database management functions onto the disks�for example, searches and joins, with the control of these operations being done by the server-resident DBMS

� Off-load file system activities�for example, optimizing a string of commands by reordering them in the disk to minimize head movement

While there is little quantitative information available for the benefits this approach can bring, the real problem is standardization. Indeed, widespread deployment of intelligent disks would mean that the most widely used software (from basic file systems with simple access methods, such as those offered by Windows and Linux, all the way up to DBMSs) would be adapted to such machinery. This requires agreements between the players behind this software and the disk manufacturers; an agreement between the disk manufacturers is in the realm of the possible, and is in any case a prerequisite for any larger agreement between software vendors and the disk manufacturers.

These latter possibility seems more remote; we can easily observe that historically, DBMS manufacturers have avoid using the magic features of any system platform, preferring to use extremely low-level interfaces so that they could be certain that execution of vital functionalities is under their control and could therefore be guaranteed across platforms. This view also simplifies porting across platforms and reduces support and development costs for the DBMS.

Source of Information : Elsevier Server Architectures 2005

Disk Evolution

We expect the rate of improvement in basic technology for disks�storage density and access time�to slow down. Improvements in the architecture of disks and storage subsystems will be able to compensate somewhat for this slowing, particularly for the high-end products, which is where we concentrate our discussion.

Image, inspired by [MOO99], summarizes some predictions about disks and storage subsystems.

A few comments are in order, including the observation that the suggested order of events is not to be taken literally.

� The first changes suggested are to do with improvements in the bandwidth of the system interface (with FC projected at 2x2 Gb/s in 2002), or with improvements in bandwidth between the disk units themselves and the disk subsystems (using FC-AL or SCSI at 360 MB/s in 2003), as well as the projected increase in disk capacity (to beyond 100 GB) and rotational speed (moving first to 10,000 rpm and then on to 15,000 rpm). Increasing disk rotational speed improves average access time (which is the time for half a turn of the disk).

� Using high-level interfaces such as SCSI or FC-AL implies the use of a 32-bit microprocessor and a few megabytes of memory in the disk units; the provision of memory allows the disks to provide a cache in a totally transparent manner.

� A spread in the use of data compression is seen. This allows economies in several aspects of disk usage�not only is effective data capacity increased, but also effective bandwidth is increased and latency reduced by the degree of compression attained�at the cost of some processing to effect the compression and decompression. Given the very favorable improvements expected in price-performance for microprocessors, the computational burden imposed by this extra processing should easily be supported, whether in the server proper or in processors embedded in the disk subsystem.

� Physical sharing of storage between servers is currently possible at the subsystem level, and is the basis for SAN.

� As the intelligence in the subsystems grows, it is possible to give them the responsibility for higher-level activities, such as implementing backup and restore: the system initializes as needed, and then the peripheral does the work autonomously.

� Sharing storage at the logical level is significantly more complex a problem than physical sharing, since it means that two different systems (different processor architecture, operating system and data manager) are sharing logical data. Because of the wide diversity of systems and because in many cases the stored data is managed by a DBMS, it is reasonable to suppose that logical sharing is not at all widespread (in heterogeneous systems); it is much simpler to base server cooperation on a client/server-like behavior between applications.

� With disk technology improvements, it is possible for a disk manufacturer to offer multi-disk subsystems, operating as a RAID system and/or as a SAN subsystem; that is, disk manufacturers could become players in the storage world. This would likely hurt the established storage vendors in the same way that Intel moved from being a mere chip manufacturer to a specifier and supplier of systems.

� Data availability requirements and risk avoidance are likely to make remote backup increasingly common, and perhaps commoditized. This could drive a market for companies offering backup storage, with network exchanges taking the place of physical exchanges of magnetic cartridges.

� We can then envision an increase in Fibre Channel bandwidth, and the arrival of 500 GB capacity disks.

� When a system's overall performance is dependent on the performance of its I/ O, the overall performance is (as we have noted previously) liable to drop as improved disk technology becomes available, since as capacity increases the number of physical disks needed is reduced, automatically reducing the amount of parallelism available to the I/O system. Having multiple independent read/write channels on a single disk could claw back some of this concurrency, by more or less doubling parallelism at the disk level.

The last point on the graph is a disk built from DRAM, sometimes called a RAM Disk or a Solid State Disk. For many years, some observers have repeatedly predictied the crossing of the cost prices for DRAM and magnetic storage, and consequently the replacement of disks by DRAM. Beyond the projected cost benefits, the driving force behind this movement is the simple fact that DRAM is orders of magnitude faster than magnetic storage (perhaps 40 microseconds in place of 10 milliseconds). However, cache technology works for disk accesses as well, and a disk subsystem marrying a traditional magnetic storage device to a large DRAM cache can approach the performance of a pure DRAM disk without having to overcome the key issues of cost (since the cost curves have still not crossed and show no immediate signs of doing so) and volatility.

The volatility issue is real; DRAM is volatile�cut the power for more than a rather short interval and all the information is lost. To avoid this, one can provide a battery to keep power on at all times, or look for a better technology. The semiconductor industry is well aware of this and has been developing a number of promising technologies which marry silicon and magnetic effects. Motorola's MRAM [GEP03] seems to be a leader, although more directed at embedded memory than commodity memory chips; IBM's TMJ-RAM (Tunneling Magnetic Junction�Random Access Memory) is also worthy of mention. These technologies promise most interesting benefits: MRAM can be roughly characterized as having the density of DRAM, the access times of a mid-range SRAM, non-volatility and the ability to be rewritten an indefinitely large number of times. Even if costs do not reduce enormously, memory chips built from these technologies could be beneficial for applications requiring very high bandwidths, or for specialized roles such as journaling transactions�that is, recording the journals which track transaction-based changes in a non-volatile memory.

Source of Information : Elsevier Server Architectures 2005

Network Communication Technologies

Within a system, multiple communications networks meet�from a chip handling internal connections all the way up to long-distance networks or networks formed from I/O buses and local networks. We will attempt to put the sundry communications technologies into perspective by organizing them by their potential data bandwidths and the distance they are intended to cover. What is usually covered by a discussion of networks is just one part of the whole picture.

The attach image, with no claim to completeness, lists various technologies classified by their distance (point-to-point) and bandwidths.

The very highest bandwidths, over extremely short distances, are the internal communications within a chip.

We then encounter a number of technologies which we can group together under the rubric of intrasystems networks, for which the acronym SAN has been used; in that context it meant System Area Network. However, nowadays the use of the acronym has been preempted to refer to network storage, when it means Storage Area Network. To minimize confusion, we shall adopt this latter meaning for the acronym. In the category of intrasystems networks we find:

� Systems buses, connecting processors to memory and I/O, are characterized by bandwidths of several gigabytes per second and distances in the 10-20 cm range�less than a foot

� I/O buses, such as PCI, which connect the processor-memory complex to I/O controllers. InfiniBand might replace PCI for this usage in mid-range and high-end servers. Connecting the processor-memory complex to the I/O subsystems, which would themselves likely still be built around PCI or a derivative

� Connections between I/O controllers and the peripherals themselves, using SCSI or FC-AL

� Connections between the processor-memory complex and a peripheral subsystem, such as disk or tape susbystems or a communications concentrator. Fibre Channel is the current prime example, and it may be joined by InfiniBand. HPPI (High Performance Parallel Interface) offers the same level of performance as Fibre Channel, but its use in practice is limited, essentially, to supercomputers

Beyond the intrasystems networks we find the local area network category:

� Ethernet, offering three classes of bandwidth: traditional Ethernet at 10Mbits/ second, fast Ethernet at 100 Mbits/sec (both these are very widely used) and gigabit Ethernet at 1 Gbit/second, which is finding its place in the market

� Token Ring at 4 to 16 Mbits/sec, which has an advantage over Ethernet in that it offers deterministic behavior. However, it has not had the same marketplace acceptance as Ethernet, probably because it is not an open technology and because of higher prices

� Fibre Channel and FDDI (Fibre Distributed Data Interface) make an appearance in this category as well, often as a concentrator of lowerspeed local area networks (such a network is referred to as a backbone)

� ATM has pretensions in the field of local area networks as well, with an emulation of a LAN named Lane (for LAN Emulation)

We then come to metro area networks, which are networks within a single city using technologies such as:

� Fibre Channel
� DQDB (Distributed Queue Dual Bus), which uses a pair of unidirectional bus connections
� FDDI, based on a token-ring technique
� ATM

And finally we see the category of long-distance or wide-area networks with technologies such as SONET (Synchronous Optical NETwork), and SDH (Synchronous Data Hierarchy) which are standards (ANSI for SONET), and International Telecommunications Union (ITU�once known as CCITT). SONET and SDH both carry ATM packets. For private lines, Frame Relay is also worth mentioning; it extends the capabilities of X25.

In the image, we also show two technologies used to connect users to telecommunications networks: ADSL (Asymmetric Digital Subscriber Line) and HDSL (High Bit Rate Digital Subscriber Line), are standards in this area. They make it possible to sharply increase bandwidths using existing copper telephone connections, giving up to 52 Mbit/sec for distances up to 300 meters (a bit over 300 yards) and even 1.5 Mbit/sec at distances up to 3 kilometers (around 2 miles).

Alongside the convergence of the different technologies in the areas of distance and bandwidth, we also see a convergence between local and wide area networks. As an example, ATM technology is as well-suited to LAN usage as it is to WAN. And it incorporates the concept of quality of service, guarantee a user�once a connection is granted�a quality of service (in guaranteed bandwidth, for example) for the duration of that connection.

However, the largest portion of installed networks are IP networks; this domination can only be extended with the advent of the new IPv6 version of the protocol, which considerably extends the address space of an IP network. Given IP's commanding position, any new network technology must support IP if it is to succeed.

Source of Information : Elsevier Server Architectures 2005

PCI�s Origins and Competitors

PCI started as an industry initiative that aimed to overcome the limitations of the then-current PC bus (ISA bus). Initially proposed by Intel, it was developed by a group that included systems manufacturers, component vendors, suppliers of add-in cards and peripherals, and software companies.

Competition for the bus at the time included IBM�s MicroChannel Architecture (MCA), introduced on their PS/2 personal computer systems and the EISA bus, promulgated by a PC manufacturers� group.

MCA, unlike the open ISA bus, was a protected piece of IBM intellectual property; the result was that it only ever appeared in IBM products.

EISA suffered from a different problem; since it was backwards compatible with the venerable ISA bus, it embodied a number of compromises which limited its advantages over the earlier standard.

PCI won against both MCA and EISA through its combination of functionality and its openness.

Source of Information : Elsevier Server Architectures 2005

PCI, SCSI, and Fibre Channel

The PCI standard had its origins in the PC world, and has supplanted the two earlier standard microprocessor backplane buses�VME and Multibus. VME is, however, still used in real-time systems and in some process control applications. It started as a 16-bit bus and later grew to 32 bits; for the most part, VME-based systems used Motorola 68000-family microprocessors.

Multibus I was also a 16-bit bus initially, but Multibus systems tended to house Intel processors. While Intel extended the definition of Multibus I to 32 bits as Multibus II, the new version never saw wide adoption and disappeared fairly quickly.

We can summarize PCI�s major characteristics as follows:

� Two data transfer widths�32 bits and 64-bits

� Two clock rates�33MHz and 66MHz

� Various available bandwidths (133, 266, and 532 MB/sec), depending on clock rate and data width, and with burst-mode transfers

� The ability to support both 32 and 64 controllers on the same bus

� The ability to automatically discover the configuration of devices on the bus at system initialization (known as Plug and Play; this avoids tedious parameter setting in control tables)

� The ability to plug in and remove controllers without stopping the system, a capability known as hot plug.

PCI offers�even in its slowest version�substantially higher throughput than the earlier buses (and higher than MCA and EISA, too, which offered 33MB/sec and 40MB/sec respectively).

The significantly greater demands of more recent technologies, such as Gigabit Ethernet or Fibre Channel, have led to a proposal for a first extension to PCI, called PCI-X, with 32- or 64-bit data widths running at 66, 100 or 133MHz. The bandwidth of a 64-bit, 133MHz PCI-X interface is 1064MB/sec. Along with the physical enhancements, the bus protocol has also been improved in order to enhance efficiency.

The capabilities have been further extended into PCI-X 2.0, whose specifications were approved early in 2002. The goals of PCI-X 2.0 may be summarized as:

� Meet performance needs with an interface capable of handling 64-bit data widths running at 266 or 533MHz and with a throughput of 2128 or 4256 MB/sec respectively

� Support the use of earlier-generation cards to protect earlier investments (of course, this simply means that old cards must work with the new bus; a PCI-X 2.0 system with a mix of cards meeting earlier specifications and cards meeting 2.0 specifications will run at the speed of the slowest card)

� Become an industry standard

� Integrate well with the InfiniBand initiative (see below)

These various buses all represent the classical way to connect up peripherals and controllers �New I/O Structures: InfiniBand�we will examine the limitations of the classical approach and show why a new I/O architectural approach is called for.

Source of Information : Elsevier Server Architectures 2005

I/O

Neither systems architects nor computer architecture researchers have paid as much attention to I/O as they have to processors. The rationale for this lack of attention is completely unclear to us, since I/O is a key part of a system, being both a driver for system performance and an opportunity for value add�unlike processors, where the economies of scale predominate.

We provided a generic server model with the purpose of identifying the various interconnects of interest, mentioning the interconnects between processor, memory and I/O.

An I/O system comprises a number of elements.

As shown in this diagram, the various elements of a classical I/O subsystem are as follows:

� A system controller implementing the connection between processor(s), memory and the I/O bus(es). In practice, this is often a chip integrating two functions�a memory controller and an I/O controller.

� One or more I/O buses. The industry has converged on the PCI (Peripheral Component Interconnect) bus and its extensions.

� I/O controllers connected to an I/O bus. Peripheral devices�for example, disks directly connected to the system, long-distance network connections (WAN, for Wide Area Network) and local network connections (LAN, for Local Area Network) are connected to these controllers.

� Directly-attached magnetic peripherals (a configuration called DAS, for Directly Attached Storage), on specialized buses such as SCSI, which today is the standard for this purpose.

� Specialized networks are used for the connection of peripheral subsystems, such as disk subsystems (e.g., SAN, for Storage Area Network) or communications subsystems (WAN or LAN). In this domain, the industry is moving to Fibre Channel.

We will first be interested in buses used for I/O (principally PCI and its extensions) and in the connections between controllers and magnetic peripherals (SCSI and Fibre Channel�Arbitrated Loop, or FC-AL) and subsequently in Fibre Channel, used to connect to peripheral subsystems.

Later, we will look at the InfiniBand I/O proposal, which has some chance of gaining traction in the years to come. For this success to come about, widespread industry support will be vital; at the time of writing, we are still waiting for confirmation of such commitment from an appropriate spectrum of industry players. For InfiniBand, we will concentrate on the functionality of I/O interfaces and the optimizations appropriate for communications in a loosely-coupled system, with an emphasis on clusters. Since data is the vital and central element of business information technology, the characteristics of the storage systems used are important factors in the choice of servers. Since data needs to be directly accessible�that is, on-line�permanently, both within a company and outside it (through the Internet), storage systems have become an essential part of a server. Trends in storage subsystems are ever-increasing capacity, performance, and availability, coupled with steadily reducing cost per gigabyte.

Communications support�both local and wide area�also has increasing importance. Reflecting this, specialized subsystems connected to servers have been developed.

Source of Information : Elsevier Server Architectures 2005

Intelligent Memory

Researchers at Berkeley have suggested that rather than bolting some amount of SRAM, organized as a cache, around a processor, one should add a processor core to a DRAM. They called this approach IRAM, for Intelligent RAM. Since processor and memory coexist on the same chip, extremely high bandwidth connections between them are possible and cheap. When the memory happens to be large enough to contain a complete application and its data, one can then imagine adding serial or narrow interfaces such as HyperTransport, RapidIO or Gigabit Ethernet, and thus avoid expensive, silicon-unfriendly parallel external interfaces. In such a situation, an IRAM chip would have interfaces only for power and network interconnect. A specialized version of the concept, a vector-processing. We summarize the pros and cons of IRAM:

IRAM pros and cons
Advantages
� High band-width (compared to traditional DRAM)
�Low latency (compared to traditional DRAM)
� Energy effectiveness.Compactness

Inconveniences
� Suitability of DRAM manufacturing process for processor (logic) implementation
� High-temperature operation of the chip (because of highperformance logic), making DRAM refresh cycles very frequent
� Limiting the memory size of a system to what fits on a single chip
� No flexibility in the processing power/memory capacity ratio
� Cost of manufacturing test
� Industry acceptance



These judgements arose from the IRAM project, and deserve some comment.

� DRAM processes optimize for different capabilities from the highperformance logic processes generally adopted for microprocessors. Therefore, the natural question is: is an IRAM built in a DRAM process (yielding markedly sub-optimal processor performance) or a logic process (yielding markedly sub-optimal DRAM)?

� One may circumvent the memory capacity limitation of pure IRAM by providing interfaces to external memory (perhaps serial, for cost reasons); but then some of the IRAM advantage is lost.

� With the pure IRAM approach, each chip has a well-defined processing and memory capacity. Changing this ratio implies changing the chip. The most natural system architecture for such a device is a loosely-coupled multiprocessor. Note that integrating a message-passing interface (for example, RapidIO) would not change the processing/capacity ratio. An SMP would mean major complicated changes to an IRAM chip, and would strongly affect performance (inter-chip bandwidths are unlikely to match within-chip bandwidths).

� A significant portion of the cost of a DRAM is manufacturing tests. Adding a processor must increase this cost noticeably, but an IRAM cost must be compared with the cost of a processor plus the cost of a memory.

� For an IRAM-like approach to succeed, it must be widely adopted. For this to occur, a major industrial gulf would likely have to be bridged�memory manufacturers (whose economics have long been controlled by commodity-like cost constraints) and microprocessor manufacturers (whose pricing reflects a belief in value-add through superior IP).

We should also note�reflecting the concerns of an earlier section�that an IRAM would likely offer a new instruction set architecture, and would thus run into many more barriers as well; it is possible that a Java-like approach might modify this harsh judgement. An IRAM must also choose to follow DRAM interface standards or not; either course of action will have cost and usability consequences.

And finally, we must note once again that any silicon technology which does not achieve wide adoption is destined to disappear.

Source of Information :  Elsevier Server Architectures 2005

Architecture-Neutral Distribution Format

Within the framework of the OSF (Open Software Foundation) created at the end of the 1980s by a group of information processing systems manufacturers, whose initial goal was to develop a UNIX operating system independent of Sun and ATT, there was an attempt to promote a distribution technology independent of processor architecture. However, this technology, called ANDF was not adopted by industry players. It consisted of distributing the applications in a form of intermediate code (compilers produced this intermediate code instead of generating computer code). Installation then required translation of the intermediate code into computer code. One reason for the failure of this approach could be that software vendors using it might have been presented with a support problem, since the approach vastly increases the number of platforms on which the software could be run (to port to a new platform, one needed only a translation program for that platform). The Java approach, which we cover shortly, is different in that it specifies a Java Virtual Machine (JVM) to execute the Java programs., and the JVM is the piece to be validated. However, in the JIT (Just In Time) compilation strategy of Java, one sees a close parallel with ANDF.

Source of Information : Elsevier Server Architectures 2005

System Abstraction Layer

SAL allows the portability of the operating systems�in binary format� between various platforms based on the same processor architecture. The role of this layer is to hide the specific details of the platform from the operating systems. Among the principal functions of a SAL are:

� The assumption of responsibility of initialization, test and the configuration of the hardware resources of the platform

� Providing the operating system with data structures describing the configuration

� Provision of basic services for resource management, such as choice of which processor will load (�bootstrap�) the system; basic hardware error management and error logging

� Hiding differences arising from the use of different processor architectures, or the use of different processors within a single architectural family

For IA-64 systems, Intel has introduced a further layer between the SAL and the hardware; this new PAL (Processor Abstraction Layer) layer is intended to hide the differences between the implementation details of successive generations of IA-64 processors from the SAL. For an operating system intended to be ported across processor architectures, this functionality has its natural home in a SAL.

The concept of a SAL was understood and implemented long before the term itself was introduced. As an example, the manufacturers of both proprietary and UNIX systems developed families of products which had differences in implementation�in particular, for performance reasons�and therefore often had to develop an abstraction layer to facilitate porting the OS between the various models in the range.

In the case of Windows NT, a similar abstraction layer was implemented, called HAL, for Hardware Abstraction Layer.

Source of Information : Elsevier Server Architectures 2005

Flynn�s Classification of Parallel Architectures

On the level of systems architectures, Michael Flynn proposed a classification of parallel architectures:

� SISD (Single Instruction Single Data), in which just one stream of instructions performs a transformation on a single stream of data (this is the simplest model and corresponds to the computer architecture model described by John von Neumann.)

� SIMD (Single Instruction Multiple Data), in which the same stream of instructions is applied to disjoint sets of data

� MISD (Multiple Instruction Single Data) in which several instruction streams are applied to the same stream of data, (some sources hold that pipelined execution is the closest approximation to this approach, but we feel that this is a somewhat artificial view, since in a pipelined machine there is but one instruction stream)

� MIMD (Multiple Instruction Multiple Data), in which independent instruction streams are applied to independent sets of data (as we will see in the case of parallel DBMSs, the same program (the DBMS) is simultaneously executed, without synchronism on disjoint sets of data one speaks then of SPMD Single Program Multiple Data Stream)

Source of Information :  Elsevier Server Architectures 2005

Compare and contrast the three major multiprocessor architectures: SMP, massively parallel and cluster

An SMP (for Symmetrical Multiprocessor) is a system in which several processors share the same memory and function under the control of just one executing operating system. An SMP generally provides�within its configurability limits�the best scalability and the best price/performance ratio. SMPs are tending to become commodities at the entry level, although there are some problems in extending SMP to support a very large number of processors�at the time of writing, somewhere around 100 processors seems the upper boundary. While this amount will increase over time, for applications that call for extreme processing capabilities (intensive numerical operations or decision support across very large databases), one turns to cluster or MPP systems.

A cluster is a collection of otherwise independent systems (�nodes�) connected by a fast interconnect. Each node runs under the control of its own copy of the operating system, although cluster software gives the user the illusion that it is a single, extremely powerful, high-capacity system. Clusters support high availability in a very natural way: any applications running on a failing node can be retried on the surviving nodes. While clusters can provide high performance, they do require that applications be written to support the programming model provided by the cluster. Both DBMSs and integrated management packages (for Enterprise Resource Planning) have been ported to cluster systems. While it can be hard for a cluster to deliver on the promise of its performance for transaction processing, it is much more straightforward for decision support.

From an architectural point of view, the only difference between a cluster and an MPP is the maximum number of processors supported�several hundreds for the MPP, instead of tens�together with a very high- performance interconnect. Key applications for MPP are intensive scientific workloads and decision support. To leverage the available raw performance, applications must be carefully written to match the platform architecture, with extreme attention being paid to extracting and exposing the maximum parallelism. Peer-to-peer networks, grid computing and clusters of PCs can offer an economic alternative to an MPP system.

Source of Information :  Elsevier Server Architectures 2005

How much longer will system performance continue to increase?

A number of factors contribute to system performance: the performance of the processor(s), memory, I/O, network, and disks, as well as that of various software components (including OS, middleware, and applications), all have an effect. However, the largest effects have been seen�and will continue to be seen�in the area of processor performance and memory capacity. And as far as microprocessor performance and memory capacity is concerned, there seems little reason to suppose that the technology improvement curve will slow before 2010 or thereabouts; thus, microprocessor suppliers will have enough transistors and frequency capability on hand to keep processor performance on track for quite a while (although if it is not constrained, the increase in thermal dissipation associated with the higher frequencies could be a roadblock to achieving the desired level of performance). Memory capacity increases will make it possible to track the growth in software size and in the amount of data handled; this growth in memory size will make it possible (through the use of cache technologies) to compensate in large part for the lack of equivalent improvements in disk and network access times. But the possibility of abreakdown in the smooth progression of system performance remains, if memory access times and bandwidths get too far out of step with the demands of processor performance.

This drive for growth is driven by software�s insatiable appetite for storage capacity and processing power. And there are no objective reasons to suppose that the appetite or growth will stop. The open questions, however, are the growth rate and the effect that these phenomena will have on the industry.

One could observe, across several information-processing domains, that the industry goes through successive phases: a phase of stability, followed by a phase of disruption. A stability phase is characterized by continuity in architectural concepts and incremental improvements. During such an equilibrium phase, we can observe intense technological developments, often far afield from the mainstream. A disruption is characterized by a sudden questioning of established verities, together with a flood of new ideas coming to a head. New architectural concepts, approaches and products appear; the market makes its choice (not always in favor of the new), and the structure of the industry moves on. A new phase of stability then commences.

Source of Information :  Elsevier Server Architectures 2005

Does high availability mean that a fault-tolerant machine is needed?

Traditionally, fault tolerant machines were based around hardware redundancy, and able to survive hardware failures without any break in service.

High availability no longer requires such fault-tolerant machines. There are many solutions based on cluster architectures that are able to satisfy the majority of high availability needs.

It should be noted that the reliability and maintainability capabilities of the platforms used to construct a cluster system are of primary importance in obtaining a system able to meet extreme availability needs.

Fault-tolerant systems are used in situations when the time between a failure and complete resumption of services must be very short. Hardware reliability continues to improve (a trend that will continue for technology reasons), while software reliability marks time at best (granted, the quality of a given piece of software will improve over time�given appropriate management�but there always seems to be more software). Failures attributable to software substantially exceed failures due to hardware. Clusterbased solutions provide some protection against software failures, while purely hardware-based fault-tolerant machines can cope only with hardware failure.

Source of Information :  Elsevier Server Architectures 2005

Are RISC processors dead, killed by Intel?

What drives the market to settle on an architecture is, almost certainly, the availability of applications; IA-32 (Intel Architecture 32-bit, once known as x86) has clearly benefited from this effect since the introduction of the PC. This architecture, because of its complexity, is not positioned to offer the best performance potential; but its extremely large sales volumes allowed Intel to make substantial investments in research and development (R&D), allowing its processors to match the best RISC processors (except for floating point).

Development of IA-32 has not stopped, and RISC processors will have an increasingly difficult time competing with the architecture for entrylevel and mid-range systems.

With the new IA-64 architecture, Intel squarely faces RISC machines on their own ground�high performance (both integer and floating point) together with 64-bit addressing. Itanium, the first implementation of this architecture, hardly met expectations in terms of integer performance or availability date. Itanium 2 and its successors are likely to remedy this situation. In looking at the situation, recall that IA-64 performance has two interrelated components: compilers, which must extract and express the internal parallelism in programs; and the performance of the processor itself. HP�s contribution, especially for the compiler, is invaluable to Intel, to whom this is a new field.

We should not forget that there is constant progress in IA-32 implementations (and in IA-32 compatibles), a factor that delays the penetration of IA-64, a new architecture lacking the large applications catalogue of IA-32.

Our comment on the Itanium catalogue refers to the IA-64 native catalogue; Intel has provided IA-64 with the ability to execute IA-32 applications, thereby getting Intel the support of the key vendors of applications, databases, middleware, and operating systems�albeit not at the same performance as could be obtained with native Itanium applications.

Because the investment needed to develop new implementations of an architecture keeps growing faster than the market, the tendency will be for the number of RISC architectures to reduce. The survivors will be those with either sufficient market volume, or very strong compatibility reasons. We have already seen a number of RISC architectures fall by the wayside; we can reasonably suppose that just a few years in the future we will see a maximum of two RISC architectures (plus IA-64) surviving. Of course, IA-32 will continue to exist, too.

The real challenge for IA-64 in the area of IA-32 support arises with AMD�s introduction of a straightforward extension of IA-32 to 64-bit architecture, allowing a smooth coexistence and migration between the two architectures. This will be particulary interesting to watch in the next few years.

Source of Information : Elsevier Server Architectures 2005