Network Architecture - Comparing Sun Solaris 7, Windows nt server 0, and Windows 2000 Server

An operating system’s network architecture refers to its physical network device support and its ability to operate over a variety of LAN topologies. This review covers each operating system’s physical device driver architecture, driver support, driver availability, and support for the various network media types available on the market today such as Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, and ARCnet.
Solaris 7 Implementation Details
When examining network architecture support for Solaris 7, there are three key areas to look at:
-
Hardware support.
-
Network media support.
-
Device configuration.
Hardware Support
You are faced with two completely different sets of issues when dealing with the hardware support for Solaris 7. The first is the support on Sun’s proprietary hardware. Because Sun is a hardware company as well as a software business, the support for Sun operating systems, included packages, and licensed third-party applications is excellent. A purchaser can be assured that a choice to run Solaris 7 on Sun SPARC-family hardware will cause few if any compatibility issues between the software and the hardware. The biggest issue for compatibility on the proprietary hardware platform is which version of the Solaris operating system is being run. And there are two issues that can further confuse the Solaris user.
The first is which revision of the Solaris operating system is being run as the platform for Solaris 7. Solaris 7 is supported on both the Solaris 2.6 and Solaris 7 versions of the core operating system. While this, on the surface, may seem like only a small difference, many applications that run on Solaris 2.6 will not run or need to be recompiled to run on Solaris 7. Second, on current Sun hardware, the operating system can be installed in full 64-bit mode or as a 32-bit operating system. Some versions of the various applications that make up Solaris 7 have earlier versions in place that will only work with Solaris as a 32-bit operating system. For example, problems have been reported with PC NetLink and Solstice PPP 3.0.1. Also, 32-bit tools from third party vendors may need to be recompiled before they can run on 64-bit systems. Primarily, this problem is encountered when the tools have been compiled with a restrictive flag (-xarch=v9).
The second set of hardware issues deals with running Solaris 7 on the Solaris for Intel platform (also referred to as Solaris x86). Sun certifies compatibility on only a very small subset of the devices (systems, network adapters, SCSI controllers, etc.) that are available in the x86 world. For example, they only officially support Ethernet cards from fewer than 20 vendors (see The Solaris Hardware Compatibility Web site for the complete list of compatible hardware).
Network Media Support
All standardized network architecture types are supported as part of the operating system, including:
-
Ethernet (10Base-T, 10Base-2).
-
Fast Ethernet (100-BaseT).
-
Gigabit Ethernet.
-
Token Ring.
-
FDDI.
While Sun Solaris 7 doesn’t support ARCnet, it does support native ATM. ATM technology itself is emerging as a worldwide standard for the transmission of information. Numerous telecommunications organizations and enterprise customers are rapidly deploying it today. For many, ATM represents the next generation for LAN switching. Its extremely high performance is enabling a new breed of real-time voice and video applications.
Sun Solaris 7 using SunATM adapters supports 155MB/second and 622MB/second transfer rates. At 155MB/second, data can be transferred over multimode fiber or standard category 5 cables. The ATM Forum User Network Interface 3.0, 3.1, and 4.0 specifications are also supported. In accordance with RFC 1577, TCP/IP applications can run transparently over ATM.
Device Configuration
An advantage Sun Solaris 7 has over Windows NT 4.0 is the ability to make most device configuration changes without having to reboot the system. You can, for example, reconfigure a network card without restarting the server. However, this advantage does not extend to Windows 2000 Server. Windows 2000 Server can change device configuration settings without rebooting.
An area of configuration where Sun Solaris 7 falls behind Windows 2000 is in support for Plug and Play and auto-detection of devices. While Windows 2000 supports auto-detection during and after installation of the operating system, Sun Solaris 7 only supports auto-detection of devices during installation of the operating system. This means you must manually detect and configure new devices.
Windows NT Server 4.0 Implementation Details
Windows NT Server 4.0 uses the existing 32-bit NDIS standard for network device drivers. Introduced with Windows NT 3.1, 32-bit NDIS provides support for all major types of devices including ISA, ISA PnP, PCI, EISA, MCA, and PCMCIA. Because 32-bit NDIS has been available on the marketplace for years, both hardware support and media types support is considerable, including Ethernet (10Base-T, 10Base-2), Fast Ethernet (100-BaseT), Gigabit Ethernet, ARCnet, Token Ring, and FDDI. However, Windows NT Server 4.0 does not provide native support for ATM.
On the Windows NT Server 4.0 CD-ROM, driver support is provided for most popular network cards. Additionally, any 32-bit NDIS driver can be used. Windows NT Server 4.0 will auto-detect most network cards that are supported during initial operating system installation. PCI device settings are automatically detected and configured in most cases. All other types of cards must have their configuration settings specified by hand. As with Solaris 7, all hardware-related configurations must be done outside of the operating system.
Post-installation, or in systems with multiple network cards, all devices must be added by hand. Additionally, if the device is not PCI-based, configuration settings must be manually specified. Any type of device-related configuration requires that the server be rebooted, potentially interfering with server uptime for simple configuration-related issues.
Windows 2000 Server Implementation Details
Windows 2000 Server expands on the 32-bit NDIS driver model. As with Windows NT Server 4.0, device and media type support is outstanding due to the longevity of the 32-bit NDIS driver standard. As would be expected, all standardized network architecture types are supported as part of the operating system, including:
-
Ethernet (10Base-T, 10Base-2).
-
Fast Ethernet (100-BaseT).
-
Gigabit Ethernet.
-
ARCnet.
-
Token Ring.
-
FDDI.
Native ATM Support
New in Windows 2000 Server is native Asynchronous Transfer Mode (ATM) support. Microsoft has entered into licensing agreements with FORE Systems and Olicom to bundle Olicom’s UNI 3.1 call manager and FORE Systems’ ForeThought ATM LAN Emulation client software with Windows 2000 Server. These provide solution developers with an additional path to bring their products to market quickly for use with Windows 2000 Server.
Plug and Play Support
Windows 2000 Server, unlike either Solaris 7 or Windows NT Server 4.0, is a Plug and Play compliant operating system. In addition, native operating system support is also provided for PCMCIA and CardBus devices. Consequently, Windows 2000 will automatically detect all ISA PnP, PCI, EISA, PCMCIA, and CardBus devices, regardless of whether a driver is present. (The user will be prompted for device drivers if one is not present as part of the operating system.) Also, unlike Solaris 7 or Windows NT Server 4.0, post-installation, Windows 2000 Server will automatically detect all of the aforementioned devices.
Additionally, because Windows 2000 supports Plug and Play, PCMCIA, and CardBus, hardware configuration settings such as I/O ports or interrupts can be managed via the operating system rather than via vendor-supplied utilities. Also, unlike either Windows NT Server 4.0 or Solaris 7, hardware conflicts will be automatically resolved by the operating system.
Dynamic Configuration Changes
Configuration changes, such as the addition or removal of device drivers, can be made without rebooting the server. In most cases, even hardware configuration settings such as changing transceiver types, can be made while the system is running, if the device supports dynamic configuration.
Power Management
Windows 2000 Server also supports all of the latest standards in power management including APM and ACPI. Consequently, network devices can be powered off when not in use and dynamically reactivated via incoming packets or outgoing traffic. Windows 2000 Server also supports Wake-on-LAN technology, allowing an entire machine to be powered down and then reactivated via incoming network requests. Although these features are probably not of benefit to most LAN administrators, they will prove beneficial to any mobile or power-conscious users. With APM and ACPI support, Windows 2000 Server has the potential to run for longer periods on battery powered systems thanks to its ability to conserve power when not in use and then to be dynamically reactivated via incoming network traffic.
Network Architecture Summary
Windows 2000 Server supports Plug and Play, hardware auto-detection and auto-configuration during installation and post installation. You can adjust hardware parameters in the operating system, and configure all network device settings dynamically without a reboot. These features are unmatched by either Solaris 7 or Microsoft Windows NT Server 4.0. Additionally, where ATM connectivity is a priority, Windows 2000 Server offers native ATM support.
Solaris 7 supports automatic detection of hardware during installation and the ability to change device settings dynamically within the operating system, but it does not support Plug –and Play. Also, the range of hardware support for the x86 platform for Solaris 7 is quite limited.
Although Windows NT Server 4.0 benefits from excellent device support and driver technology maturity, its general lack of auto-detection and auto-configuration abilities for network devices and its inability to dynamically reconfigure existing devices make it the most difficult of the three operating systems to administer. This is especially true, given the downtime generated from simple device configuration changes by the requirement of many reboots.
|