It is reasonable to look upon the early CRAY architectures, which strove to obtain high execution rates through the use of simple instructions, as the basis of RISC architectures. The concept was explored in a more general manner inside IBM with the 801 project (John Cocke and George Radin [HOP87], [SHR99]); this project—named after the building in which it was done—was finished in 1979, and its results were published in 1981. Similar studies at Stanford and Berkeley started in the early 1980s, and led respectively to the MIPS and SPARC architectures. The acronym RISC was created by the Berkeley team. The first commercial computers based on these concepts were marketed by start-ups Ridge and Pyramid, who introduced their products in (respectively) 1983 and 1985, followed by HP who introduced HP PA (Precision Architecture) in 1986. Sun’s introduction of SPARCbased systems in 1987, transitioning in an exemplary fashion from their 680x0-based product line, was instrumental in the acceptance of RISC concepts.

Source of Information :  Elsevier Server Architectures

• 0 comments »

Looking at the historical record, we can see that processor architectural evolution tends to develop as a repeating two-phase phenomenon—a stability phase being followed by a breakaway phase.

In the stability phase, we see concentration on implementation refinement while the architectures remain essentially unchanged.

• hardware architectures, embodying improvements such as the techniques

• compiler improvements, making it possible to better exploit architectural features

• instruction set extensions, but without breaking backwards binary compatibility; examples are the addition of multimedia capabilities, and the extension of addressing capabilities

The stability phase is one in which an equilibrium has been reached.

However, despite the equilibrium, in the background things are going steadily wrong, putting increasing pressure on extant architectures. Examples include the growing gulf between processor and memory speeds; the reduction in memory costs that make program size much less of an issue than before, and the increasing the integration capabilities of the technology. We can qualify such evolutions as being non-homotetic, since they destroy established equilibrium and lead eventually to a break; in other words, pressure is great enough to support a breakaway solution.

Such a breakaway solution is characterized also by a flock of new ideas and thinking, and of questioning of well-established “truths”. Two obvious examples are

• The appearance of RISC architectures

• The introduction of IA-64

This view of architectural evolution suggests it proceeds in a manner similar to an earthquake—for a long time, the deep movements are invisible except to those with the appropriate sensitive instrumentation; but eventually the tensions pass a critical threshold and the situation ruptures. A key difference between earthquakes and architecture evolution is that for architectures, the critical threshold keeps increasing, particularly in terms of the size of the necessary investment.

Source of Information :  Elsevier Server Architectures

• 0 comments »

Below we list—non-exhaustively—selection criteria appropriate for an IT professional to use in choosing a server, following the list by a discussion of each criterion in turn:

• Availability of applications and development tools
• System availability
• Data integrity
• Security
• Performance
• Scalability
• Price
• Support for the client/server model
• Architectural maturity
• Investment risk

Note that the list is given in no particular order; when selecting a server, the individual needs of the business will drive the relative weighting of the criteria.

The availability of a vast catalogue of applications and development tools eases the construction of business solutions and is an indication that the server family under consideration has a strong and active marketplace. Such an active market has beneficial indirect effects: reduced prices because of volume and competitive effects; enhanced confidence in the continuity of the vendor and platform; widespread availability of experts in the applications and the tools. We should note in passing that the success of a platform is rarely an effect of the intrinsic merits of its technology (whether hardware or software); it is the marketplace that decides.

Since business activities rely more and more on their data processing resources, three criteria of increasing importance are availability, data integrity, and security. By availability, we mean the ability of the system to perform its function every time that it is requested; integrity corresponds to the system’s ability to manage its data without damage to the data; and security is the ability to ensure that there is no unauthorized access to that data.

