
------------------------------------------------------------------------
NOV-HDW2.DOC -- 19961007 -- Email thread on NetWare file server hardware
------------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com



Date: Wed, 21 Feb 1996 19:23:32 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Hardware recommendations (EISA/PCI server)

>I'm putting together another server.  I'm planning on using a PCI
>motherboard this time, as EISA is getting hard to find..
>
>Anyone have any good or bad experiences using any of:
>- the Intel Pentium/PCI motherboards ?
>- A 486/PCI motherboard ?
>- Adaptec 2940 PCI bus SCSI Controller ?
>- 3Com PCI NIC ?
-----------
	When I went shopping for a roughly similar system last fall I found
three motherboard suppliers: Tyan Tempest III, ASUS PCI/E P54NP4, and
Micronics in the Micron Inc (memory guys) box. The combination of EISA bus
and PCI seems to mean dual Pentium boards.
	I purchased the ASUS board, with two P-100's, and it will run with
one or two cpus as you wish. 4 EISA, 4 PCI, all bus master, one of them is
shared. Neptune II chipset, and PCI stuff seems ok so far. Six SIMM sockets,
not the four in ISA/PCI boards, so I have memory flexibility. Obeys Intel's
SMP spec and of course PCI specs. The o/s is UnixWare in my case, and the
board has been rock solid. This board is popular in high end servers for Unix,
NT, and now NW 4.1/SMP; it's not expensive.
	There is no reason to purchase a 486 board today. Prices on Pentium
boards have dipped quite low and are good bargins. The PCI bus has settled
down enough that we have some confidence in it, but I hedge with EISA anyway.
	In my opinion I avoid Intel made motherboards. I don't know what it
is with those guys but there are far too many tiny components all over the
place and the boards are almost always off-center in some ways. This has
been the case since 386's. The mass market versions have little to offer
for NW servers; they are basically bottom price Windows boxes.
	I can't say anything definite about the Micronics board in the
Micron box (not the same vendor, by the way). In the past I've avoided
Micronics as being plagued with timing problems and far far too many hot
chips (old design syndrome). Gateway has Micronics make many of their
motherboards under contract. A friend as a P133 Micron machine (Windows box)
and it works fine so far running just Windows 95.
	This is an odd time to purchase a PCI board. The solid Neptune II
chipset is here and stable, and this month Intel started delivery of the
"Triton II" PCI chipset with badly needed features omitted from "Triton I"
(but they have two flavors of II so you have to choose which items to give up).
It's too early to jump on that bandwagon. Absolute speed is not the criteria
I use for production machinery. Stability with good performance is, hence
my satisfaction with the board noted above.
	I may have mentioned this elsewhere, but to be very candid, a dual
P-100 machine has soooo many horses under the hood that it is embarassing
trying to find stuff to make them work hard. My system is Unix so I can
pile on the tasks. NetWare needs but a tiny fraction of that horse power
unless you also plan to run a backend database on the server. The advice
is maintain sanity while touring the toy store. Also don't buy mass market
junk boards (which fill Computer Shopper).
	Also in my opinion I now avoid 3Com Ethernet boards. There are some
which are plain poor design (the parallel tasking stuff), others which are
EISA but not bus masters, and others with gotcha's waiting to happen. It's
a pity from a vendor with such a reputation, but just read this list for
tales of woe. Were I to pick a PCI Ethernet board the choice would probably
be a DIGITAL unit since it's very highly rated by PC Magazine, or a Cogent
board which has maintained a good reputation. Do be careful of Intel boards
and do avoid SMC boards for PCI. For EISA I use NE-3200's, and they have
worked very well indeed.
	Adaptec continues to make SCSI adapters of choice. In my case I
use 2742AT's, dual SCSI channels (14 devices), with floppy controller,
EISA bus. 2940's have no floppy controller, so figure out where you will
find one.
	Ok, that's my set of findings and opinions. Others have contrasting
