In Phase 3 of the Open Benchmark both Red Hat and
Microsoft were free to use the latest software available
and to make other configuration changes to the same Dell
PowerEdge 6300/400 server used in Phases 1 and 2. Also, we tested
both one- and four-processor configurations of the Dell server.
For Phase 3 Mindcraft used the same version of
Windows NT Server 4.0 as in Phases 1 and 2. Red Hat
chose to use Red Hat Linux 6.0 upgraded to the 2.2.10
kernel. See the Products
Tested section below for other software, hardware and
configuration changes.
The other significant change in Phase 3 was the use
of both Windows 95 and Windows NT NetBench clients for
the file-server tests.
File-Server Performance
Figure 1 shows the file-server performance
we measured and the scaling between
one- and four-processor configurations. Linux
file-server performance on a four-processor system increases by 43% over a
one-processor system. Windows NT Server, on the other hand, improves
performance on a four-processor system by 105% over a one-processor
system.
Figure 1:
File Server Performance in Phase 3
(larger numbers are
better)

Figure 1 shows that even the one-processor configuration
running Windows NT Server is a faster
file server than any of the Linux configurations. Table 1
summarizes the Windows NT Server speed advantage over Linux.
Table 1: File Server Speed Advantage
of Windows NT Server over Linux
1 |
Windows 95 |
1.5 times |
4 |
Windows NT |
1.9 times |
4 |
Windows 95 |
2.7 times |
Web-Server Performance
Figure 2 shows the Web-server performance for
all of the phases. It shows that Red Hat was able to achieve 14%
better performance in Phase 3 than in Phase 2. This was accomplished by using
Linux 2.2.10 and different tuning for Apache, including static file
caching. See the Products
Tested section below for the
details.
The Web-server tests show that Windows NT Server is 2.2 times
faster than Linux 2.2.10/Apache 1.3.6 on a four-processor server and 1.4 times faster on
a one-processor server.
Figure 2:
Web Server Performance in Phases 1, 2 and 3
(larger numbers are
better)