The performance of a system is an important characteristic, but it is difficult to characterize with a single number. The best way of capturing performance is to identify what the system must do to fulfill its mission and then identify the values that allow one to characterize performance for that mission. If the analysis of the workload shows that one or more standard benchmarks is a close approximation to the workload, then one may use the relative performance of different systems on the relevant benchmark(s) to provide a good predictor of performance on the company’s workload. If no benchmarks fit well, then one can compare performance only by running tests on the real workload. Since systems needs often change over time, it is generally a good idea to leave some "headroom" in available performance when choosing a system.

Scalability—the ability of a system to match the dimensions of the problem it has to manage—is closely related to performance. But given the choice of two systems, one may prefer a less powerful system with good scalability over a more powerful system with less growth potential.

Over the course of time, the ways of comparing price have changed, shifting from a simple price comparison of the systems under consideration (both hardware and software) with support and maintenance costs added in, to a “Total Cost of Ownership” approach, which also integrates internal costs, such as the staff needed to operate the system, system management and user support costs, the economic impact on the company were the system to become unavailable, etc.

Support for the client/server model depends on the availability of appropriate middleware; some platforms are better served than others in this area. For example, standard systems present a significant potential market, and so attract the attention of middleware publishers.

Although the various concepts used in server architectures are widely known, the development of a new architecture often takes longer than originally expected by its developers. The various aspects of maturity are very powerful forces; one such effect is the difficulties innovative architectures often meet while going to market.

Installing a server and the necessary applications represents a major investment, in terms of both immediate expenditure (acquisition costs of hardware and software) and associated costs (training, implementing new applications, etc.). Given the usual size of these costs, the investment risk is an important criterion. It is particularly important that a server vendor stay in existence for as long as its customers are using its products, and so this issue presents a particular problem to start-ups, since so many collapse while young. This difficulty can be less severe for suppliers of products like storage subsystems, since these have extremely well defined interfaces with their host systems—so, if the supplier collapses, all is not lost—alternative products from other vendors can be deployed in the same way and with the same connections as the products from the ill-fated start-up. In general, however, the subsystems purchased from the defunct vendor must be replaced, since such subsystems will, in general, only run software provided by their vendor.

Source of Information :  Elsevier Server Architectures 2005

• 0 comments »

The concept of a cluster has been known for a long time - since the end of the 70s for Tandem and since 1983 for Digital. UNIX clusters appeared at the very start of the 90s, while Windows 2000 clusters did not arrive until the late 90’s. UNIX clusters not only offer excellent functionality, but extremely good stability, which they acquired after years of experience. For Microsoft, this experience is still in its very early stages, so one may judge that UNIX clusters have a solid advantage today.

The problems faced by the UNIX clusters are due to their diversity; each cluster solution is specific to a UNIX vendor, each of which offers its own software interfaces. Each UNIX cluster vendor therefore has to support the development of its own cluster extensions and, at the same time, any thirdparty software vendor who wants to take advantage of the high availability and the scalability of the various cluster solutions must somehow handle this wide range of diversity.

Converging on some smaller number of UNIX versions, perhaps triggered by the introduction of IA-64, could effect a remedy to these diversity problems—unless the systems vendors decide to reserve the cluster extensions for use just on their own systems. Because Microsoft’s cluster solution is an integration of proprietary interfaces and of implementation, it answers just one part of the problem. The key problem remains unanswered: that qualification of application software on a given system platform is a necessity.

Finally, we should note that Linux-based cluster solutions could offer a threat to Windows-based systems similar to the threat they offer to the fragmented and divided UNIX market.

Source of Information :  Elsevier Server Architectures 2005

• 0 comments »

Hardware cost reductions should continue. At least in the entry level, we can distinguish two pricing models: constant performance with reducing price, and constant price with increasing performance. It is better to make comparisons using the price/performance ratio. It should be noted that the increasing investment necessary to build such systems will reduce the number of vendors, and that such a reduction in competitors could diminish the rate of cost reduction.

As to software, the logic of a volume market works as well as for hardware. And phenomenon of free software will tend to stabilize or even reduce the cost of commercial offerings.

Source of Information :  Elsevier Server Architectures 2005

• 0 comments »