views and will be granted equal time to respond (Henno is typing away madly,
I'm sure). Whatever you do, be up front about running NW and get a money
back guarantee from a reputable supplier.
	Joe D.

------------------------------

Date: Wed, 28 Feb 1996 08:27:13 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: mutiple servers vs super server

>Can anyone give me recommendations or citeria to help
>decide wheather a server should be split off in two OR
>hardware upgraded ( ie 2nd processor, more HD, more RAM)?

What's the current bottleneck, or are there any? Netware, as someone else
mentions doesn't really respond to a second processor. Relatively few
people know about the SMP option yet, but Novell has been very upfront
about it not being effective for file/print services; adding a second
processor only nets about a 10% increase under heavy loads.

1. First check the network utilization. If it's 70-80% for token ring
split some users off on another segment.

2. Next, check available RAM. It should be 50-70%. If not, add more.

3. Tweak the set parameters. This ALONE can nearly double server
performance. Make sure you've allocated enough ECBs, then radically
increase the minimum and maximum directory cache buffers. Optimum is up
for debate and is highly individual, but it's not unreasonable to
allocate 2-3000 directory cache buffers. Nearly every file load will
benifit. Also increase the dirty directory cache buffer nonreferenced
delay time up from the default of 2.5 seconds to the 30 second - 1
minute. This will force the system to keep more of the DET cached.
Finally, increase the number of simultaneous directory and disk write
operations. Play with these to achieve maximum performance, as there are
NO magic numbers. Oh, and turn off NCP file commits. Some Dbase type
databases and others will actually force a flush to physical disk before
continuing.

4. Replace the RAID 5 setup with spanned/duplexed drives; it's faster
under load. I don't really have time to explain now, it has to do with
the number of drive accesses per logical write activity.

5. If you're still suffering sluggish performance, it's time to consider
a new server. Just remember this:  PCI will likely give (today at least)
double the throughput of EISA, but most any server you get today will
have PCI. You'll double that thoughput with a second (or more!) server,
just keep in mind that if you depend on all of them you'll reduce your
uptime by that many times. If you design for redundancy (hot spares,
multiple data/program points, etc.) you can improve your uptime, at the
cost of some added complexity. Finally, 5 servers with 10 gigs each will
mount, run vrepair and service files 5 times faster than 1 server with 50
gigs to process

------------------------------

Date: Tue, 27 Feb 1996 23:07:55 -6
From: "Mike Avery" <mavery@bga.com>
To: netw4-l@bgu.edu
Subject: Re: mutiple servers vs super server

>Well a second processor won't help you much with Novell but the RAM
>and HD upgrade would.   I would stay away from volumes over 10 GB
>simply because they tend to exhaust the directory entries before the
>actual space is used ( a limit Novell doe not readily publicize).

Another reason to stay away from large volumes..... my previous boss
insisted that no volume be larger than what you can restore in an
hour.  This is a moving target.  As tapes and nets get faster,
volumes can get larger.  His feeling is that almost any user can
tolerate an hour wait.  But when you get into the 8 to 10 hours
restore range, almost any user can get testy.

I tend to agree with him.  Of course, as with everything in this
industry, your mileage may vary.  You may find that you have huge
data bases that mandate larger volumes.  At that point, SFT III may
start looking better.

------------------------------

Date: Tue, 5 Mar 1996 21:13:49 -0800
From: John Navarro <jnavarro@MCGRAW-HILL.COM>
Subject: Re: Drives out of Synch in Duplexing/

The remirror process is running as the server is trying to complete is
boot. That is why the boot process is taking so long.  Here's what I do
when I'm pressed for time in a production environment.  First I go into
monitor and disable the disk read-after-write verification.  This speeds
things up tremendously.  What I've done is made this the fist NLM I load
after I mount the volumes.  This ensures that monitor is available in
these situations. Remirroring makes things slow, but read-after-write
verify really drain performance evern on a PCI SCSI-fast/wide system.

Be sure to go back and reenable read-after-write verify after things are
back up.  You're gonna take a beating if your disk sub-system is IDE base
no matter what.

------------------------------

Date: Sun, 10 Mar 1996 10:02:51 -0500
From: Maddogmbw@aol.com (Mike Worden, CNE, PSE)
To: netw4-l@bgu.edu
Subject: Re: Server Recommendations

>I would like to hear about other experiences using clones as servers.
>I have been told if the parts are Novell certified that clones should
>work fine. Is the reliability better with a Compaq, HP, or other name
>server?

Linda, as you can probably imagine, from the dialog going back and forth
here... server selections seem to be a thing of emotional attachment... as
well they should be(the server is the Admin's livelihood)... So, I'll try to
keep this objective.

As long as the equipment you're looking for/at is certified by Novell Labs,
you're about as good as you're gonna get regarding compatibility. ALL file
servers have little problems that crawl out of the woodwork when you start
loading other products (hardware - and - software) into them. The fact that
the server has been certified by Novell Labs simply lends a bit of
credibility to the selection (i.e. you can feel more comfortable that you're
going to have avenues for exploring the resolution to the problems you may
encounter).

As for clone vs Tier-I server products, well... While the clone servers may
still run fine, remember the old saying... "You get what you pay for". The
Tier-I selections usually bring to the table things like ECC, Parity
Protected bus, C2 Security features, intelligent array controllers, outband
monitoring devices, PFA enabled devices, hot swap drives, blah blah blah...

You may still be able to "add" some of these features to a clone by wisely
selecting third party products to add to your server (i.e. someone's
intelligent array controller and and drives), but don't forget those "bugs in
the woodwork" !! When you start integrating products from multiple
manufacturers you're going to have to do your home work, and prabably a bit
of head scratching too.

(Now, just to be fair, I've installed literally dozens upon dozens of servers
and they have been mostly IBM and Compaq. Guess what !?   There are STILL
bugs in the woodwork, even when you limit your product/adapter selections to
a single manufacturer !!  Hmmm, I guess that's why they hire smart folks like
all of us hey !?)

As for relability, this is a complex equation... many things play into it.
Vendor, warranty, Novell Labs certification, etc... Don't overlook the
"non-hardware" aspect of your selection when considering the reliability...
an IBM Server 720 with all the fixin's isn't worth a darn if you can't get
GOOD service for it when you need it. End result (in the eyes of your users)
NOT RELIABLE !!

>Also, during my research I'm finding information about departmental servers
>that are geared for 60-200 users, but nothing about other kinds.  What
>should I be looking for.  Reading articles is sounds like my current
>servers are more like workstations.  What do I really need for 30 users?
>(Currently using 486ds 66  32 meg with 1.2 gig).  What price range am I
>going to be in?

Look at your application... let this be your guide.  Are you doing mostly
"File" serving ? "Database" serving ? "Application" serving ?
"Communications" serving ? Are your disk activities mostly "Random" or
"Sequential" read/write ? Are you interested in maximum expandability, or
is this lan going to remain pretty much the same size for the predictable
future ?

Look at these types of indicators, and develop a list of core objectives you
need to satisfy. Then, you can use this to compare to the features you are
finding on servers in the marketplace. Every server selection has a bit of a
"personalized" twist, exclusive to the company picking it out. Match with an
acceptable warranty and relative assurance that you have easy access to
support vendors, and start working on your finance person. No matter what the
cost, he/she will be one of your best ally's when getting final aproval for
the big "spend".

You might want to hook up with a local reseller, and see if they will
entertain a "pre-sale" meeting with an engineer.

In the server world, there is no "right or wrong".... only "easy and hard"!
The easy ones are the ones you plan better and that match your real "needs"
better.

------------------------------

Date: Sun, 10 Mar 1996 11:03:06 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Server Recommendations

>>Also, during my research I'm finding information about departmental
>>servers that are geared for 60-200 users, but nothing about other kinds.
>>What should I be looking for?  Reading articles it sounds like my current
>>servers are more like workstations.  What do I really need for 30 users?
>>(Currently using 486ds 66  32 meg with 1.2 gig).  What price range am I
>>going to be in?
>
>Look at your application... let this be your guide, grasshopper. (Sorry,
>couldn't help myself on that one : )   )  Are you doing mostly "File" serving
>? "Database" serving ? "Application" serving ? "Communications" serving ? Are
>your disk activities mostly "Random" or "Sequential" read/write ? Are you
>interested in maximum expandability, or is this lan going to remain pretty
>much the same size for the predictable future ?
>
>Look at these types of indicators, and develop a list of core objectives you
>need to satisfy. Then, you can use this to compare to the features you are
>finding on servers in the marketplace. Every server selection has a bit of a
>"personalized" twist, exclusive to the company picking it out. Match with an
>acceptable warranty and relative assurance that you have easy access to
>support vendors, and start working on your finance person. No matter what the
>cost, he/she will be one of your best ally's when getting final aproval for
>the big "spend".
>
>You might want to hook up with a local reseller, and see if they will
>entertain a "pre-sale" meeting with an engineer. Heck, they might even buy
>lunch : )
>
>In the server world, there is no "right or wrong".... only "easy and hard" !!
>The easy ones are the ones you plan better, and that match your real "needs"
>better.
>
>Good Luck !!
>Mike Worden, CNE, PSE

Excellent post, Mike! Good analysis of the issues.

I can add that for 30 users with basic services (file, print, maybe dial
in/out, email) a 486-66 should be adaquate for today, and maybe the next
year or two - provided you're using bus mastering (EISA or PCI) cards. If
you're specing a new server, I'd jump up to a p90-120 to give room for
growth - basic file and print services don't need it, but NDS, file
compression, aspects of backup and new services require CPU. Not much
individually, but as the environment gets more complex... . Besides,
you'll feel pretty dumb telling management in two years that they need a
new server because their new web server is taking up too many CPU cycles.

Other issues: For new, make sure you have a GOOD PCI bus, and find out
which adapters work well with it. If the manufacturer can't advise, don't
buy! You'll probably find that 30 users are too many for 1 ethernet
segment, but it's going to depend on their usage patterns. Also, a single
HD is probably going to be inadaquate - at least mirror, better yet
mirror/span across 4 drives sized to get your needed drive space, which
should only be about 25% full at first. If you must go RAID, Compaq's
array controller is hard to beat - inexpensive, and you  can add drives
to the volume later without deleting and reinstalling. BTW, this is what
I've specified for our internal network, which is about the same size.
About $6000 for Compaq, but use this as a ballpark figure.

------------------------------

Date: Sun, 10 Mar 1996 21:33:00 -0600
From: "Mike Avery" <mavery@bga.com>
To: netw4-l@bgu.edu
Subject: Re: Server Recommendations

>I am currently looking into purchasing a new server.  I have have
>been using two clone servers with 30 workstations and am considering
>moving to a single server.  I have had problems with both clone
>servers abending.  I'm not sure if the problems were with the clones
>or the way my network was set up.
>
>I would like to hear about other experiences using clones as
>servers.  I have been told if the parts are Novell certified that
>clones should work fine.  Is the reliability better with a Compaq,
>HP, or other name server?

I'm the village athiest when it comes to name brands.  I've used a
large number of different servers from a large number of different
vendors.  Overall, the care the installer took in setting up NetWare,
and the care the system manager takes in maintaining the system seem
to be a better predictor of success than the brand name on the box.

Some vendors, like Compaq, make it easier by having special CD-ROM's
that automate a lot of the installation.

If you have problems with a system, they are usually resolveable by
bringing the patches up to the current version.

>Also, during my research I'm finding information about departmental
>servers that are geared for 60-200 users, but nothing about other
>kinds.  What should I be looking for.  Reading articles is sounds
>like my current servers are more like workstations.  What do I
>really need for 30 users?   (Currently using 486ds 66  32 meg with
>1.2 gig).  What price range am I going to be in?

Well, a more important question that "how many users do you have" may
well be "What will your users be doing?"  If you have 250 users
running WordPerfect 5.1, you don't need a very hot server.  If they
are using a server based interactive graphics design program.....
then you may not have enough to support 5 users.

In general, NetWare is not processor bound.  All in all, a 486DX2-66
should be able to handle 250 users with no problems.

If there are performance problems, it's time to start looking for
bottlenecks.

The memory is generous for the amount of disk space, you should be
able to double your storage without adding more memory.  The big
question here is "how much storage do you need"?  And the answer is
usually "more than you thought, more than you dreamed".

If the problem is stability, it might be cheaper to resolve the
problems than to replace the servers and just wind up with an new set
of headaches.  Sometimes, for political reasons, it is better to
replace the hardware.

All that said, what would I do in your shoes?  If there are no
performance problems, I'd still consider consolidating the users onto
a single server so the other server could be used as a test bed or
users PC.  I'd move the disks to the main server to increase storage.

Then I'd bring it up to date on patches.

If it abended again, I'd get a core dump and send it to Novell for
interpretation.

------------------------------

Date: Sun, 10 Mar 1996 21:43:29 -0600
From: "Mike Avery" <mavery@bga.com>
To: netw4-l@bgu.edu
Subject: Re: Server Recommendations

>>I would like to hear about other experiences using clones as
>>servers.  I have been told if the parts are Novell certified that
>>clones should work fine.
>
>As long as the equipment you're looking for/at is certified by
>Novell Labs, you're about as good as you're gonna get regarding
>compatibility.

Sorry.... I have to speak up here.  Just because individual parts are
certified does not suggest that they will work together.  And server
certification, the last time I looked, certified an integrated
product.  The whole system was certified - motherboard, case, memory,
NIC's, disk controller, disk drives.  If you changed anything - even
the hard  drive in the box, the new product is no longer certified.

As a result, I do not feel that Novell certification has ever been
terribly useful in the real world, and since vendors can self-certify
their products, the value of product certification has further
eroded.

My suggestion is to by a system from an integrator who is willing to
guarantee the system, has a reputation for standing behind what he
sells, and has the resources to support you.  And that does not
always mean a big store and a Compaq - it can mean a small outfit and
a clone.

------------------------------

Date: Wed, 13 Mar 1996 22:15:16 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: A note on Intel Pro 100 Ethernet boards

	Steven Shippee and I are working on some tests of Ethernet boards
of the 100Mbps variety and I came across an interesting item for the group.
	These EtherExpress Pro/100 boards have a feature of wishing to
start transmitting a packet after N buffer bytes have arrived, unless told
otherwise. The default is a couple hundred bytes. Well, it turns out that
such "parallel tasking"-like behavior reveals itself on the wire in the
form of bad packets (fragments with no proper end). The cure is to tell the
board driver to wait for all of a packet to be delivered before touching the
wire.
	My setup is rather simple at the moment, just lashed together.
A brand new, hours old, Pentium 100 EISA/PCI board as a NW 4.10 test
server, with the Intel PCI board. Cat 5 wire strung across the hallway
to my office where an Intel EISA board (same kind, different bus) is in
my desktop 486-66 DX/2. VLMs on the client, with Pburst but no local
cache. No hub ($$$).
	As I moved a few hundred MB back and forth I noticed that MONITOR
reported some TX DMA underruns, and that's the emitted fragment effect.
This was on the server, naturally. The obvious candidate for causing delays
is the disk system, a rather primative Adaptec 1542 SCSI controller and an
old SCSI I Seagate drive (you work with what you have). Now at 100Mbps a
128 byte fragment is about 1000 bits or 10^3 bits / 10^8 bps = 10 microsecs
to send on the wire. That is a very small time for the rest of the system
to deliver a missing buffer, even on a Pentium box.
	I suspect that the current 3Com Ethernet boards, and their SMC
rivals, have the same problem about wishing to get on the wire too quickly.
They may have software control to prevent it as does the Intel board, but
I don't know that myself. But if you have these boards I suggest preventing
the problem. That is the point of this message.

	Before folks ask, yes, it does go fast. Not nearly as fast as one
might expect because there are all the other components of both systems
in series. So how fast? I'm not going to say presently since I just hooked
up things tonight, but less than a factor of two difference from 10 Mbps
Ethernet. The throttle seems to be the slow drive on the server, as expected,
and I'll find out later when I can move over a faster drive. That 1542
controller is an ISA busmaster board, rather old by now, and yet all things
considered it is faster than the drive.
	Server utilization was up a ways, around the 40% mark, during big
transfers, and I attribute it to the disk system. MONITOR showed no noticable
overhead from the Intel Ethernet board, but it did show lots and lots when a
plain jane NE-2000 was used on coax. Dirty cache buffers shot to the limit
of 16MB memory (currently, will be doubled shortly) for files going to the
server, and that is a sure sign that the disk system is slower than the comms
link (simple queueing theory in action).
	Both Intel Ethernet boards have performed fine so far (a couple of
hours since being hooked up). Now I have to roll up the wire before someone
trips over it; a permanent link awaits the chore of dragging it through
tiny conduit filled with other wires, and we know who gets to do that task.
	There will be more on these experiments as time becomes availble.
	Joe D.

------------------------------

Date: Thu, 14 Mar 1996 00:19:16 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Addendum to note on Intel Pro 100 Ethernet boards

	I did manage to get some rough unscientific numbers between two
ways of communicating between the same server and client machines. The
iozone tests are shown side by side below. See netlab2.usu.edu, cd APPS
for iozone.exe. The differences are a little larger than I thought.
	Joe D.

	Operating System: MS-DOS, VLMs, no local cache. Slow server disk
system (which is the overall throttle on the exchange). 16MB server. Notice
how performance drops once we run out of cache buffers in the server to
buffer more disk requests (at which point server utilization climbs to
above 80% as it slaves to move things to disk). Disk read-check after
writes was turned off to get half way acceptable disk performance tonight.
NW 4.10 server, Pentium, 32KB disk allocation units, no other users.
	The 10Mbps case shows that the server has to spend lots of time
split between servicing the disk system and the NE-2000. Waiting a tad
too long means waiting for the disk to come round again.
	Reading means wait on the disk; writing is buffered by the server
and hence limited by server free memory. Reads are from server to client.

Server: Intel PCI 100Mbps             Novell ISA NE-2000 10Mbps
Client: Intel EISA 100Mbps            Novell EISA NE-3200 10Mbps
IOZONE: auto-test mode                IOZONE: auto-test mode

	IOZONE: Performance Test of Sequential File I/O  --  V1.15 (5/1/92)
MB  reclen  bytes/sec   bytes/sec     MB  reclen   bytes/sec   bytes/se
	    written     read                       written     read
1   512     516539      516539         1   512     254508      235635
1   1024    659481      825650         1   1024    353055      313007
1   2048    504123     1191563         1   2048    398698      397187
1   4096   1361787     1278751         1   4096    514007      466033
1   8192   1476867     1456355         1   8192    529583      504123
2   512     428865      483214         2   512     237234      244708
2   1024    794375      779610         2   1024    328707      329223
2   2048    979977     1158647         2   2048    449068      394201
2   4096   1198372     1361787         2   4096    537731      423667
2   8192   1416994     1416994         2   8192    626015      449068
4   512     426684      505947         4   512     238583      249660
4   1024    713317      755730         4   1024    319444      339619
4   2048   1158647     1033079         4   2048    417343      414866
4   4096   1252031     1271001         4   4096    483214      459901
4   8192   1416994     1384258         4   8192    534306      489417
8   512     430405      427771         8   512     236432      230013
8   1024    655359      505642         8   1024    313007      299486
8   2048    954335      425601         8   2048    399838      231729
8   4096    954335      437590         8   4096    462692      387643
8   8192    960894      465775         8   8192    512751      410401
16  512     442670      451121         16  512     235139      232274
16  1024    637674      557382         16  1024    311670      307613
16  2048    718818      513378         16  2048    398224      245928
16  4096    734232      543479         16  4096    458644      405148
16  8192    730714      550433         16  8192    499024      433295
Completed series of tests              Completed series of tests

------------------------------

Date: Thu, 14 Mar 1996 12:00:57 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Addendum to addendum to note on Intel Pro 100 Ethernet boards

	The last message on this topic for a while.
	To remove ambiguity about mixed experimental conditions, the table
below is for the same setup as last night but using the pair of Intel
EtherExpress Pro 100 boards set to 10Mbps rather than 100Mbps. One has to
restart the drivers to change speeds.

	IOZONE: Performance Test of Sequential File I/O  --  V1.15 (5/1/92)
		By Bill Norcott

	Operating System: MS-DOS

IOZONE: auto-test mode

	MB      reclen  bytes/sec written   bytes/sec read
	1       512     347210              317750
	1       1024    476625              455902
	1       2048    576140              579323
	1       4096    680893              635500
	1       8192    733269              680893
	2       512     318232              326659
	2       1024    476625              444311
	2       2048    587437              553338
	2       4096    683111              635500
	2       8192    748982              670016
	4       512     323634              333410
	4       1024    462947              454420
	4       2048    578524              549712
	4       4096    687590              626015
	4       8192    755730              668948
	8       512     324260              297152
	8       1024    460154              318111
	8       2048    572210              315479
	8       4096    664181              313007
	8       8192    666820              322266
	16      512     324260              308858
	16      1024    451243              336824
	16      2048    455284              381821
	16      4096    464228              261286 <<
	16      8192    298261              534136 << Note: MONITOR switched
						    to show Processor util
						    here, consumes resources
Completed series of tests

	Comments. The results are similar to those of the NE-3200/NE-2000
pair over coax. Server utilization ramped up strongly only when the disk
queue (writing to the server) used all available memory (16MB NW 4.10 box).
Hence the Ethernet board driver was not eating the server alive at either
speed. There is a marked improvment in performance by going from 10Mbps to
100Mbps with exactly the same equipment, even when the server's disk system
is slow.
	Performance suffers when the cpu has to work harder, as when dealing
with an ISA bus adapter and when dealing with excessive disk request backlogs
and when running MONITOR in show processor utilization mode (even on a P100
machine).
	Joe D.

------------------------------

Date: Fri, 15 Mar 1996 13:07:04 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: more performance misc notes

	Taking out 20 min before lunch today I decided to run a wire-melter
test program which sends IPX packets to another board and gets back a reply.
It's a Novell test program, and it does not use Packet Burst (just send and
wait for reply). Sorry, I can't distribute the program.
	With 10Mbps Ethernet the speed is about 550KB/s using 1500 byte
pkts.  With 100Mbps Ethernet the speed is about 2200KB/s, ditto.

	100Mbps Ethernet means 100Base-TX (two pair Cat 5).

	Neither is the capacity of the media (a tad over 1MB/sec and
8+MB/sec, respectively once we include framing overhead). The above figures
basically represent driver plus board throughput, with no disk nor file
system nor NCP interaction at all.
	Looping back through just my own board yields about 3.3MB/sec to
an NE-3200 and 2.3+MB/sec (must be somewhat higher but no notes in front of
me) to an Intel Pro/100 at 100Mb/s. NE-3200's are fast smart boards, and
we must be seeing efficient buffering and loopback. Nothing went onto the
wire in this test.
	Running iozone (or perform3 if you wish, similar results) we can
achieve higher values by using Pburst and hence have fewer wait-for-ACK
intervals per sending opportunity. But "higher" is what I sent out the
other day, say 800KB/sec peak (more like 350-400KB/sec) for 10Mbps, and
1.4MB/sec using 100Mbps Ethernet. Neither of these is full wire capacity,
and the 100Mbps values are especially disappointing.
	Thus a serious component of our lans is the driver and board
efficiency, not that is startling news, but it does help reveal
bottlenecks.
	I replaced the slow SCSI drive system on the test server with a
much faster one, and the throughput numbers reported the other day remain
very nearly the same. What changed was the number of dirty cache buffers
for writes, which went way down because the disk system was keeping up with
the incoming traffic better than the slow disk system. Cpu utilization
still shot up, but I suspect that's polling the disk system for bytes (are
we there yet?).
	If time and opportunity permit I'll discuss this driver throughput
