Return to nwtips.htm
Server
motherboard recommendations:
These recommendations are
for a NetWare Server, but generally apply to any server. I recommend a 'server class'
motherboard with ECC RAM, support for at least 1GB of RAM, and optionally 64bit
and/or 66MHz PCI, PCI-X, or PCIe. SCSI is also preferred to IDE, but UDMA IDE
can work well IF and ONLY IF the UDMA controller on the motherboard is one
supported by the OS (On NetWare, IDEATA.HAM v3.10d or later supports UDMA on
the Intel BX and later chipsets, ServerWorks chipsets, some recent AMD or VIA
chipsets.) See IDEATA
for more info and links to newer drivers.
I also recommend a case
with multiple cooling fans. The Supermicro SC750/SC760 cases are nice tower
units that can handle many drives and at least 8 fans (user added). Cases with
redundant power supplies and/or rack mount cases are available, but I don’t
have a specific recommendation.
You don’t need a P4 for
NetWare, but it will work. You may need
to apply Novell’s P4 patch, see CPUs for more info.
Multiple
CPUs are of little or no benefit in NetWare servers. See SMP for more
info.
I do not currently have a
P4 motherboard I would recommend because I haven’t tested any for any length of
time, but units based upon the Intel 845, 875P, E750x, or ServerWorks chipsets
should be good choices. The Asus P4C800
Deluxe is one such motherboard. Supermicro
has many such motherboards. http://www.supermicro.com/matrix.htm
Compaq and Dell both make
excellent servers (for NetWare, Linux, or Windows). Compaq has generally had better support for NetWare than anyone
else, while Dell servers generally have fewer proprietary components making
them easier to upgrade. IBM and HP have
had decent support for NetWare, but I’ve never used their servers so I can’t
recommend them.
NetWare 5.x and earlier
will generally not make use of a second CPU. This is not usually a performance
limitation because NetWare is not CPU intensive. NW 4.11, 4.2, and 5.x do
support SMP, but only for NLM’s specifically written to use SMP. NW6.x’s SMP support has been greatly
extended. Since NW6 can make better use
of multiple CPU’s, you might consider a multiple CPU machine if you’re
considering an upgrade to NW6, although there is little, if any, benefit to
multiple CPU’s, even on a NW 6.5 server in most environments. See SMP
below for more details on multiple CPUs
Hyper-threading on Intel
Pentium 4 CPU’s should be disabled, it will almost always slow down a NetWare
server (see SMP below).
There is a P4/NW5.1
specific patch (4PENT.EXE) needed for installation, but I don't know if it's
required for normal operation. Search Novell’s Knowledgebase for "Pentium
4" OR "Pentium IV" for more info.
The Intel P3 and P3 based
Celeron CPUs do require a patch (OS5PT2A/SBS5PT2A) or NW51sp3 for NW 5.x. This patch must be applied BEFORE the server
is booted using NW5sp6a/NW51sp2a to prevent a file from being corrupted (I
believe it’s the NetWare registry that gets corrupted, but I’m not certain of
that).
The AMD Athlon or Duron
CPUs are prone to overheat and burn up (newer ones may just shut down) if the
CPU fan fails and it’s very difficult to find a motherboard for them that
supports ECC RAM, therefore, I don’t recommend these CPUs for production
servers. They should be fine choices
for non-mission critical servers as long as they have sufficient cooling (preferably
dual fans on the CPU heatsink) and ECC RAM (or reliable non-ECC RAM if you can
tolerate the chance of a memory failure).
There is no 64 bit code in
NetWare (as of NW 6.5sp1), therefore, the AMD Opteron and forthcoming Intel
EM64T CPUs will offer little or no benefit and NetWare may not even run
correctly on them (it’s untested as far as I know).
Maximizing
performance
The following guidelines
assume a base of a 486/Pentium class CPU, 64+MB RAM, PCI bus, and SCSI or UDMA
IDE hard drives and controllers.
Anything below that needs to be upgraded to at least that level before
any significant performance gains are practical.
Here’s a rule of thumb for
maximizing performance of:
NetWare server used
primarily for file and print services (This includes servers with client side
databases such as MS-Access, FoxPro, Clipper, and most proprietary databases): RAM first, network architecture
second, hard drive/controller/bus type third, CPU forth. The same is true of non-NetWare servers, but
the minimum CPU requirements may be significantly higher. In particular, see the section on allocating
sufficient directory cache buffers in NWRAM for general
file server performance.
Server (NLM) based
databases (Oracle, MS SQL Server, Informix, etc.) and Web servers will typically benefit most from
these items in the following order: RAM first, CPU second, hard
drive/controller/bus type third, network architecture forth.
By network architecture, I
mean faster/lower latency switches, fewer switches between servers and
workstations, faster link speeds, etc.
1Gb links introduce very little latency, each 100mb (including
switch-to-switch) link introduces nearly 10x as much latency, and each 10mb
link is nearly 100x as much as a 1Gb link.
Keep links to a minimum number and maximum speed. WAN links introduce significant
latency. Latency doesn’t affect raw
data transfer rate much (as long as you’re using a streaming protocol such as
IP or burst mode IPX), but it can significantly affect client side databases
and non-burst mode IPX.
1. NetWare isn't
particularly CPU intensive, so a faster CPU won't make much difference. The
1GHz+ P3/Celeron/Athlon/Duron CPU's are faster than P4's up to about 2GHz (with
PC800 RDRAM or DDR SDRAM). P4 motherboards with SDR (Single Data Rate, aka
standard) SDRAM are 20%-30% slower than P4's with RDRAM or DDR SDRAM making
them even slower when compared to 1GHz+ P3/Celeron/Athlon/Duron systems with
SDR SDRAM. Even on servers running large GroupWise or Oracle systems that might
benefit from a faster CPU, there is no P4 optimized code in NetWare. The memory
performance situation has improved with the release of DDR (Double Data Rate)
and DDR2 SDRAM chipsets for the P4, including the Intel 845D and 750x chipsets.
When coupled with DDR/DDR2 SDRAM, a P4 is just as fast or faster than it is
with RDRAM. P4 CPUs above 2.2GHz will
probably be slightly faster than P3 CPUs, but the benefit in NetWare is small.
2. A CPU at up to 1GHz may
help with performance of ‘client side’ databases such as MS-Access, FoxPro,
Clipper, and most proprietary databases because latency introduced by the
server processing the request is minimized.
Above 1GHz there is a diminishing effect of the faster CPU. Sufficient RAM to cache the entire database
is more valuable than a faster CPU, hard drives, or controllers. Better network architecture will typically
make more difference than the fastest CPU.
For MS-Access (MS-JET database engine) specific tips, see http://www.granite.ab.ca/access/performancefaq.htm.
You may also need to increase these settings on your NetWare server.
SET Maximum Record Locks =
200000
SET Maximum Record Locks
Per Connection = 10000
3. NetWare does generally benefit
from extra RAM. See NWRAM
for RAM sizing tips.
4. Multiple CPUs will
rarely benefit NetWare servers. See
below for more specifics.
NetWare server parameter
settings: nwsettings.htm
Multiple CPU’s and/or Hyper-Threading and NetWare
LAN drivers, Oracle and
GroupWise are the only NLM’s I know of that can benefit from multiple CPU’s on
NetWare 5.x or earlier. Even in those instances, only heavily used systems are
likely to benefit from more than one CPU. Having multiple CPU’s in NW5.x or
earlier can slightly slow the server and may cause stability issues in certain
circumstances. If you have a multiple CPU machine and wish to disable the SMP
support in NetWare, comment out the SMP enabler (usually MPS14.PSM,
ACPIDRV.PSM, or CPQSMP.PSM) from the STARTUP.NCF file and restart the server.
To temporarily disable additional CPU’s, you can issue a STOP PROCESSORS
command at the NW5.x console to stop all processors except the first. TID
10052541 is for NW 4.11/4.2, but generally applies to NW 5.x as well.
The
issue with multiple physical CPU's is that there is extra overhead involved in
managing/scheduling multiple CPU's.
Unless primary CPU is over 50% typical utilization, adding additional
CPU's just adds overhead which results in slightly slower performance. The other critical feature needed to see
performance gains from multiple CPUs is that the system is multi-threaded and
consistently has at least two tasks requesting CPU time. If the primary CPU is frequently hitting
90+% utilization or is averaging over 50% and there are multiple threads
requesting CPU time, then adding a CPU may help.
Those
situations ALMOST NEVER occur in NetWare, so multiple CPU's almost always slow
down a NetWare server slightly, although the penalty may be very small with
fast CPUs.
Some
CPU intensive NLMs such as databases (Oracle, etc.), GroupWise, Web servers,
Java apps or X-windows apps on the server might justify additional CPU(s) if
the server is fairly heavily used by those tasks. The above conditions still apply.
The
biggest problem with hyper-threading (HT), as currently implemented by
Intel, is that the second “virtual” CPU only has about 1/3 the throughput of
the primary CPU. If the OS scheduler
isn't aware of the speed difference (and most aren't because they expect
identical CPUs in SMP environments), then scheduling high priority or latency
sensitive tasks on the “virtual” CPU results in slower performance for those
tasks, thus slower overall performance.
HT should be disabled on NetWare servers. HT should also be disabled on all machines
running Windows NT4 or 2000 and on most machines with multiple physical CPUs
that are running XP or 2003.
Search Novell’s
Knowledgebase for “SMP”, “PSM”, or “multiprocessor” for known issues with
multiprocessor support in various versions of NetWare and/or third party NLMs.
Note:
Having any IDE/ATA (or ISA NIC) devices running in PIO (not DMA/UDMA) mode may
significantly increase CPU utilization (as high as 90%) and significantly
decrease performance. Adding additional
CPUs in that case may NOT help because interrupts may be disabled during PIO
transfers. Using the most recent
IDEATA.HAM will help IF and only if your server’s IDE chipset is supported in
DMA mode and your IDE devices all support DMA mode. If your server’s IDE chipset is not supported, changing to SCSI
drives and bus master controllers (or DMA ISA or PCI NICs) will help.
The
current situation is that there aren't many applications that are truly
multi-threaded, they tend to single threaded, "sequentially"
threaded, or possibly dual-threaded by separating the GUI and process
threads. The modern OS's are
multi-threaded, but not all of the services are. The practical effect of which is that multiple CPUs (and/or HT)
allow two or more applications or services to run concurrently, but generally
don't help any particular application or service.
Until
programmers learn to think and write in multiple threads (and have development
tools that facilitate that), the advantages of multiple CPU's and HT will be
limited. Despite that, dual CPU's (or
HT on an HT aware scheduler) do provide some benefit for everyday processes,
even if it's just slightly better responsiveness.
Servers
running multiple services (or multi-threaded services) are more likely to
benefit in the near term, but only if they're CPU limited rather than I/O
limited.
For additional information on
Hyper-Threading see:
Warning,
these may be WAY more than you want to know.
http://www.intel.com/technology/itj/2002/volume06issue01/art01_hyper/p01_abstract.htm