FAQ for SDG v.1 - ARCHIVE
This page provides clarifications and corrections for Hardware Design Guide for Microsoft Windows NT Server, Version 1.0.
The goal of the Hardware Design Guide for Microsoft Windows NT Server is to present guidelines for designing servers and peripherals that provide an enhanced user experience when implemented with Microsoft Windows 2000.
Correction to item 5, "Installed system memory meets minimum requrements":
The minimum installed memory required is 128 MB (rather than 64 MB), which is identical to the requirement defined in Hardware Design Guide Version 2.0 for Windows NT Server for all classes of server running Windows 2000 Server or Microsoft Small Business Server. Note that this does not override the note which recognizes that OEMs supply systems to corporations with feature requirements that might specify no pre-installed memory. However, for testing purposes, the system must include 128 MB memory as a minimum.
This correction is defined because 64 MB on a Windows 2000 server will not provide an enhanced end-user experience. (Change date: February 17, 1999)
Clarification to item 18, "Each PCI slot and device type has access to a non-shared interrupt line":
System designers must make a best effort to provide access to non-shared interrupt lines by meeting these conditions:
| • | The system design enables all PCI slots and PCI device types to obtain exclusive use of an interrupt line when exclusive access increases performance. |
| • | Dedicated PCI interrupts must not use vectors from ISA bus interrupts. |
The high-end and low-end commodity server platforms present certain design challenges. For high-end servers, PCI 2.1 taken by itself imposes a limitation for Intel Architecture-based systems because the values written to the Interrupt Line register in configuration space must correspond to IRQ numbers 015 of the standard dual 8259 configuration, or to the value 255 which means "unknown" or "no connection." The values between 15 and 255 are reserved. This fixed connection legacy dual 8259 configuration, if examined alone, constrains Intel Architecture-based systems, even when they use sophisticated interrupt-routing hardware and APIC support. For low-end servers, some core logic offerings provide little or no interrupt-routing support, and designers implement rotating access to interrupt resources using simple wire-OR techniques, such as those illustrated in the PCI 2.1 implementation note in section 2.2.6 of the PCI 2.1 specification.
Windows NT, with its support for both MPS 1.4 and ACPI, uses mechanisms beyond the legacy methods of routing all PCI interrupts through the legacy cascaded 8259 interrupt controllers to determine proper allocation and routing of PCI bus IRQs. This Windows NT capability allows use of interrupts beyond the 015 range permitted by the strict reading of the current PCI 2.1 specification language for Intel Architecture systems. System designers should include sufficient interrupt resources in their systems to provide at least one dedicated interrupt per PCI function for embedded devices and one interrupt per PCI INTA# INTD# line on a PCI slot. This will become a requirement for all servers in a future version of this guideline.
When system designers cannot provide a non-shared interrupt line to a particular PCI device or slot because of the above situations, the server systems documentation must explain clearly to the end user of the system how interrupt resources are allocated on the platform and which devices cannot avoid sharing interrupts. System designers may provide this documentation or information as they deem most appropriate for their product. Some possible mechanisms include:
| • | Documenting slots according to the order in which cards should be inserted to prevent interrupt sharing for as long as possible |
| • | Providing information on interrupt routing and sharing via system setup programs |
Some instances need additional clarification to fit within the context of this guideline. At the system designers discretion, PCI devices can share an interrupt line under the following conditions:
| • | One system interrupt line can be shared by all PCI devices on an expansion card. In other words, PCI INTA# INTD# may share the use of a single system interrupt directed to a given PCI expansion slot. This instance of line sharing applies to both expansion card designs based on PCI multifunction devices and to expansion card designs using PCI-to-PCI bridges. |
| • | Devices can share an interrupt in a design where a system-board set has multiple instances of a given PCI device performing a specific function. For example, two embedded PCI SCSI controllers on a system board can share a single system interrupt line. A single line can be shared when the functions of the devices are very similar, such as a case where one embedded SCSI controller may be dedicated to "narrow" (8-bit wide) SCSI devices and the other is dedicated to "wide" (16-bit wide) SCSI devices. On the other hand, an embedded SCSI controller may not share an interrupt with an embedded network adapter on a system board, because they perform two different functions within the system and could contend for the shared interrupt in ways that will reduce overall system performance. |
(Change date: October 6, 1998)
Compliance testing for items 54 and 55, "Adapter automatically senses presence of functional network connection" and "Adapter automatically senses transceiver type":
These requirements apply only where the network media allow this capability. (Change date: July 15, 1998)
Clarification to item 59, "Adapter supports configuration capabilities for performance tuning, with all settings stored in the registry":
This item is meant to require that any and all network interface adapter tuning parameters be stored in the registry and be accessible through a user interface. The explanatory text was meant to provide some examples of items that may be adjusted using tuning parameters. There is no requirement with regard to the use of specific parameter keywords, default numbers of receive buffers, interrupt moderation, or moderation algorithms; these are simply examples of some of the tuning parameters which, if present, must be implemented in this fashion.
Some network adapters and drivers might support additional configuration capabilities for performance tuning when used in special environments or applications. Any tuning parameters that are set by the user, an application, or the operating system must be controlled through registry variables.
An example of such performance optimizations might be adjustment of interrupt moderation or the number of receive buffers for systems used as dedicated routers.
In addition to Dynamic Interrupt Moderation, there are other techniques that may be implemented on network adapters to maximize system performance for special environments or applications.
User-tunable parameters must be set through registry variables as parameters for network adapters and must not be set in .INI files, configuration files, or in other locations. These parameters can be accessed using the Advanced Page in the Device Manager. The variables should be set through standard user interfaces provided in Windows. (Change date: August 13, 1998)
Clarifications to item 60, network adapter support for remote new system capabilities:
Item 60 in Version 1.0 of the Server Design Guide requires adapters to be compatible with remote new system capabilities if used as a boot device.
It is highly recommended that network adapter implementations submitted for testing, either integrated on the system board or add-on cards, have this capability built in and enabled. Such adapters must either have a boot ROM integrated on the board or have a socket for a boot ROM with the boot ROM installed. This allows WHQL to test the remote boot functionality. However, if the vendor plans to sell such a card as a standalone retail device without the boot ROM installed, its packaging must indicate clearly that the remote boot capability is supported and available as an option.
There are a few exceptions to the above:
1. | It is acceptable for server network adapters to not support remote boot. |
2. | Remote boot capability is recommended on at least one port on a multiport adapter. |
3. | Based on customer requirements, a server system as shipped may include one or more or all network adapters without remote boot capabilities and still qualify for the logo (this may be a corporate customer requirement based on their security policy). Another example of this is a server configured with a Gigabit Ethernet connection. However, if the server can support a network card as a boot device (even if not ordinarily sold that way), it must be configured for remote boot testing when submitted to WHQL. Servers that do not support network cards as boot devices should clearly state this fact in the user documentation shipped with the server platform. |
If implemented, there must be a way for remote boot capability to be enabled and disabled by way of administrative control in order to maintain server security. (Change date: July 28, 1998)