situation with the ODI group next week (assuming they are let loose to
attend Brainshare). We don't expect wire-speed because there are many other
considerations to make drivers hospitable in a general environment. However,
I'm concerned that the 100Mbps technology now becoming available won't be
usable at the capacity that folks may expect.
	Joe D.

------------------------------

Date: Thu, 25 Apr 1996 13:55:45 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Hazards of spanning volumes across multiple disks?

>I guess the subject pretty much says it. I would like to know some of
>your views of spanning volumes over multiple disks. Other than the
>fact that if you loose a drive, you loose the volume, is there
>something I am missing? Is there a big performance hit?

David Pifer, George Hoffman, and Roger Alexander are all correct on
certain points - spanning is faster, but more dangerous unless redundancy
is enabled such as mirroring/duplexing or RAID. Lets take them in logical order:

There's no performance hit with spanning - the bottleneck is nearly
always the physical limits of the drive. 2 drives doubles the throughput,
ect. Of course the exact limits of the performance improvements depends
on the individual pieces, but a year ago 4 1 gig drives on a single fast
SCSI II chain approached saturation. Fast/Wide SCSI should handle about 8
drives, and the new ultra SCSI (40 megabyte channel) should handle about
twice that. When drives get faster, of course we'll have to come up with
different numbers.

Mirroring a single drive is slower on write operations (both drives need
separate writes) but marginally faster on reads if the system supports
SCSI disconnect, so a drive can satisfy a read request while the other
drive performs another operation. Duplexed drives are faster on both
operations than mirrored, but under heavy load all writes must still go
to both drives.

Raid 5, while as fast as spanned drives on read operations while intact
is about 3 times slower than spanning drives on write operations. This is
based on the number of disk accesses required; if you're doing RAID in
software a la the OLD Micropolis RADION implementation, performance goes
to the toilet under heavy write operations, due to the inability of the
CPU to handle the necessary checksum calculations required by RAID 5.
Raid 5 also takes a serious performance hit on read operations when a
single drive is lost but can actually speed up, due to disabling parity writes.

By spanning drives you roughly double the probability of volume loss with
2 drives, with 4 the probability is roughly 4 times, ect. I used to work
for a fool (personal opinion only) who built a 7 gig spanned sys volume,
no redunancy. And Arcserve 5.00 problems. He lost a weeks work because of
it, and continued. We lost 3 drives total out of that system in 4 months,
then I was out the door. Lesson? redundancy rules!