The performance scaling differences between Linux and Windows NT
Server are even more pronounced for Web servers. Linux increases
four-processor system performance by 42% over a single processor
system. This compares to the 124% performance scaling improvement Windows
NT Server demonstrates.
If you have not already read the Looking at NetBench Results
in the Phase 1 and 2 document, it may help you
understand this analysis. The supporting details for Figure 1
are in the NetBench Configuration and
Results part of this white paper.
The Windows NT Server 4.0 file-server peak
performance increased between Phase 1 and Phase 3
primarily because we partitioned the RAID into four 7 GB
partitions. This greatly reduced contention for the
critical log file resource of the NT File System. Partitioning makes
sense in real-world situations because
it allows for more efficient system
administration. As a result of the partitioning,
the four-processor Windows NT file-server performance increased
over that in Phase 1 by about 9%
with Windows 95 clients.
When we switched to Windows NT clients, Windows NT
Server turned in 294.6 Mbits/second
of throughput, about 13% slower than with Windows 95
clients. Nevertheless, Windows NT Server still outperformed Linux/Samba
by 1.9 times when both were tested using Windows NT clients. The Red Hat engineers made several significant
server configuration changes in addition to the Linux
upgrade including:
- Replacing the RAID controller with another SCSI
controller.
- Creating a software RAID 0 logical drive of 4 GB
spread across eight disks for the NetBench data.
The four-processor Linux/Samba test results using
Windows 95 clients show that these configuration changes
made no performance difference when compared to Phase 2.
Thus, the Linux/Samba performance
bottleneck is somewhere other than the disk subsystem.
We believe the major
reasons for the poor Linux/Samba performance are:
- A single threaded TCP stack;
- Large-grained locking
in the kernel; and
- Samba running in user space.
The shapes of the performance curves for
both Windows NT Server 4.0 and Linux/Samba
indicate that we reached peak performance
and went beyond it. Performance for both
Windows NT Server 4.0 and Linux/Samba
degrades slowly as the load is increased
past the peak performance load. So both
systems should deliver predictable
performance even under overload conditions.
If you have not already read the Looking at WebBench Results
in the Phase 1 and 2 document, it may help you
understand this analysis. We used the standard
WebBench zd_static_v20.tst test
suite, modified to increase the number of test threads to
240 (120 system with 2
threads each) for Phase 3.
The supporting details for Figure 2 are in the WebBench Configuration and Results
part of this white paper.
The Linux/Apache configuration changes in Phases
3 improved the four-processor performance by 15% over
Phase 2. We
believe that most of this improvement came from memory
mapping (caching) the data files in Apache and from the
Apache "top fuel" patch.
Mindcraft used its Phase 1 four-processor Windows NT
WebBench
results instead of re-running the test for Phase 3. Figure 2 shows the Windows NT
one-processor Web server performance matches that of the
Linux four-processor configuration.
We used the same Dell PowerEdge 6300/400
server that was used in Phases 1 and 2.
Windows NT Server 4.0 File-Server Configuration
We tested using Windows NT Server 4.0 Enterprise Edition with
Service Pack 4 installed. We made the following
configuration and tuning changes:
- Used 1024 MB of RAM (set maxmem=1024 in boot.ini)
- Server set to maximize throughput for file
sharing
- Foreground application boost set to NONE
- Set registry entries: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:
- \NDIS\Parameters\ProcessorAffinityMask=0
- Tcpip\Parameters\Tcpwindowsize = 65535
- \lanmanserver\parameters\InitWorkItems=256
- \lanmanserver\parameters\MaxWorkItems=256
- \lanmanserver\parameters\SizReqBuf=16644
- \lanmanserver\parameters\LinkInfoValidTime=10000
- \lanmanserver\parameters\MaxWorkItemIdleTime=1800
- Used the NIC control panel to set the following
for all four NICs:
- Receive Buffers = 200 (default is 32;
this setting is under “Advanced
Settings”)
- NIC speed = 100 Mbit (default is “auto”)
- Duplex=full (default is"auto")
- Spooler service was disabled
- Page file size set to 1012 MB on the same drive
as the OS
- The RAID file systems were formatted with 16 KB
allocation unit size (the /a option of the
format command) and an NTFS file system. The
RAID was divided into four 7 GB partitions and
the NetBench data was equally divided among the
partitions
- Increased the file system log on each RAID file
system to 65536 K using the chkdsk f: /l:65536
command
- Used the affinity tool to bind one NIC to each
CPU (ftp://ftp.microsoft.com/bussys/winnt/winnt-public/tools/affinity/)
only for the four-processor configuration
Windows NT Server 4.0 Web-Server Configuration
- Used Internet Information Server 4 (IIS 4) as
the Web server
- Used the NIC control panel to set the following
for all four NICs:
- Coalesce Buffers = 32 (default is 8)
- Receive Buffers = 1023
- Transmit Control Blocks = 80 (default is
16)
- Adaptive Transmit Threshold = on
(default is on)
- Adaptive Technology = on (default is on)
- Adaptive Inter-Frame Spacing = 1
(default is 1)
- Map Registers = 64 (default is 64)
- SMTP, FTP, MSDTC, and Browser services were
disabled
- Set registry entries: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services:
- \InetInfo\Parameters\ListenBackLog=200
- \InetInfo\Parameters\ObjectCacheTTL=0xFFFFFFFF
- \InetInfo\Parameters\OpenFileInCache=0x5000
- Using the IIS Manager
- Set Logging – “Next Log Time Period”
= “When file size reaches 100 MB”
- Set performance to “More than 100,000”
- Removed all ISAPI filters
- Removed all Home directory application
mappings except .asp
- Removed permissions for “Application
Settings”
- The RAID file system was formatted with 16 KB
allocation unit size (the /a option of the
format command) and an NTFS file system.
- Increased the file system log on each RAID file
system to 65536 K using the chkdsk f: /l:65536
command
- Logs on the F: drive (RAID) along with the
WebBench data files
- Server set to maximize throughput for
applications when doing WebBench tests
- The other tunes for the file-server
configuration were kept
Linux 2.2.10 Configuration
The Red Hat engineers started with Red Hat Linux 6.0
and upgraded it to the Linux 2.2.10 kernel. They also made the following configuration and tuning changes:
- Used 1024 MB of RAM (set mem=960M in lilo.conf)
- Used a buffer.c patch
- Used an new eepro100 driver
- Made changes to tpc.c
We have included a separate Web page with all of the Linux configuration files
Red Hat used.
Samba 2.0.3 Configuration
- Used the pre-compiled version of Samba 2.0.3
- Started Samba manually before each test
- Used a software RAID 0 on 8 disks. Added another
SCSI controller to do this
We have included a separate Web page with the Samba configuration
files Red Hat used.
Apache 1.3.6 Configuration
- Compiled Apache 1.3.6 using gcc version 2.7.2.3 and
glibc 2.0.7
- Started Apache manually before each test
- Used mod_mmap_static module to pre-load all files in Apache
We have included a separate Web page
with the Apache
configuration files Red Hat used.
We used the same test lab configuration for Phase 3
that we used for Phases 1 and 2. The only change made
was to run Windows NT Workstation 4.0 on the clients for
the appropriate NetBench tests.
Phases
1 and 2
FAQ
NOTICE:
The information in this publication is
subject to change without notice.
MINDCRAFT, INC. SHALL NOT BE LIABLE FOR ERRORS OR
OMISSIONS CONTAINED HEREIN, NOR FOR INCIDENTAL OR
CONSEQUENTIAL DAMAGES RESULTING FROM THE FURNISHING,
PERFORMANCE, OR USE OF THIS MATERIAL.
This publication does not constitute
an endorsement of the product or products that were
tested. This test is not a determination of product
quality or correctness, nor does it ensure compliance
with any federal, state or local requirements.
Product and corporate names mentioned
herein are trademarks and/or registered trademarks of
their respective companies.
|