When you mirror drives, consider duplexing. Somewhat safer, but the big
advantage is that it's faster. The data has to be sent twice (once to
each disk), and during that time nothing else happens. In general that
double send is handled better by the EISA or PCI bus than the SCSI
channel(s), and the system can process up other requests at the same time.

Remember that these extra controllers and drives cost money, but it's
less than it used to be. High quality RAID controllers can be had for
under $2000, and drives are about $250/gigabyte. Consider that a 3 gig
RAID system would cost $3000, while a low end mirrored system would only
cost $1900, assuming $400 for a controller; duplexing the same system
would cost $2300. The crossover point is for a 6 gig system with these costs.

The final point is single and double points of failure. With RAID, you
have a single point of failure that doesn't exist with duplexing - the
controller. Yes, I've had 2 fail on clients, and we couldn't get
replacements, so when you're pricing things out make SURE you have a good
source, preferably a hot or cold spare on site. The drive situation is
less scary, but still real - most raid implementations will fail if you
lose any two drives; in our 3 gig example duplexed system you could lose
1 controller, any one drive or even up to one adapter and 3 drives!

There are good reasons to do RAID in many cases, but be sure you're
educated about them before choosing.

------------------------------

Date: Sun, 28 Apr 1996 19:08:44 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Hazards of spanning volumes across multiple disks?

Andrew,

>I am a bit out of date but the last time I heard a Compaq Propaganda
>Presentation (about 1 yr ago) I was told that nothing was saturating
>the EISA bus on their SMART SCSI Array Controller, I would be
>interested in more details.

Compaq is correct in their statement, however it can and does become
bottlenecked on the SCSI bus. Big difference. They do use 2 on the single
card, so you could reasonably have 8 drives on the single card before the
SCSI busses start suffering from saturation. Their statements were
directed towards their lack of a PCI implementation for the RAID
controller; however you may note that they now have this controller in a
PCI implementation.

>>Mirroring a single drive is slower on write operations (both drives need
>>separate writes) but marginally faster on reads if the system supports
>>SCSI disconnect, so a drive can satisfy a read request while the other
>>drive performs another operation. Duplexed drives are faster on both
>>operations than mirrored, but under heavy load all writes must still go
>>to both drives.
>>
>>Raid 5, while as fast as spanned drives on read operations while intact
>>is about 3 times slower....
>
>I am not familiar with the RADION implementation you mentioned but is
>it not correct that the more spindles on the array controller the
>faster the performance, so even though RAID 5 is not as fast as
>duplexing it can still be an increase in performance.  And I think
>the Compaq SMART Array Controller with 4mb cache means that you do
>not write direct to the HDD array, but you write to memory.

1. Where did you hear that more spindles were ineffective? I'll direct
you to a white paper by DPT and another from IBM called Server
performance tuning, from about 2 1/2 years ago that directly challenge
your statement.

2. I never said that DUPLEXING was faster than RAID on write operations,
but rather that SPANNING was.

3. The cache on the Compaq Smart SCSI Array controller is there primarily
to do checksum calculations. The bottleneck here is not usually the
processor write to memory, but rather the end write to physical hard
disk. A "reasonability" test to convince you might be the fact that ALL
performance optimizations of the disk channel in various OSs relate to
caching information to reduce reads, caching partial writes to reduce
multiple writes of the same block, and of course elevator seeking. I'll
refer you to the same two white papers and an additional one; the March
'96 Appnote written by Compaq regarding high performance servers with
over 1,000 users. They had a single processor 4500 with FDDI cards,
multiple array cards  and lots of ram servicing 497 netbench clients. The
estimated ratio was 1 netbench client equaled 5-10 real users, this
equates to servicing 2500-5000 users as a primary server.

The interesting thing about these tests was that they were able to max
out the CPU at 100% utilization, but the EISA bus was not saturated and
performance continued to increase with additional clients, thanks to
busmastering adapters. Also remember that Microsoft is quite proud of the
fact that NT cannot take advantage of busmastering except in the disk
channel; it would take a sizable multiprocessing server to equal this
performance under NT.

>>The final point is single and double points of failure. With RAID, you
>>have a single point of failure that doesn't exist with duplexing - the
>>controller. Yes, I've had 2 fail on clients, and we couldn't get
>>replacements,
>
>I have had failures with RAID controllers, most notably the DPT
>Controller, but they are an expensive item to have 2 of, and once you
>start thinking about mirroring RAID 5 systems your system must be
>pretty critical and such options as spare servers

I wasn't advocating mirroring RAID 5 arrays (the proper term is
duplexing), but rather pointing out a shortcoming of hardware raid. I've
had failures with both DPT and Compaq array controllers, with resulting
severe problems for the clients involved due to lack of immediate
availability. You are quite correct in pointing out the need for hot (or
cold) spares. The primary issue is to have a disaster recovery plan, to
have a clue and the necessary pieces available, if you like your job or company.

Thanks for replying!

------------------------------

Date: Tue, 30 Apr 1996 23:20:10 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: PC Heat output

>We are trying to estimate the Heat output of an average PC (Server type)
>to calculate the required amount of AC we need to place into our new
>computer room.
>Anybody have any ghuesses?
>The engineer we are working with is estimating 1000 BTU per PC. Does
>that seem reasonable?

Well, a pre energy star desktop uses about 150 watts, half of which is
from the monitor. I'd guess a high end server would use about 250 watts
as a ballpark. (Additional RAM, HDs and an Intel bacon cooker). Now 1
watt=3.413 Btu/hr, so it should pump out about 850 Btu/hr, so he's  right
in there.

------------------------------

Date: Wed, 1 May 1996 17:05:13 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet

>  I attended a meeting today to discuss the network implementation in a
>new building.  Being concerned with costs, I'm proposing that we rely on
>switched 10Base-T.  However, the consultant involved with the project
>asserted that virtually nobody installing a network in a new building
>nowadays would implement 10Base-T in any form.
>  Our bandwidth needs are not especially intense.  We have a
>client-server database (oracle NLM) shared among 20 to 25 users, expect
>internet access to become more and more important, and otherwise have pretty
>typical needs.  Our network is unlikely to grow beyond 125 users.  It seems
>to me, that with two robust servers, and a 10Base-T switch in the data
>center, our needs should be met well into the future.
>  Although I have no reason to believe that our consultant has anything
>to gain from seeing us throw away money, I'm skeptical of the need for
>100Base-T in our environment.
----------
	Perhaps you are misunderstanding each other by using the wrong
jargon.
	What is meant is the wiring, CAT 3 vs CAT 5, and how many pairs,
and distance to wiring closets. 100Base-T<whatever> is still new and much
overpriced and underdeveloped. What you buy thus depends on your financial
status, plus your willingness to risk using fluid technology, plus what your
demands will be three years from now. Certainly wiring for CAT 5 and 100Base-X
distances is a wise move, even if you install no matching electronics at
this time. Recall that the time constant for computing is about 2.5 years,
within which span capabilities at least double and demands more than double.
Networking gets caught dealing with something closer to their product.
	Joe D.

------------------------------

Date: Thu, 2 May 1996 13:47:48 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Acronyms - NetTech

>Can anyone tell me what "RJ" (as in RJ-45) and "BNC" stand for? Had a student
>ask in a NetTech class and couldn't answer (he couldn't have asked me about
>"AUI" or "DIX" or "RG" of course <g>)!
---------
	They are historical names for connectors, as we all know. BNC has
a heritage dating back to the '30's and the real origin is lost in the sands
of time (most often attributed to initials of the guys inventing it, not to
the US Navy). RJ's history I don't know, but it is telco-speak. Normally
J's are jacks (socket, female, the wall plate end of things) and P's are
plugs (male, cable end things). By convention cables have male connectors
(plugs) and boxes/chassis/other-heavy-things have female (socket) connectors.
That is to prevent exposing high voltage on such boxes as well as to avoid
bending pins during shippment. IBM PC engineers never learned.
	There is a TNC connector which is a BNC with threads rather than
bayonet attachment. And a great many more Radio Frequency connectors. The
RF guys regard BNCs as miniature type N connectors (the things used on
RG-8 "thick wire"), even if type N's are threaded. Notice something else:
we say "BNC" and "type N" as units, not "type BNC" nor "N."
	Computer professionals in the US should also be familiar with various
Hubble connectors which are AC power mains items, a rather large set of them.
	The technology world is full of such names of important objects,
and those names often have little to do with defining the object in English
words. Thus eventually names are treated as technical words without internal
construction (they are "atoms" in the CS view, or elementary particles in
the Physics view). Our personal names are treated the same way, right?
	Joe D.

------------------------------

Date: Mon, 6 May 1996 13:48:35 -0400
From: Larry Hansford <hansford@ERINET.COM>
Subject: Re: tp cable question

>... The noise reduction is taken care of by the twists in the cable
>pair, not the drain or shield wire. More twists/unit length is the main
>difference b/t cat 3 and 5, I think. An improperly installed (grounded
>at both ends) ground wire, or one poorly maintained can dramatically
>reduce the systems immunity to electrical noise. If the ground is lifted
>for any reason, the shield can begin acting as an antenna for RF emf. I
>believe the purpose of the shield is not to reduce noise so much as to
>provide protection to personnel in much the same way as the Ground wire
>in the Line outlet protects the Happy Administrator or User from shock.
>Since currents induced in the shield or drain wore can be substantial,
>some means to limit these currents must be employed, like the little
>ferrite core that surrounds the video cable b/t monitor and PC.
>Sam Martin

As I recall from my electrical engineering studies, Twisted Pair wires
reduce RF noise interference.  Shielded wires reduce electro-magnetic
noies interference. Shielded Twisted Pair wires attack both fronts.
CAT-5 cabling does not normally have a grounding wire in the cable,
and comes with either a PVC or Plenum jacket.  Also, as I recall, the
ratings for the CAT 3-5 cables are:

CAT-3   Up to 10 Mbs
CAT-4   Up to 20 Mbs
CAT-5   Up to 100 Mbs

These ratings are becoming somewhat blurred with newer technologies,
though.

------------------------------

Date: Mon, 6 May 1996 19:50:31 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Nobody Know the Trouble I've Seen

>I recently upgrade my NW 3.12 server from a Compaq ProSigna VS to an HP
>Netserver LH.  The old system was a rock(it never crashed). The New system
>however is a different story.  It stops processing frequently. What I mean
>is the server doesn't abend it just freezes.  I'm at my wits end trying to
>narrow down the problem. I did upgrade my Arcada backup exec to the
>enterprise edition (Arcada said all my NLM's where up to date.) Other than
>that everything software wise is the same or newer than on my old server.
>I've downloaded the latest patches etc. from Novell.  Here is my config:
>
>P133
>2 4GB hard drives mirrored on the HP backplane. - Latest Adaptec drivers
>2 intel 100b NICS          - latest driver from Intel.
>1 3com EISA 3c5x9 card     - latest driver from 3com.
>1 2940 PCI controller card - latest driver from Adaptec.
>1 HP Surestore 6000 ext.
>
>The hard drives are on the HP backplane and the Surestore is on the Adaptec
>card along with a Toshiba Cdrom drive.  The CDROM is NOT utilized under
>NW3.12.
-------------
	A suggestion is replace the 3Com board with a regular ISA unit,
say an NE-2000 clone. Those 3Com boards are pretty rough on servers and
are not recommended for such service.
	A second suggestion is tinker with edge versus level triggering
of the PCI boards. Motherboards vary as to which works better.
	Similarly, tell the Intel drivers to not transmit until a whole
packet is ready. And tell all PCI boards to get the heck off the bus
fastest when their residency has expired.
	Finally, though Toshiba CD-ROM players have a decent SCSI
controller just being plugged in makes them active. If in doubt remove the
unit completely. I presume you have been wise enough to use the active
terminator shipped with your HP DAT drive; good.
	Joe D.

------------------------------

Date: Mon, 6 May 1996 22:39:14 -0400
From: Glenn Fund <gfund@HOMENET.ULTRANET.COM>
Subject: Re: Lan InteGrity Server....

>I was wondering if anyone out in the Novell World have heard or
>implemented Network Integrity's Lan Integrity server? The product
>provide an instant stand-in 15 seconds after any server fails (up to
>12 servers). In addition, it backs up all files from all servers to tape.
>I am looking for comments from anyone who has purchased this solution.

I have installed it.  It does take a little effort to get things up and
running, especially stand-in printer support.  However the product is
virtually transparent and works just about automatically when you have it
set up.

As a point of info, 12 server would likely be too many to support unless
they are all very small and their data does not change that much.

My rule of thumb is that you can add servers up to about 40-50GB for an
effective LANtegrity installation.  There is no problems mixing 3.x and 4.x
configurations in any user denomination.

Great for Intel based NetWare users.  MAC backup support is there, but
stand-in for MACs is not transparent today.

------------------------------

Date: Mon, 03 Jun 1996 08:51:21 -0700
From: Floyd Maxwell <floyd@direct.ca>
To: netw4-l@bgu.edu
Subject: Re: 100% Server Utilization

>When I do a XCOPY on a workstation with alot of files to copy my server
>goes to 100% Utilization. It takes for ever to copy the files but it
>does copy them. Then the server goes back to normal??? Can anyone help
>me with this problem???

Check the Redirected Blocks in Monitor.

If a hard drive surface starts to fail, NetWare will use reserve
blocks.....but not before it does a serious amount of disk churning.
And after the Write To Disk delay, NetWare becomes *very* earnest
about trying to write to disk.

If your drive is creating a bad block per minute you could be sitting
at 100% utilization forever.

------------------------------

Date: Tue, 11 Jun 1996 01:12:33 +0200
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: Random Abends from FileServer

>After FINALLY making the TCP/IP routing work I came across an other
>problem:
>
>RANDOM abends: Page Fault Processor Exception in different processes.

According to some this most probarly indicates a hardware failure.
Did you open up the server by any chance? In other cases: suspect the
software you last installed and word backwards from that.

>Here's the fileserver it's happening on:
>- Big Tower model connected to UPS
>- Motherboard: AP5C/P
>- Processor: Pentium P133
>- Memory: 32 Meg
>- Hard Disk: SCSI 4 Gig
>- Users: 5 continue, 30 all together (not happend yet)
>- Nic's: 1 3-Com Etherlink III PCI (100 Mbit UTP-Only)
>	    1 AMD Combi Card (PCI 10Mbit, coax connected)
>	    This card is loaded by PCNTNW.LAN ??

Does it work when you kill the PCNTWN.LAN? I never tried to troubleshoot
these cards. I just replace them with 3Com and it works.

>- Scsi: Adaptec AH2942
>- Diamond Stealth PCI Video Board (Don't laugh)

Put this card in a PC and replace it with a standard VGA card. You don't
need anything more so why use anything more and risk conflicts?

>- Pserver running with a HP LaserJet 4SI PS
>
>At first we thought it was a interrupt problem: File Server kept abending
>with Interrupt Service Routine's. We changed some intterupts witch, after
>taking a look into the machine, where conflicting.
>
>After that the Fileserver kept abending with other processes like SMDR 2
>and more of them. We called the company who installed the machine and the
>COMPLETE (except for the Power supply and the Nic's) machine was replaced
>with a P166 and 64 Meg of memory. Because the Motherboard had some errors
>we ended up with the old motherboard and the new Memory and processor.
>The Problem just got worst.

Replace them back to the original configuration (that worked).

>Again the company replaced the motherboard, Video board, SCSI, Memory and
>processor. Again, the problem got worst. old motherboard back, new
>processor (P133 this time) and old memory back. The machine did work a
>while and with the Domain thing loaded it is workable.

Back to what it was before when it worked.

>I applied the 410PT3.EXE and the 410IT6.EXE patches but no luck. Then,
>our programmer said, put the board in Fail Save mode. And, IT WORKS.
>Although loading a NLM takes ages the users don't notice a thing and the
>machine worked fine all through the weekend. Processor speed at the
>console says 150.

- Go back to where the server worked OK and work from there.
- Don't solve problem by troubleshooting effects.
- Try to get a solution for the real problem.

>Question: Are there configurations which Novell Can't Handle??

Are you sure the BIOS can handle it???

>Question: Can Novell handle a Pentium?

Yes

>Question: Cache on the motherboard, can Novell handle it?

Some say disabling the second level cache or external cache helps.
But when you had a working fileserver go back to that point and work
from there.

>Although the NIC's where not replaced, I would sure like some idees on how
>to handle this problem.

- You don't have any use for a PCI VGA card so replace it with a standard
one.
- Put your networkcards in the first slots.
- Go back to minimum requirements and work from there.
- Review your BIOS settings with the book in your hand.
- Disable powersave modes.
- Remember that PCI isn't that auto-configuring at all. It can and will
cause problems when it has to handle a situation it isn't designed to
handle. What it can't handle depands on a lot of things. So go back to
basics and take it one step at a time.

------------------------------

Date: Mon, 24 Jun 1996 08:43:58 +0200
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: NOVELL Digest - 21 Jun 1996 to 22 Jun 1996

>I have a problem:
>NW 3.12 APC 1200 Newest Patches.  30 Stations are on a COAX (ugh, we
>inhereted it).  Stations drop, the FS HARD locks.  I have put a tester
>on the coax wire, and they are getting spikes of 500-800mv of AC on
>the line...  I think 14mv is the limit.

Did you check the length of the cable with a TDR meter ? It shouldn't
be longer then 185 meters.

>I have done the following:
>It is a old school. With poor power...
>
>Grounded both terminators,  don't know how well the ground is though...

Ouch, only 1 side grounding is legal, 2 side grouding is _dangerous_
since it can create ground-loops.
Grounding is good with only a resistance of 1.5 Ohms and lower, let
you cabling contractor measure it.
Remember, human live is involved!

>UPS on the FS, CD Tower, Monitor etc.
>
>Surge Bars on the ws, they const. Show red lites, which mean they are
>SUPRESSING...
>
>I am lost other than rewire, get voltage regulators for the ws's or try
>APC COAX Surge supressors, but they are expensive...

Let a eletrical cabling contractor investigate things, all these
power surgers & so on are just suppressing, not solving the causes.

------------------------------

Date: Wed, 26 Jun 1996 08:18:08 +0200
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Extended BIOS Translation > 1GB = ENAB

>I had the same problem with my server: extended BIOS translation for
>drives > 1GB was enabled at the card level, and my network was also slow.
>Not only that, but EVERY time we brought it down, we were also having to
>do a vrepair and remirror, and the remirroring took over 20 hours!
>
>Luckily the server is duplexed, all the way back to the controller, so
>what we did was change the translation on just one controller and then
>remirror the drive on that controller to the drive on the first controller
>(unaltered).  It remirrored really fast this time (4 hours as opposed
>to 20,... they're 9GB drives).
>
>We then left the controllers in that setup to see if anything got lost,
>before attempting the same on the other controller.  We were supposed to
>do the second one last month, but we never got around to it.  However,
>believe it or not, the server is running great now, no more vrepairs, no
>dragginess (except when ARCserve decides to do something uninvited in the
>middle of the day, but that's another story...), and the drives stay in
>sync when we down and bring back up the server.

You were fortunate...

>Before trying this stunt I researched the problem into the ground and got
>some conflicting answers from HP (we have HP Netserver LH 5/100),
>Micropolis (drives), and Adaptec (controllers).  HP said when I disable
>translation I lose everying and have to reinstall NetWare, etc.

With one drive that would be true. With the mirroring process it
would be possible to take the data from one disk to the other.

>Scared me half to death because I DID change it at one point, with HP tech
>support on the phone; turns out as long as you don't WRITE anything to the
>drives after you change it you don't lose anything.

Correct.

>HP also told me that one of the problems with leaving extended BIOS
>translation enabled at the card level when you run NetWare, besides the
>slowness due to the redundant translating, is that as the drive fills up
>you start to lose files and also end up having to do a lot of VREPAIRS,
>until eventually you lose just the right files to make your volume
>unusable.  Yikes!

True.

>Adaptec and Micropolis told me I'd also have to low level format the
>drives, whereas HP said emphatically not to.

HP is right. Low-level formatting is done by the disk manufacturer
before the scsi interface board (pcb) is attached to the bottom of
the drive. After this board is attached, the firmware reads in the
defect-table and remaps the bad sectors.
After this, it is very difficult to even format through this pcb.

>And then colleagues at my
>local NetWare users group told me that they run NetWare with extended
>BIOS enabled at teh card level all the time and never run into problems
>with it.

They are playing with explosive material & should read Adaptec's
documentation that comes with the card.

------------------------------

Date: Sun, 30 Jun 1996 22:04:05 -0500
From: James Federline <federlin@CHEM.UMN.EDU>
Subject: Re: Comments requested on new server spec.

I'll give 'er a go.

>Motherboard      ASUS P/E P55T2P4D (4PCI/4EISA/1ISA) Triton II Bios

No real experience, but I did consider this board before I received an
accellerated deadline, and opted for a Compaq ProSignia 500 - the
"pre-fab" solution. :-)

>Cache            512K Pipeline burst COAST module
>CPU              Pentium 100

Spend the extra for a 133. That's where the sweet spot is right now (at
least it was on Friday!) for price/performance. NDS ops are only going to
get more numerous, and any server-based tape backup system or database will
gobble up all the power you can throw at it.

>Memory           128MB parity RAM

Parity is a good choice these days. Better is to have a system that
supports manageable ECC RAM, like Compaqs - they let you know about
failing RAM before it's problem. But that's hard to come by on a tight
budget...

>SCSI Cards       2x Adaptec 2940UW PCI
>		  1x Adaptec 2742A EISA

I've never had 3 SCSI cards in a single machine, let alone 2 PCI and one
EISA. I kind of scares me as a matter of fact. I've run CDROMS and tape
devices on the same SCSI bus with both mirrored and duplexed hard drives,
running ARCserve with nary a problem (and ARCserve would have broke it
given the chance). But if you can make it work solidly, it'll probably be
bullet proof.

>SCSI Devices     2x 4GB Fast Wide SCSI II Fujitsu 2934 or 2954 HDUs
>		  Quad speed SCSI CD-ROM Drive
>		  Sony SDT5200 DAT Drive

See above. Fuji's are nice, rock-solid drives. I've got five of them that
have been on for 2.5 years straight w/ 0 probs. No experience with the
Sony DAT. By all means, now matter how stingy the client is w/ the cash,
don't subject him to WangDAT.

>Ethernet Card    3Com 3C590 10base2
>Ethernet Card    3Com 3C595 100baseTX

Experience has shown that the 3Com cards are harsh on the bus/CPU (too
many interrupts to the CPU). No real experience with the 590, but the
100Meg card got tossed here in favor of an Intel Pro100B 10/100. It's
much smoother in the line of duty. Also, the 3Com 595 will not do
full-duplex at 100Mbps, just at 10Mbps, if this may be in your future,
esp. with server-to-server links. (A 3Com engineer was called for this
info). The Intel card will do this.

>PSU / Case       Full Tower, Multiple cooling fans, 300W
>		  with 10 5.25" drive bays and 4 3.5"

Check out PC Power & Cooling if it fits in your budget. Nice, cool solid
containers for circuit boards.

>(basic mono VGA screen and controler, KBD etc).

>The board is rated upto a P166 and there is space for a second CPU,
>although I doubt we'll need it.

Think seriously about making that chip a 133.

>The two disk drives will be duplexed into 1 volume using the AHA2940s.

If the system (or users, or admins) might have any chance at all of filling
the disk unexpectedly, seriously consider breaking the huge SYS: into
SYS: plus a data volume. NW, esp. 4.1, gets really cranky if disk space
gets down low on SYS:. Sometimes abends.

This statement is nullified if you simply mistakenly interchanged the
term "volume" with "partition". Even so, I'd still recommend devoting a
smaller volume to SYS:.

>The DAT drive and the CD-ROM will be on the AHA2742. There will be two
>of these machines linked together by the 3C595 to provide a server to
>server link, which we will use to backup one server to another through
>the day.

The Intel card will suit this need much better - less CPU utilization on
both servers, and the option to go full-duplex is here now. 3Com is
simply saying they will be adding this functionality.

------------------------------

Date: Wed, 14 Aug 1996 16:35:38 -0700
From: Jerome Ware <jerware@NETCOM.COM>
Subject: Re: One volume or many

>I would like to hear opinions on the topic of "One volume or more."  I
>am responsible for many servers which have 5-8 volumes each.  I'll be
>migrating to 4.1 by year end and would like to restructure the mess.
>However, I would like to hear your thoughts on whether one large
>volume (other than sys) is better, more efficient, more reliable, or
>worse than many volumes.  We are Win95 and MAC based.

I use 1 large SYS single drive always, for very small installations. Dept.
server or small company. (go up to 4G) Found easier to maintain, everyone
understands that if drive fails its 4 - 6 hours of downtime. Don't even
try duplex/mirror stuff, since people who admin such systems usually are
to busy to check mirror failure and a lot of the stuff that kills the drive
can kill both, I've had enough problems with servers downing and the lousy
drive gets mirrored and we lost the whole deal anyway. I don't like
spending time figuring out what died, hardware is too cheap and  tape
restores too fast to make this a worthwhile activity.

Typically anything bigger than a Dept Server I build a Arrayed drive as one
partition, segmented into three volumes. SYS APPS DATA, Sys just has
Netware and related utilitiies that have to be there. APPS has all the
relatively fixed executable stuff and DATA has all the fast increasing
stuff. DATA gets monitored daily and trended for additional space/cleanup.
APPs monitored monthly or as applications are added for sufficent space.
SYS is rarely monitored, (since I no longer store Queues there).. I am fond
of monitoring utilities and hot swap drives, (currently very satisfied with
Compaq Insight Manager and their hot swap drives), so far have been able to
plug in a drive  and have the rebuild complete before the second failed...
For super high availability stuff SFTIII is very nice, though not many are
willing to do the expense...but the drives, partitions and volumes I do the
same way. No one complains about speed unless the wire bogs down and have
FDDI or FAST Ethernet migrations especially for large 4.1 installs. Like
to keep drive letters to the minimum and Windows has helped much in that
respect and WIN95 seems even better...

------------------------------

Date: Mon, 19 Aug 1996 11:22:02 EST
From: "Larry Phelps" <ldp812@FS-4056.NWSCC.SEA06.NAVY.MIL>
Subject: Re: One volume or many

I don't think so.  If you have three drives with a MTBF of x, it
seems that the MTBF of the whole system remains at x (I'm sure the
mathematically inclined might quibble, but it certainly isn't divided
by three).

That said, the M in MTBF stands for mean, so you stand a chance of
getting a failure earlier.  When you have three drives, you triple
the chance that your failure will be before the MTBF.

And no, I do not recommend spanning volumes across drives. #;)

---------

There was a discussion on this topic in a Data General Users Mag. a
couple of years ago.

Basically the Manf. puts a Mean time to failure on that line of
drives, not the individual drive itself.  If you think about it, 80K
MTBF, is approx 9 years.  The Manf. is simply saying they expect a
failure, on average, for every 80K hours their drives are used.

Just divide the MTBF by the number of drives you have, and you get an
estimate of your MTBF.

Otherwise, how could a Manf. put out a figure of 9 Years for a MTBF
unless they test a drive for 9+ years.

So if you have a drive array with 10 drives that have an 80K MTBF,
you can expect a drive failure, on average, about every 8K hours
(almost 11 months or continuous use).

Like was said, this is Mean Time Between Failures, which means your
drive could fail the day you put it in, or it may last 10 years.

------------------------------

Date: Sun, 1 Sep 1996 18:46:27 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Pentium or Pro

>A question regarding the best type of Processor to run NetWare 4.1
>on, does anyone know if their is a performance boost by using a
>Pentium Pro over a Pentium in a server, and which is the best speed
>rating to use. While I'm at it what chipset should a server
>motherboard be using? ie; Triton 1, Triton HX etc.
--------
	Some common observations on this topic, starting with an obvious
one often overlooked:
	o Apps run in clients, with few exceptions, and thus the cpu power
belongs on the clients. Exceptions are tape backups, http daemons, and
similar. A 486-33 EISA bus machine can service four dozen Pentium clients
if done right, as I demonstrate daily in production mode. That means a
Pentium Pro is an expensive space heater.
	o Servers are faster than the wire in many cases, and the
bottlenecks in servers are almost entirely on the bus and perpherial
boards.
	o That means put your money into the bus and those boards. ISA bus
is as slow as they get. Triton-1 chips sets are for cheap desktop Windows
machines things, avoid in servers. Buses of merit are EISA, PCI, MCA, but
be wary of the still unsettled PCI bus (test thoroughly the equipment you
plan using, not generic chipsets). Bus master boards far outperform other
kinds; that's money well spent. Add plenty of memory too.
	o Desktop quicky machines are junk when pressed into service as
NW servers; avoid them. Buy quality because it works better and it's
cheaper in the long run.  Please don't think in terms of desktop Windows
machines as decent servers; that is a wrong frame of reference.
	o If you can't test thoroughly then go for the name-brand server
makers such as HP and Compaq. Those aren't problem free either so shop
carefully and listen to comments by their owners. There isn't a free lunch
in this area.
	o If you have the lan operating already then please pay careful
attention to the numbers. Measure, think, find the important constraints
on your lan. It may be that you don't have a problem to solve.
	o Finally, building a lan is a systems problem, aways with
constraints and requirements competing for available budget. We don't know
those parameters in your case. Chasing one fascinating technical detail is
fun but not exactly solving the overall problem (if any).
	Joe D.

------------------------------

Date: Tue, 10 Sep 1996 20:17:38 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: registering server memory

>I am hoping someone can help me with a small problem I have
>registering memory on our Netware 4.1 server.
>
>I recently installed another 16Mb of RAM into one of our 4.1 servers.
>This server now has 80 Mb total.  In order for Netware to recognise
>this memory, I typed into the console and added to the startup.ncf file
>the line
>
>Register Memory 1000000 4000000
>
>The server responded with:
>
>Additional Memory not added
>The specified memory is already registered
>
>The RAM count when I rebooted the server shows 80 Mbytes but Netware
>only recognised upto 64 Mbytes.   Does anyone have any suggestions as
>to what I can do
--------------
	Well, it turns out that you missed out the most important item, of
what kind of machine is that. We will see why it's important.
	I will guess it is a Pentium box with PCI slots and likely a Triton-1
support chipset. If so it can't cache more than 64MB, because of that chipset
and I think you are stuck at 64MB.
	Let's try harder. Novell has recently issued a patch to obtain more
information from the machine's non-volitle CMOS on PCI matters, and in some
cases that should help resolve memory quantity issues. Perhaps your machine
fits that description, and if so please do get all the patches for NW 4.10
and try again (without the Register Memory item).
	And again, some machines require the Bios to be configured to see
the amount of memory present. The cold boot memory test is nearly worthless
operationally because its information is discarded immediately and not
communicated to real operating systems.
	Fine, fine, etc. Now one last small thing. If Register Memory is
the only way of getting the beast to work then the first argument of the
command is the amount of memory that NW sees by itself, rather than always
16MB (1 million paragraphs, where a "paragraph" of memory is 16 bytes in
Intel-speak). The second arg is the extra amount to register. And one may
have to tinker with NW console/startup.ncf command Auto Register Memory
Above 16 Megabytes=ON. Worth a try.
	Joe D.

------------------------------

Date:	Tue, 10 Sep 1996 10:34:34 -0700
From:	John Lauro <jlauro@umich.edu>
Subject: FAQ update: IDE

SCSI is still preferable, but IDE is ok IFF:

1. You don't plan to ever have more then one drive (or if you do, you
   should add SCSI at that time).

2. Your motherboard supports DMA transfer for IDE and has specific
   drivers for Novell instead of the standard IDE drivers.  This is needed
   to allow the CPU to do other things (such as service network requests
   from it's cache) while waiting on disk I/O.

Also, transfer rates on IDE have improved and (I think, not positive) are
now faster than SCSI.  I don't think they are faster than F/W SCSI yet.

------------------------------

Date: Tue, 17 Sep 1996 17:33:32 -0400
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Re: RAID 5

>With a RAID 5 array can you yank out any of the drives and it will recover?
>Or is 1 drive a backup?  How does that work?  It duplicates data across 5
>drives?

I found a nice description of RAID methods at:
	http://www.datapub.com/dpg/whitepapers/raid/raid0.html
they seem to be selling RAID arrays for Unix systems, but it's good basic
info.

Basically, RAID 5 uses a method called Distributed Parity Block
Interleaving. It "stripes" your data blocks across all the disks in your
array, in parallel, and adds a "parity check" for what should be on that
stripe.  For example, in a 5-disk array, each block exists in a stripe on
all 5 disks.  Each disk's "part of the block" holds 1/4 of the data
contained in the block, plus a parity check of what should be in the entire
block.

If you lose part of a block on a drive, the data can be rebuilt from the
rest of the block remaining on the other drives.  The controller has the
information that remains, and knows what the parity check should add up to,
so it sort of adds the parts of the block that remain and subtracts the
parity check and is left with the original block.  (Okay, not exactly, but
I hope that draws a simple picture of what it does.)

The same is true if you lose all the blocks on a drive (i.e. you lose a
drive) - it can be recovered from the striped parity-checked data remaining
on the other drives.  It just does it for all the blocks.

I think that from this you can see that you have room to lose only 1 drive,
because you need the other 4 (in this example) to determine what's missing
from the parity.

---------

Date: Tue, 17 Sep 1996 19:13:36 -0700
From: "Aaron D. Turner" <aturner@BEST.COM>
Subject: Re: RAID 5

RAID 5 uses an algorithm to place data across the drives.  This isn't the
real way RAID 5 works (the algorithm is far more complicated) but, here's
an example to explain the process:

Say you have a 5 drive RAID5 array.  Say you want to save a 4 bit file
containing "0011" to this array (on a Netware Volume that resides on the
drives).  The following would be written to each drive:

Drive 1: 0
Drive 2: 0
Drive 3: 1
Drive 4: 1
Drive 5: 0  (Calculated Parity Bit)

Now if any of the five drives fail, the file's data remain intact.
Example:  Suppose Drive 3 fails.

Drive 1: 0
Drive 2: 0
Drive 3: ?
Drive 4: 1
Drive 5: 0

By using the parity bit on drive 5, the value of what would of been found
on the missing Drive 3 can be calculated.  Since, Drive 5 has "Even Parity"
(0) and 0+0+1=1 (Odd Parity) the missing bit would have to be 1.  Of course
is 2 drives die, you're hosed.

Raid 1 is different- it just duplicates the same data on two different
drives:

Drive 1: 0011
Drive 2: 0011

Either drive dies, you're OK, both and you're hosed.

---------

Date: Tue, 17 Sep 1996 20:36:06 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: RAID 5

[ Aaron Turner's reply above snipped ]
---------
	Speaking as a person who has never laid hands upon RAID N I do have
a technical comment on the works.
	The nutshell version is: above is a hamming distance of two.
Which translates into the system can tolerate a one bit error in any item
but not two or more in the same item. Hamming distance is the mimimum
number of bits, taken over everthing, which changes one legal item into
another legal item. Thus the RAID 5 XOR scheme described above has a
hamming distance of two.
	To detect an N bit error one needs a hamming distance of N+1, to
correct an N bit error one needs a hamming distance of 2N+1.
	Put this in terms of that RAID 5 item above, and suppose there is
a one bit error (N=1). We know there is an error (an illegal item) but
we don't know where it is (and hence can't correct it).
	The RAID 1 scheme has a hamming distance of two but again there isn't
a way of knowing which drive is bad. The dual copies of the FAT technique
suffers from the same effect.
	To correct the error takes a hamming distance of 3. Think of this
as "legal", "illegal", "illegal", "legal", and we choose the nearest "legal"
item to correct matters.
	Way back in the old days tape drives had both longitudinal and
transfer check bits on 9 track tape. That permitted correction of single
bit errors.
	To read a little more about it, in the context of computer networks
at that, see Andrew Tanenbaum's classic book "Computer Networks." He also
goes on to find the minimum number of redundant bits to recognize N bits
in error and to recover from N bits in error (two different situations).
	Whatever the RAID folks are doing must be more sophisticated than
the common XOR etc example we offer folks, else we could not safely recover
from simple errors. Apparently the "errors" are a missing drive rather than
a drive system suffering transient difficulties (for which I will guess the
RAID vendors hope the drive mechanism will complain, fond hopes that).
	As is obvious, I know zilch about RAID.
	Joe D.

---------

Date: Wed, 18 Sep 1996 03:40:40 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: RAID Levels 4 & 5 explained

	Joe has raised a good point about the theory & practice behind
Level 5 (and Level 4!) RAID. Technically speaking, Aaron Turner's logic
example is a RAID Level 4 with a single parity drive; as opposed to a RAID
Level 5, which has the parity distributed across all the drives. RAID Level
4 provides sustained transfer rates approaching that of pure striping
(Level 0 RAID), but with the added security in that with Level 0 if any
drive goes you're screwed. [BTW, I'm an experienced RAID Level 0 user &
installer on my own and several clients' PowerPC Macintosh workstations &
servers].

	Anyway, the concept of Hamming distance is indeed quite applicable
to network communications over a serial line, where you have  *random*
dropped bits but the circuit is still transmitting.

	Now, let's visualize a simple 8 bit parallel data line, and add in
a 9th wire that sends the parity information. We'll use odd parity in this
example:

	0  1  2  3  4  5  6  7  8  P9
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	1  0  0  0  1  1  0  0  1  1
	0  1  1  1  0  0  1  0  1  0
	0  0  0  1  0  1  1  0  0  0
	1  1  1  1  0  0  1  0  1  1


	We'll now wipe out a one of the data lines, number 3 in this case:


	0  1  2  3  4  5  6  7  8  P9
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	1  0  0  x  1  1  0  0  1  1
	0  1  1  x  0  0  1  0  1  0
	0  0  0  x  0  1  1  0  0  0
	1  1  1  x  0  0  1  0  1  1


	Strictly speaking, we only generate a parity error - The detection.
We don't know "which" data line is broken. If we had some way of "knowing"
that data line 3 was the one that was broken then we can recover the data
in that byte.

	The way RAID Levels 4 & 5 actually works is to  *detect*  the
failed drive FIRST, *then*  apply parity correction to the remaining data.
Remember, we now have TWO pieces of data that we apply: The parity bit
itself and the knowledge which original data bit failed.

---------

Date: Wed, 18 Sep 1996 10:03:05 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: RAID Levels 4 & 5 explained

>As I'm trying to grasp all of this RAID technology/hoopla -- I have a
>simple question. Does RAID5 use more than one parity bit, and if it
>does, how can it store one bit across many drives?

<snip>

>	Joe has raised a good point about the theory & practice behind
>Level 5 (and Level 4!) RAID. Technically speaking, Aaron Turner's logic
>example is a RAID Level 4 with a single parity drive; as opposed to a RAID
>Level 5, which has the parity distributed across all the drives. RAID Level
>4 provides sustained transfer rates approaching that of pure striping
>(Level 0 RAID), but with the added security in that with Level 0 if any
>drive goes you're screwed. [BTW, I'm an experienced RAID Level 0 user &
>installer on my own and several clients' PowerPC Macintosh workstations &
>servers].
--------
	<large omissions>
	To summarize todate:
	If a drive in a RAID array stops working then there is sufficient
information available to rebuild the drive's contents on a replacment.
The system may still be at a hamming level of two, but there is an external
piece of information added to the decision making process, which is that a
particular drive is dead.
	Where all this breaks down and crumbles is when the system reports
errors but no drive volunteers to be the victim. All the drives think they
are fine. A very simple example of this is found in every day life, where
a lan adapter wedges and keeps interrupts off. NW can have mirrored copies
of the FAT being inconsistent (one copy was updated, then the system froze).
I have a particular NE-2000 clone board which did exactly this too many times.
Clearly each drive is happy as can be, yet the disk system is in deep trouble.
	A single parity check drive is sufficient to rebuild a large drive
farm if only one drive fails and we know which one. It won't recover from
internal data errors unless another piece of information is supplied
externally, such as which particular drive is bad.
	And we presume the more serious RAID systems go well beyond the
simple parity check approach and thus allow elementary error correction
without external advise. It takes more than one drive worth of redundant
information, which is a handy rule of thumb when looking at products.
	Joe D.

---------

Date: Wed, 18 Sep 1996 13:23:52 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: Better RAID explanation

	Over the last few days there's been a lot of discussion of disk
array (RAID) levels. To clarify things, there are some good diagrams
located at:
<http://www.soundelectro.com/raiddef.htm>

	There is also a decent explanation located at/near:
<http://www.compapp.dcu.ie/databases/f698.html>
which I copied below.

	One word of caution: There seems to be a bit of confusion between
the implementations of Levels 3 & 4; so buyer beware.

:::::::::::::::::::::::::

RAID disks

The idea behind RAIDs is that instead of using one big expensive disk which
has expensive requirements with respect to power, heat dissipation, we use
many slower, smaller and cheaper disks linked together in a farm and we
replicate or duplicate data across the many disks and issue data requests
to app disks.

In RAID configurations, data distribution among the disks is more judicious
than random and there are a variety of strategies for data striping.

RAID devices appear to the host computer as a single large SCSI or SCSI-2
disk as the RAID controller manages data placement and retrieval. It is
this aspect which makes RAID devices general -purpose.

See Also RAID levels
~~~~~~~~~~~~~~~~~~~~


RAID level 0

RAID Level 0 is data striping across multiple disks with redundancy where
data is striped by the system block size.

Using this approach the number of drives is scalable and to improve access
time and transfer bandwidth the drive motors on different drives may be
synchronised.


RAID level 1

RAID Level 1 implements mirrored disk arrays with the simplest type of
redundancy ... full, mirrored duplication.

The disk array is split into 2 groups with one group storing the original
data and the other group providing a mirror. Within each group data is
stored by interleaving blocks among drives, and drive spindles may be
synchronised for performance.

Disk 1 Disk 2 Disk 3 Disk 4

a c a c b d b d e g e g f h f h

group 1 ... origg. mirror


RAID level 3

Level 3 RAID creates a parallel disk array where data is interleaved1 byte
at a time with a single block (A) spread over several disks (say 4), plus
a separate disk is used for storing parity bits. This is the simplest form
of redundancy and is designed not to be optimal for retrieving lost data,
but that should happen so rarely anyway that it is not needed regularly.
The parity bytes are created as exclusive-ORs and the same disk holds all
parity ... making it a weak link perhaps

This shows how blocks A-D are stored on 4 disks plus a parity ...

A1 A2 A3 A4 Ap B1 B2 B3 B4 Bp C1 C2 C3 C4 Cp D1 D2 D3 D4 Dp `

If a data disk fails its contents can be re-constructed from data on the
remaining active drives plus the parity disk.


RAID level 5

With RAID Level 5 we store data and parity information across all disks. As
with Level 3 data is striped at the byte level and the parity information
is stored by rotating on all drives. By eliminating the dedicated check
disk the performance is increased overall and reliability is further
enhanced as with Level 3 if check disk plus 1 data disk failed, the whole
system failed but with Level 5 this is not so. Drive spindle
synchronization is not required here.

For 4 data disks plus parity, this is how blocks A-E are stored

A1 A2 A3 A4 Ap B1 B2 B3 Bp B4 C1 C2 Cp C3 C4 D1 Dp D2 D3 D4 Ep E1 E2 E3 E4

---------

Date: Wed, 18 Sep 1996 21:52:03 +0100
From: Bo Persson <bop@GANDALF.SE>
Subject: Re: RAID 5

>	Whatever the RAID folks are doing must be more sophisticated than
>the common XOR etc example we offer folks, else we could not safely recover
>from simple errors. Apparently the "errors" are a missing drive rather than
>a drive system suffering transient difficulties (for which I will guess the
>RAID vendors hope the drive mechanism will complain, fond hopes that).
>	As is obvious, I know zilch about RAID.
>Joe D.

Not obvious at all, I'm afraid!  :-)

The raid systems does not offer any additional detection of
disk problems, "just" a way of recovering from a malfunctioning
drive.

To actually verify the data against the parity block, you would
have to read the ENTIRE stripe and recalculate the parity info
for each disk sector read. The performance would be, well...


A benefit "the raid folks" talk about is that with n disks you
can have n read commands active simultaneously. If they
were to verify all reads, it would be more like 1/n.

------------------------------

Date: Thu, 19 Sep 1996 11:12:47 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: DEC Prioris HX5166 and NW 4.1

>We just purchased 2 DEC Prioris HX5166 to be setup as Novell NW4.1
>servers.
>
>Each configuration is as follows ( same setup ):
>96 MB RAM
>1 x Adpatec 2940W PCI SCSI driving a Seagate st15150N (4.3 GB) hard disk
>1 x Adaptec 2940W PCI SCSI driving a Seagate st15150N (4.3 GB) hard disk,
>Sony SDT-500 Tape drive and Toshiba CD-ROM XM-540ITA
>4 x Novell NE3200 EISA LAN card
>
>The drives would be DUPLEX
>
>The problem I am having is when I active 3 NE3200 in NW4.1 and use
>DOS COPY from 3 machines to copy files from each of the LAN card, the
>server will "hang" and <CTRL> + <ESC> would not do anything and there
>is no abend message.
>
>I have checked all the IRQ and all setting are unique.
>
>I am looking for some advise as to what to do next.
>
>I have put in a card at a time but is only successful in activing 2
>LAN cards and I need 4 cards to to to 4 segments.
----------
	First throttle the bus consumption by your PCI boards, which means
reducing the PCI latency or whatever the name is on your system. Ditto for
the EISA bus if the Bios provides such control.
	Second, ensure you really positively have memory quantity set
correctly in the EISA setup (typically a separate floppy disk).
	Third, avoid sharing IRQ wires if possible.
	Fourth, obtain and apply all NW 4.10 patches and updates to utilities,
from updates\nwos\nw410 on the archive servers.
	Fifth, try removing memory above 64MB, because many motherboards can
not deal with larger amounts despite the number of SIMM sockets.
	Keep in mind the fuzzy state of PCI bus implementations. They can
interfere with EISA bus boards by hogging the PCI bus.
	I run a server with three NE-3200 boards plus an Adaptec 2742A SCSI
adapter, all EISA bus, and they work just fine together under heavy load.
The motherboard is a no-name 486-33.
	Joe D.

------------------------------

Date: Thu, 26 Sep 1996 18:37:29 -0400
From: Chris Brown <CBROWN@SEITZ.COM>
Subject: Re: large IDE drive

>I've got a small problem.  I'm setting up a netware 3.11 sever on a
>386.  I've got the server installed and running off of a 200 meg IDE
>drive, and I'd like to add a second IDE drive, but the problem is, it's a
>rather large IDE drive, and the BIOS on the 386 doesn't recognize it, and
>does not have an LBA mode.  So I only get a fraction of the disk space
>that should be available.  I know there are drivers/boot-tricks to get
>DOS, OS/2, Win95, etc, etc, etc to see these larger drives, but these
>programs format the drive, while I need it to be formatted as a netware
>partition.  Is there a way to get access to the entire drive under
>netware?

YES! I have put together several servers with large IDE drives. You
need a new drive interface card.

The one I use is from Promise Technologies, (model 4030) It supports
4 IDE drives and comes with its own bios and netware drivers. Rock
solid, 5 running for 3 years. Just make sure to turn
disk_read_after_write_verify to "off"

Promise tech # 408-452-0948

------------------------------

Date: Tue, 1 Oct 1996 12:29:38 -0400
From: Chris Brown <CBROWN@SEITZ.COM>
Subject: Re: large IDE drive

>>>I've got a small problem.  I'm setting up a netware 3.11 sever on a
>>>386.  I've got the server installed and running off of a 200 meg IDE
>>>drive, and I'd like to add a second IDE drive, but the problem is, it's a
>>>rather large IDE drive, and the BIOS on the 386 doesn't recognize it, and
>>>does not have an LBA mode.  So I only get a fraction of the disk space
>>>that should be available.  I know there are drivers/boot-tricks to get
>>>DOS, OS/2, Win95, etc, etc, etc to see these larger drives, but these
>>>programs format the drive, while I need it to be formatted as a netware
>>>partition.  Is there a way to get access to the entire drive under
>>>netware?
>
>>YES! I have put together several servers with large IDE drives. You
>>need a new drive interface card.
>
>>The one I use is from Promise Technologies, (model 4030) It supports
>>4 IDE drives and comes with its own bios and netware drivers. Rock
>>solid, 5 running for 3 years. Just make sure to turn
>>disk_read_after_write_verify to "off"
>>Promise tech # 408-452-0948
>
>I've also had good results with Promise IDE controllers, specifically
>the EIDEMAX which supports Int 12 and works nicely for duplexing.
>
>I'm curious though, why you say...
>
>>Just make sure to turn disk_read_after_write_verify to "off".
>
>Do all IDE's automatically do a hardware-level verify...or something
>else?

Yes all of the newer (2 years) IDE drives have very sophistocated
read after write, caching, error detection and error correction.
Most will even re-direct bad sectors on the fly. I mainly use
Western digital drives, they have a great tech document that
describes the error algorithims.

I believe the Promise card also does some error checking. So why have
the server do it a third time in software. I've had my server get
real slow and abend with the write verify turned on. I notice an
improvement in performance with it turned off.

And because the WD drives do bad sector re-direction on their own,
I set the Netware Partition hot fix to the minimum of 32 blocks.

------------------------------

