
------------------------------------------------------------------------
NOV-HDW3.DOC -- 19970120 -- 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: Mon, 7 Oct 1996 11:21:13 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: server kept abending ...

>  Please help !!!
>  Our server kept abending and crashing almost everyday after we switched
>from 1 gig scsi hard drive to 4 gig scsi hard drive and installed dual
>network boards (NIC). The server was running just fine with 32 meg of
>memory with 1 gig scsi hard drive and 1 netword board (ne2000). We have
>tried almost everything to fix it and still not working right.
>
>  The following is the same old  message we saw on the console's screen:
>	System halted Saturday Oct 5, 1996 ....
>	abend: AllocateNonMovableReturnableMemory discovered invalid memory
>		block segment.
>        OS version: Novell Netware v3.12 (....)
>        Running Process: ngwofs_p   4 processes
>        Stack: ...
>
>We have a server running 3.12 with 64 meg of memory. We have 1 scsi
>controller (load aha1520.dsk) with a 4.0 Gig scsi hard drive (st1550).
>We installed 2 network boards in this server; bind 1 ne2000 board with ipx
>and bind 1 3c503 with ethernet_ii and ethernet_snap. IPTUNNEL and TCP/IP
>stack were also loaded, too. We are running Groupwise 4.1 on this server
>with the following modules loaded: ngwofs,ngwads,ngwms,ngwasync,ngwapi.
>We have 1 pc running smtp gateway (from TFS). Users can use their mailbox
>through the shared drive on the NT SERVER (which in turn use the GATEWAY
>SERVICE FOR NETWARE).
--------------
	I believe the poor server is completely overwhelmed by events.
	Let me make a brief list of worrisome points.
	The Adaptec 1520 controller is a port i/o non-bus master controller,
and will consume a very large number of cpu cycles to do work. I would not
recommend it even on a client machine.
	The controller may not support 4GB drives, please check Very
Carefully. Do not enable DOS head/cylinder/sector mapping!
	Ensure the disk drive cache is turned off. See Seagate for the util.
	The 3C503 board is a couple generations old, nice but hardly up to
the demands of today's networks. It too consumes lots of cpu cycles, and
it has a history of going to sleep under stress.
	The NE2000 is an OK board, but it too uses lots of cpu cycles to
work. There must be some reason you have two boards. There must be some
compelling reason to use IP tunneling. There must be some unstated reason
to use frame Ethernet_SNAP (Appletalk only, for the most part).
	Groupwise wants a very large amount of cpu and memory resources.
That imposes a signficant burden on your already overloaded server.
	I'll wager that your server is not fully patched and brought up to
date, to judge by the crash message.
	Joe D.

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

Date: Sat, 19 Oct 1996 09:17:37 -0700
From: "William C. Holt" <b.holt@WORLDNET.ATT.NET>
Subject: Re: IDE drive

>There is alot of discussions regarding high utilization with SCSI
>drive.  I recently installed a NW4.1 server on a DEC LX 5166 server
>with 2 GB IDE drive.
>
>I am having high utiliazation and track it down to the IDE controller
>which is writing to disk all the time.
>
>Any suggestion as to why this is so?

Your IDE drive is functions like a serial device, that is it cannot do
concurrent read and writes, whereas a SCSI drive is a parallel bu and can
read/write at the same time.  The worst caes senario is that you have such
high utilization on the drive that bad data coulld be written to the disk
before the being verieied/redirecred and you have a corruption problem.
Also the large block IDE devices aren't really bigger drives, it's just as
the nem says a larger block w/the same size/density of sectors (you do the
math).  This WILL eventually cause you problems if you run disk compression
and block sub-allocation on.  Additionally the larger block inherantly
cuase lead to more "slack"/wasted disk space do to the ratio of block v.
file size.

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

Date: Mon, 21 Oct 1996 17:56:17 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Redirection and RAID 5

>>When installing 3.12 on a HP Netserver LS 5/166.  This is configured with
>>the drive array controller to RAID Level 5.  When creating the netware
>>partition, should I leave any redirection blocks?
>
>Well, FWIW, my Compaq Proliant 1500 has a RAID 5 and .1% of available
>blocks are set. Maybe someone else with more info will post.
-------------
	I have always reduced redirection blocks to the minimum, which is
24 or 31 (have to look) on SCSI drives. SCSI drives will transparently map
away bad blocks all by themselves, and when Novell's ST-506 class bad block
mapping kicks in to help the drive is ready to die within hours. Think of
the Novell item as a) ancient history, and b) a comfortable cushion to
run backups that day (and then yank the drive). As they say, been there,
done that, have the bad drives to prove it.
	Folks stuck with IDE thingys may be dependent upon Novell's material
since in most ways IDE is ST-506 spiffed up a little. Anyone have some direct
information to help here?
	Joe D.

---------

Date: Mon, 21 Oct 1996 18:32:27 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Redirection and RAID 5

>>	I have always reduced redirection blocks to the minimum, which is
>>24 or 31 (have to look) on SCSI drives. SCSI drives will transparently map
>>away bad blocks all by themselves, and when Novell's ST-506 class bad block
>>mapping kicks in to help the drive is ready to die within hours. Think of
>>the Novell item as a) ancient history, and b) a comfortable cushion to
>>run backups that day (and then yank the drive). As they say, been there,
>>done that, have the bad drives to prove it.
>>	Folks stuck with IDE thingys may be dependent upon Novell's material
>>since in most ways IDE is ST-506 spiffed up a little. Anyone have some direct
>>information to help here?
>>	Joe D.
>
>Pardon the ignorant question.  Is drive redirection only pertinant to RAID
>level 5  Arrays, or would it also pertain to Duplexing and Mirroring?
---------------------
	Appologies for not being clearer. SCSI drives, the stuff we buy
from Seagate and similar, handle bad block redirection right on the drive.
The SCSI controller doesn't know it happened. If you have a SCSI diagnostics
program then ask for the manufacturer's defect list and then the "grown" list
(stuff detected since shipping).
	Thus SCSI drives look perfect until they die, almost like watch
batteries and movie stars.
	Duplexing, mirroring, RAID-ing, all are collecting drives in various
patterns, and hence they know nothing about self healing, and most often
they do no repairing either (they have no collected wisdom about drives
and no place to store it permanently either).
	Consequently, when a SCSI drive shows bad blocks to the world in
normal use it has already consumed all its spares for a track and that means
things are in bad shape and unlikely to improve. Experience indicates the
drive should be replaced immediately, and next time direct a fan on it please.
	Joe D.

---------

Date: Mon, 21 Oct 1996 19:31:15 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Redirection and RAID 5

>Thanks Joe.  Speaking of fans, I have 4 IBM Ultrastar Fast/Wide 4.5 gig
>drives and these guys run HOT!  I mean really hot.  According to IBM this
>is normal because of the drive rpm speed....  Is this your (or anyone
>else's) opinion?  Is this normal that the drives run ot enough that if you
>try to touch one directly after shutting it down, it's too hot to touch?
------------
	New to large SCSI disk drives Robb? High thermal output drives have
been the normal condition for the past several years. If left to be hot they
die, period.
	Put fan(s) on them so they run cool and they will last. It's as simple
as that. Computer case fans do nothing much here; the fan has to blow on the
drive directly, with plenty of space around the drive for air to flow (in the
case, over the drive, and out again, not just round and round the case).
	If your drives are hot to the touch that's very bad and needs fixing.
	Joe D.

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

Date: Thu, 24 Oct 1996 14:15:00 -0400
From: Dan Schwartz <dan@SNIP.NET>
Subject: Speaking of fans...

>>	Consequently, when a SCSI drive shows bad blocks to the world in
>>normal use it has already consumed all its spares for a track and that means
>>things are in bad shape and unlikely to improve. Experience indicates the
>>drive should be replaced immediately, and next time direct a fan on it please.
>>	Joe D.
>
>Thanks Joe.  Speaking of fans, I have 4 IBM Ultrastar Fast/Wide 4.5 gig
>drives and these guys run HOT!  I mean really hot.  According to IBM this
>is normal because of the drive rpm speed....  Is this your (or anyone
>else's) opinion?  Is this normal that the drives run ot enough that if you
>try to touch one directly after shutting it down, it's too hot to touch?

	The problem lies in the 7200 and 10,800 RPM mechanisms: The heat
thrown off from the spindle bearings is too much for many cases. Also, the
hysterisis losses in the magnetic material in the heads and the platters
cause heat to build up, too. At the higher data rates in 7200 RPM drives
these losses cannot always be adequately dissipated in a given size
package... And you end up with Quantum Grand Prix meltdowns.

	The video boys have known this for a long time: When you start to
get those massive sustained transfers from Level 0 RAID arrays you can
easily cook a drive that doesn't have adequate cooling. This points the
finger to hysterisis losses in the magnetic materials.

	The fine folks at FWB <http://www.fwb.com> have a simple rule:
Never install a 7200 RPM drive in a case smaller than a Quadra 950. If you
put a 7200 RPM drive into a Quadra 840AV/PowerMac 8100 case, then it's just
ready to fail within 2-3 months... And I've seen it too many times.

	One of the best ways to extend the life of a hard drive...
Especially a 7200 RPM or 10,800 RPM drive is to turn it on it's side, with
the head arm on the top. This will eliminate the axial load on the spindle
and head arm bearings; and also will reduce the current pulses required to
actuate the head arm to position the heads... Mr. Gravity will work against
the return spring force, requiring smaller current pulses in both
directions of travel. [If the arm is towards the bottom, then gravity will
act *with* the return spring... This will cause less current to retract the
heads; but twice as much current (and 2^2 = 4 times the energy dissipated)
to move the arms towards the center.]

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

Date: Wed, 30 Oct 1996 07:00:00 GMT
From: "Forrest H. Swick" <fswick@MAIL.UNIVNORTHCO.EDU>
Subject: Re: Notebook Server Recommendation

>Do you have any recommendations for a notebook to be used as a
>NetWare 3.12 10 User fileserver?  Do you know any particular Do's
>and Don'ts you could share? I could not find a NetWare YES
>certified notebook at the Novell site.

When I was in working in DC a few years ago year our Network Service
Support group company had a laptop with swapable hard drives.  The
drives had different versions of netware on them -  2.15c, 2.2, 3.0, 3.1,
3.11 and when it had just come out 4.0.  They carried the laptop in a
hard case (those aluminum cases like James Bond had) with the
different drives available for swaping out for the appropriate version
of Netware that the client had.  On the drives they had the latest
patches for the various systems and they would let us test software
off of there system.  They'd walk in load the server onto
the network - login to it from a local pc and we had instant portable
network.  It worked great - I have no Idea how much it cost, but it
was cool.  I believe it was either a Toshiba, IBM or Compaq system.

I would recommend any mainstream laptop - and swappable drives.
Sound like you are looking into a similar system.

---------

Date: Wed, 30 Oct 1996 21:45:44 -0500
From: "Brien K. Meehan" <MEEHANB@DETROITEDISON.COM>
Subject: Notebook Server Recommendation

>Do you have any recommendations for a notebook to be used as a
>NetWare 3.12 10 User fileserver?  Do you know any particular Do's and
>Don'ts you could share?  I could not find a NetWare YES certified notebook
>at the Novell site.

You're not going to find a notebook certified to be run as a Netware server,
period.  Most notebooks on the market today don't even run well as
notebooks. Forget that part of it.

If you must run a notebook as a server, the most important feature is the
LAN driver.  I've run a notebook as a server using a Xircom PE3-10BT
parallel port adapter.  I got the idea only because Xircom bothered to
write the Netware drivers!  So, find a network adapter that has Netware
LAN drivers available, and go from there.

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

Date: Wed, 13 Nov 96 09:57:18 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: 12-bit FAT?!

>Does anyone know what the heck a 12-bit FAT is and why I might be seeing
>this?
>
>When I tried to mirror the 2 drives, I got a message stating that the
>Netware partition wasn't big enough and it asked me if I wanted to change
>the original drive's partition size. I said no. However, the partition size
>on both drives were identical (at least according to the Partition Tables in
>Install).  The strange thing is that this exact same drive was duplexed
>before in this exact same server. Does anyone know why I might be seeing
>this and/or a solution to the problem?

Oh, how fun! The issue is that for DOS 3.3 and below, the fat table was
limited to 32 megs (12 bits, if I'm not mistaken). This is just saying
that the sector size is smaller; the default sector has two drive blocks
(1024 bytes); partitions larger than 32 megabytes use drive blocks in
multiples of 2. This is normal, and nothing to worry about.

Now, the solution to your problem is to partition the drive - make the
partition 1 meg smaller; you may have to do this a couple of times. For
some reason you're grabbing 1 cylinder too many on the drive. DOS and
Netware see partitions rather differently, and the boundary has to be a
complete cylinder (set of tracks, for most people). BTW, any extra space
on the drive is simply not used, so don't be afraid to go too small on
the DOS partition. Format it just large enough to contain your emergency
boot stuff. If, on the other hand you don't intend to ever boot off the
second drive in the event of an emergency don't bother adding a DOS
partition at all.

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

Date: Thu, 14 Nov 1996 13:44:11 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: SOLVED!  New Epoch creates 100% utilization -Reply

>It is an ASUS EISA/PCI dual processor motherboard (only one processor).
>I have set up the EISA Bios to recognize the RAM, and when I type
>Memory at the console prompt it is all there.   (BTW, Why does the ASUS
>EISA Config not allow 96 Megs of ram, but must go from 64 to 128?)

	If it's the PCI/E P54NP4 board then I own two of them. Memory
is in the form of pairing of SIMMs and memory banks often need to use
SIMMs of all one kind. What the vendor (ASUS) dictates is what we do,
in detail. No funny business on SIMMs.
	96MB is a rather large amount of memory. Your 8GB disk space fits
well within 64MB if 64KB disk allocation units and subblock allocation are
used (this is a NW 4 box, isn't it?).

>I too suspect a constipated disk system.  I have an Adaptec 3985 PCI
>Raid controller in it that has the main storage (3 Seagate ST15150N for 8
>gigs online storage).  I also have an Adaptec 2940W, which is a "regular"
>PCI SCSI adapter, this has the CD, HP 4mm DAT, and the SYS volume,
>which is a Fujitsu 500meg drive.

	PCI setup. Tell all PCI devices to get the heck off the bus soonest.
EISA setup: ditto for the Adaptec controllers.
	Seagate: ensure the disk drive cache is Off for each drive. Seagate
has the tiny program to do this at DOS level. Set SCSI parity On everywhere.
Check those SCSI cables again, and if in doubt buy more expensive ones.
Active terminators please on big fast disk farms.
	An old 500MB Fujitsu may not be the strongest of SCSI implementations.
I used to run a lot of them, but age shows. Recommendation is go get a Seagate
Hawk 2GB drive (5400 RPM, runs cooler than the Barracudas) for SYS:. NDS files
live on SYS:. Avoid consumer grade drives.
	Please watchout on the narrow to wide SCSI adaptor devices. If you
really do not need wide then don't become involved with it. Similarly, don't
mix narrow and wide SCSI devices on the same bus.

>I know, but I really have no interest in destroying the SYS volume and
>moving it to the raid controller until Novell makes recreating SYS volumes a
>little less fraught with danger.

	Good thinking. Keep SYS: isolated and "pure."

>Once this problem occurred, the first thing I did was put the Fujitsu SYS
>drive all alone on the 2940W.  I also have a Cogent 100mbps Ethernet
>card on the PCI bus.  All three cards are bus masters, the Raid is a bridged
>PCI.  I have 2940's and Cogents in my other two servers, and they have no

	PCI bridging is an area where there is looseness of implementation.
You are correct in suspecting trouble there.

>problems like this one, which makes me very suspicious of the Raid
>controller.  I have sent mail to Adaptec Technical support, asking about
>potential CPU utilization problems, but they have not responded.  I don't
>even know if I am asking the right questions.

	Joe D.

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

Date: Thu, 14 Nov 1996 17:25:41 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: RE: Server Position in Bus

>>Open a DECConnect catalogue, and pick a terminator.  It will not have a
>>hook for grounding.  Same thing with the wall mounted stuff where you
>>hookup workstations using a drop cable to the jack on the wall.  With
>>this scenario, it is blatantly obvious, as the terminator that you
>>install on the last drop-box, is sealed inside a plastic casing, with no
>>provision for grounding.  Call DECConnect and ask them why.  

Like the add says, "WAIT!!!  YOU'RE BOTH RIGHT!!"

But, I still have some reservations here.

First, the 3c509b card I just pulled out of it's box does not have a
path between ground and the coax, so at least one company is not
grounding the coax.  And that's good.

DEC, it seems, is yielding to marketing realities - if you don't sell
a part, you don't carry it.  But that does not have bearing on
technical realities, nor on IEEE standards.  The bean counters decide
what will be stocked, not the engineers.

I've dealt with large multi-building sites and have some background
in electronics (though I'm pretty rusty).

Ground loops are caused by having multiple paths to ground.  This
would be achieved by having many cards on an ethernet coax segment
grounding it.  This can cause other problems.  In the case of a large
site, you have the distinct possibility that "ground" at one part of
the cable is at a different potential from "ground" at another part
of the cable.  Even a few volts difference can cause signifigant
current flow.  While the impedance of coax cable is around 50 ohms,
the resistance of the shield is much lower - it is a fraction of an
ohm at any reasonable length.  This sort of current flow has caused
cable and equipment damage in more than one site.  Ideally, the nodes
and the cable should be isolated with regards to ground, which is
much the way most computer and other electronic equipment works -
there is a separate earth ground for the power supply and chassis and
a separate signal ground for the electronic equipment.

In most cases, having the coax ungrounded, grounded in only one
place, or grounded in many places will probably make no real
difference.  However, prudence suggests there be a single ground at
one end of the segment.

Which brings up another thought... or speculation.  All the ethernet
coax hubs require that the cable be connected directly into the
hub.  This took me by surprise the first time I saw it.  Given this,
it's pretty obvious that the hubs are terminating the coax.  As a
matter of control and convenience, I would be surprised if the hubs
don't also ground the coax segments.  This would allow all the
segments in a building to be at the same ground level, which is an
advantage.

---------

Date: Fri, 15 Nov 1996 00:48:32 +0100
From: "Arthur B." <arthur-b@zeelandnet.nl>
To: <Netw4-L@bgu.edu>
Subject: Re: COAX?   (was RE: Server Position in Bus) -Reply

If Scott is right the specs are wrong.

I like to believe specs are right 'cause what else is there to check for
correct installation? Not that specs can not turn out to be outdated. But
in that case they should be updated.

Every book I open warns me to use one grounded terminator per segment.
Are these outdated books? I don't think so. Probably they look at the
specs also. Which is a problem if they turn out to be outdated.

On the issue of purchasing a grounded terminator. No problem here.
Can that be specific per country? Or maybe even the need to use one?

Which brings me to the two questions left as far as I'm concerned.
(1) Does it matter to install a grounded terminator?
(2) Will it help you in certain situations?  If so then at least the
    people who draw up the specs must have had a use for it.

---------

Date: Fri, 15 Nov 1996 01:33:41 +0100
From: "Arthur B." <arthur-b@zeelandnet.nl>
To: <netw4-l@bgu.edu>
Subject: Re: Server Position in Bus

>Which brings up another thought... or speculation.  All the ethernet
>coax hubs require that the cable be coonnected directly into the
>hub.  This took me by surprise the first time I saw it.  Given this,
>it's pretty obvious that the hubs are terminating the coax.  As a
>matter of control and convenience, I would be surprised if the hubs
>don't also ground the coax segments.  This would allow all the
>segments in a building to be at the same ground level, which is an
>advantage.

Yes, you're right Mike.

When coax segments are connected to a hub (was the term 'MultiPort
Repeater' not used in DEC docs?) each segment is grounded at one end
automatically. So no need for a grounded terminator in such cases.

Forgot about that little box.
Thanks for reminding.

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

Date: Mon, 18 Nov 1996 08:03:25 -0500
From: Dennis Large <wdlarg01@homer.louisville.edu>
To: netw4-l@bgu.edu
Subject: RE: Frame Types

>>He probably wants you to shorten all the patch cables by 1 foot to make
>>response time quicker, too.
>
>Interesting... some time back, one guy was trying to explain to me why
>patch cables shouldn't be shorter than 9.? feet... something about how far
>the electrical signal travels in one cycle... 

In analog RF, yes, cables of certain lengths can generate harmonics, etc.
and cause all sorts of goofiness. But not in digital.

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

Date: Wed, 20 Nov 1996 09:21:46 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: Boot Manager vs. Dual Boot

>>	The best solution is to use the FDISK utility from OS/2 and create
>>a 1 MB Boot Manager partition. Then, create a pair of C: partitions and
>>an extended FAT partition.
>------------
>	Yes, one could do that.
>	At one point my desktop PC booted to the OS/2 boot menu, and from
>there to the NT boot menu, and from there to the Win95 boot menu which led
>to Win95 or regular DOS 6.22. It was all very simple to accomplish with just
>the tools provided by each product. Currently I've removed NT client as not
>worth the disk space, and hence I'm down to a three way split. One does not
>need OS/2 to accomplish the goal of dual booting DOS and NT; one simple reads
>the fine manuals.

	Well, it's a bit more complicated with OS/2 2.3 & Warp: I got some
very fine info, that is not in the manuals, when I was a (Macintosh)
Special Contributor on PRODIGY from my colleagues over on the Team OS/2
boards.

	Basically, a dual boot setup is not as robust as a Boot Manager
setup. In a dual boot setup, which Microsoft recommends when installing NT
over DOS & Windows 3.1, both OS's can exist on the same partition; or they
can be on two separate partitions... But all partitions mount at startup.
The key here is that there CAN be an unintentional interaction between the
different OS' with disasterous results.

	Boot Manager, on the other hand, places the two operating systems
on different primary (C:) partitions; and uses a 1 MB "Head" partition to
load one of the two OS partitions by mounting the appropriate C: partition.
Essentially, the Boot Manager is a mini OS whose sole purpose is to set
Automount and Bootable flags.

	For a 1 gig drive, set up with Boot Manager for NT and NetWare, the
partition map would look like this:

		Drive                            File
Size            Letter          Function        System
----------------------------------------------------------
  1 MB          -none-          Boot Manager    FAT(?)
256 MB          C:              NT 3.51         NTFS
256 MB          C:              NetWare 3.12    FAT
480 MB          D:              NT & NW common  FAT

	The key thing to remember is that only one of the two C: partitions
are mounted at startup... Dual Boot doesn't give you this protection.

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

Date: Mon, 2 Dec 96 13:07:57 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: RAID 5 question

>Here is my question:  What is the best way to implement the volume
>structure using RAID 5?
>
>As I see it, there are two options.  The first is to create a large 15+ GB
>array that contains the 2 GB SYS volume and the 13 or so GB VOL1 volume.
>The other option is to two separate arrays (a 2 GB RAID 5 array wholly
>containing the SYS volume and 13 GB RAID 5 array containing VOL1).  The
>main advantage to have two separate arrays is that I can increase the size
>of VOL1 with messing with the SYS volume.  The possible disadvantages are
>system performance and system resources.

You didn't mention the drive configurations, but do indicate that
performance is an issue. You really need to be aware that Raid 5 is
SLOWER on data writes than an equal number of Raid 1 drives. Data reads
are the same, but caching drops the typical 3:1 read:write ratio down to
1:1 or worse. This won't be a problem if you're not I/O bound on the
disks or the new disks are significantly faster, just be aware that
depending on the write block size the performance ratio of raid 1 : raid
5 writes is from 5:3 to 3:1. This performance penalty for Raid 5 is not
dependent on the controller but inherent in Raid design. Check out my
upcoming article in Network Var (feb issue) or some of the lit at
http://dpt.com.

Based on this, I'd suggest 2 separate arrays. Maybe a pair of drives
(mirrored) for sys, and the rest of the array for vol1. Performance will
be better, not worse, and the increase in system resources will be
trivial.

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

Date: Wed, 4 Dec 1996 09:49:06 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Re: Upgrading server hardware

>I have a question about upgrading hardware. What is the general consensus
>about the best method to upgrade an existing 4.1 server to new hardware
>(from 486dx66 to PP200) ?

Stay away from proprietary boxes like Compaq's.  Use generic
machines, and a third party disk controller, like Adaptec or DPT to
insure that the disk controller will work with as wide a range of
vendors systems as possible.

When it's time to upgrade, backup the system, down it, swap
motherboards, bring the system up, fine tune the setup for any
changes you had to make.  In some cases, you can make stepwise
refinements at the same time.  For instance, moving from an ISA to
EISA, or ISA to PCI, or EISA to PCI disk controller.

All too often the prorietary boxes don't let you swap motherboards,
or even disk controllers into another box.  I once tried to use a
Compaq RAID controller in a DELL system.  Tech support at both
companies were unwilling or unable to help.

If you can't do this, you can set the stage for your next upgrade now
by moving to a more generic box.  (As to motherboards, I am very
conservative.  I suggest ASUS, or other well know motherboards, not
just whatever the clone shop had in stock that week.  Although I have
had good luck with no-name clones, I can't do that to a customer,
client, or employer - the stakes are too high.  At home, that's
another matter entirely.)

As to migrate, there is some debate about whether or not it will
allow 4.1 to 4.1 movement.  In any case, unless something has
changed, migrate is as slow as Christmas.  You can backup and
restore, that way you only have to load minimal NetWare and the tape
system.  With some backup systems, you only need a single diskette to
boot on, and they take it from there.

Another possibility is the JRB utilities.  John Baird has written
some really neat utilities.  One will allow you to get a dump of the
NDS/Bindery information in a format that can be piped into a makeuser
or UIMPORT script.  Run the program on the new server and that's
over.  Then he has a network copy program that copies data and
assigns ownerships and priveleges on the new system the was it was on
the old system.  For instance, if john owns a file on the old system,
and there is a "john" account on the new system, then the copied file
will belong to "john".  It's been a while since I looked at the JRB
utilities, but I believe they are NDS aware now.  The copy program is
MUCH faster than migrate.  In fact, it is faster over regular
ethernet than migrate is over 100mbps FDDI.  And you can have
multiple copy sessions running at once, where migrate can only be run
on a single node.

They can be found by anonymous ftp at risc.ua.edu in the
pub/network/misc directory.  The current file is jrb300.zip, but it
always does start with jrb.  You can also check out John Baird's home
page at http://www.lincoln.ac.nz/ccb/staff/jrb/default.htm

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

Date: Thu, 5 Dec 1996 08:16:28 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: Re: RAID 5 question

>>If you aren't having performance problems that could be
>>addressed by a CPU upgrade, I suspect that the upgrade is ill
>>advised.  The TriCord Powerframe should be a more reliable and
>>resilient machine than the Compaq.  To be sure, Compaq makes a good
>>box, but I have to think that the TriCord has the edge on reliability.
>
>Mike, I'm curious - why do you think the TriCord is going to be more
>reliable? I'm curious mostly because I've heard it many times without any
>substantial information.

It's my understanding that the TriCords have a lot of internal
redundancy to insure that they are close to being a non-stop
architecture.  Multiple power supplies, multiple CPU's that are in
parallel, ECC memory, multiple disk controllers and drives, and even
NIC's in parallel.  All set up so very few single component failures
can bring the box down, or even cause it to lose network connection.

Last time I looked, Compaq didn't have anything that was trying for
that level of reliabilty.

---------

Date: Thu, 5 Dec 1996 14:57:56 -0500
From: Joe Thompson <JST604@aol.com>
To: netw4-l@bgu.edu
Subject: Re: RAID 5 question

>I'm rather curious about why the upgrade is being performed.  Sure, a
>Pentium Pro 200mhz  machine is faster than a 486-DX2/66.  But, are
>you having performance problems on the old server?  Unless you are
>doing unusual things with your server, the CPU is usually not a
>bottleneck.  If you aren't having performance problems that could be
>addressed by a CPU upgrade, I suspect that the upgrade is ill
>advised.  The TriCord Powerframe should be a more reliable and
>resilient machine than the Compaq.  To be sure, Compaq makes a good
>box, but I have to think that the TriCord has the edge on reliability.

While the Tricord is a faster Netware server due to it's superior drive
array, I've found it to less reliable then our Proliants.  Actually the
speed gap between the two has been  smaller with the latest Compaq PCI
drive array.

Frankly we are no longer buying the Tricords due to the severe problems
that we had with one of our ES5000.

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

Date: Fri, 06 Dec 1996 10:48:29 -0700
From: Shawn <opeth@futureone.com>
To: netw4-l@bgu.edu, netw4-l@bgu.edu
Subject: Re: EIDE VS. SCSI

>>Can anyone tell me what performance/reliability penalties I may be facing
>>here?
>
>With current technology, the max. transfer rate for an EIDE drive is 16.67
>MB/sec (that Mode 4).  With SCSI, the max. transfer rate is 40 MB/sec
>(that Ultra Wide SCSI).  As I see it, you would have most likely used
>Fast-SCSI 2 drives which has a max transfer rate of 10 MB/sec.
>
>SCSI is a better for servers.  When the SCSI controller issues a command
>to a drive, the drive disconnects from the SCSI bus until it has the data
>requested.  This allows the controller to issue commands to other drives
>on the SCSI bus.  In addition, you can place seven devices on a SCSI bus
>verses two on an EIDE bus.

Other considerations:

1) EIDE still (to my knowledge) doesn't support overlapped, multitasking
I/O, whereas SCSI does (see Robert's comments above). That means that the OS
will have to wait until the request to the device has been completed before
it can issue another request. SCSI uses command tag queuing and can thus
issue 256(?) requests at a time. This can make a huge difference on
disk-intensive systems.

2) I think EIDE still doesn't support bus-mastering (SCSI does), but I'm not
sure of this. Bus-mastering (as you probably know) offloads work from the
CPU, thus reducing CPU utilization significantly.

3) Most non-SCSI devices (ie: EIDE) don't have sector-remapping capability,
which is an important part of a fault-tolerant system.

4) Novell doesn't approve of mirroring/duplexing EIDE drives in a NetWare
server. In fact, they go so far as to say it can't be done at all. However,
this is not true, as I've done it myself a bunch of times.

5) Most SCSI HBAs also have external connectors, allowing for daisy-chaining
of (if it's a separate channel) another 7 devices.

---------

Date: Sat, 7 Dec 96 00:36:11 -0000
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: EIDE VS. SCSI

<snip>
>5) Most SCSI HBAs also have external connectors, allowing for
>daisy-chaining of (if it's a separate channel) another 7 devices.

Good comments, Shawn. One correction, however - SCSI I and II support 7
drives/chain and external devices, the wide formats support 15
(theroretically), firewire supports 96 and Fiber channel supports 128.
The last two also have provisions for multiple hosts and hold out the
possibility of network attached drives, and are shipping technology. The
fun part incudes fiber channel switches - can you say ungodly throughput?

Also, don't forget that the BUS throughput is meaningless, as long as
it's higher than the max agregate throughput of the drives on that bus.
EIDE supports only 2 drives per channel, so that 16 MB transfer rate
isn't going to be taxed just yet.

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

Date: Mon, 9 Dec 1996 08:57:42 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@bgu.edu
Subject: RE: (Fwd) Mother Board change

>I've had parts of this happen.....   on a Compaq Proliant 1500...
>(no, we didn't change the motherboard!)

Well... two comments.

Compaq's tend to work better if they have Compaq memory in them.
I've purchased third party memory for Compaq servers a few times and
always had to return the memory and install real Compaq memory.

Their PC's seem to be OK.

As to making sure something really really works, my cynical friend in
Australia always qualifies his systems before installing them, no
matter who made them.

For several months the server canidate is his personal PC.  If he
feels that it hasn't let him down, the network operating system is
installed, and a number of PC's beat on the server using LANTest and
some programs he has written to simulate a typical load that he sees
on his LAN's.  After the server survives a week of the LANTest
endurance test and his load simulator, it's put on line.

Sure, it seems excessive, but on the other hand, he sleeps all night
at home, undisturbed.

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

Date: Thu, 12 Dec 1996 01:33:45 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: CPU cooling

>>>One of the techs noticed that the fan on the processor chip had
>>>stopped.  Replaced the chip and the server has been up now for 1
>>>day and one night - looking good.
>>
>>Hmmm. I've seen enough fan related problems here to make me wander
>>if it wouldn't be a good idea to connect fans to a led that can be
>>looked at from the outside. Not everyone has a hardware module
>>inside their fileserver that checks tempature on vital places. And
>>to be honest. Suspecting the fan isn't my first idea. A simple led
>>could save many hours of downtime and troubleshooting for this '5 in
>>a lifetime' problem. Any manufacturers out there that wish to
>>respond? Keep in mind that tempature control will become a bigger
>>issue everytime system parts get smaller and smaller.
>>
>>Arthur B.
>
>I've toyed with that idea (in my mind), a thin bi-metal sensor,
>squeezed between the heat sink and CPU, connected to some sort of
>display.
>
>Better yet, wrap one of the power leads to the cpu fan around a
>sensor that would be affected by the magnetic field generated.
>Presumably if the fan siezed or began to run slow, the display guage
>would move away from normal.
>
>As for the power supply fan, one could wire a micro switch to a
>piece of mylar, while the power supply fan is blowing it would keep
>the mylar floating high, upon fan failure the mylar would fall and
>set off an alarm.
>
>Pierre Marceau

	Pierre, Gary, and Arthur had written about a CPU fan failing, with
dire consequences. In my opinion (as well as that of other engineers),
mounting a fan directly on a CPU is poor engineering design, because of
vibration. What can happen is that one or more of the very fine wires
leading from the chip bonding pads to the carrier can fracture due to
cyclical loading, destroying the device.  *AND*  on certain machines the
CPU wafer is bonded directly to the logic board, so if the CPU goes so does
the whole MLB!

	There are alternate designs that yield equal or even better
performance, such as reverse thermocouples (so-called "thermocoolers") that
conduct heat away; and more importantly larger fans (such as those in power
supplies) that are directed or ducted to provide a blast of air on the
CPU/heat sink assembly. These designs are prevalent in the RISC arena, with
thermocoolers used on PowerPC 601 machines running over 100 mHz, and all
604 machines. Designs that include ducted or directed power suply fan
cooling air include the Radius 81/100 and 81/110 tower machines, as well as
the Macintosh Quadra/Performa 630, 640, 6200 and 6300 series desktop
machines.

	There was a serious problem with the Apple Workgroup Server
9150/120 design (of which I built five machines converted from Quadra 900 &
950 boxes) in that the thermocooler was either defective or too small: The
design was OK with convection cooling at 110 mHz; but at 120 mHz it was
marginal at best. [BTW, this was the platform for Novell's aborted attempt
that died in beta last November to port NetWare 4.11 to the PowerPC
Macintosh.] Apple's answer was to use a small fan blowing about 10 SCFM of
air orthogonally across the heat sink (with 50% theoretical maximum
thermodynamic efficiency).

	What I did was to re-engineer the power supply assembly, upping the
fan from a 5 inch 12 volt 60 SCFM unit to a 120 volt 115 SCFM unit; and
installing a second 30 SCFM 3" fan exhausting the power supply directly
over the CPU heat sink. This acted in a fail-safe mode in that if the
smaller CPU fan failed enough of a breeze would still be ducted down on the
heat sink to prevent it from being destroyed. In addition, a counterflow
heat exchanger provides a theoretical maximum thermal transfer of 100%
efficiency, as opposed to the 50% efficiency of a crossflow design.

	[As a side benefit to this design, by switching the main fan from
12 to 120 volts this cut down on the power supply loading and heta
generated... Imagine generating heat just to remove heat from the power
supply!  In fact, I am now making this standard issue on 24/7 machines:
Can't run them too cool.]

	As for Pierre's suggestion about fan monitoring, I do *not*
recommend a sail switch to detect airflow: Instead I recommend just
monitoring the fan motor current. Most all small fans have windings that
are impedence protected (abbreviated ZP in the fine print on the
nameplate), and can operate in a locked rotor state indefinitely. Just
monitor the fan current and if it climbs that means that the bearings are
sticking or frozen.

---------

Date: Fri, 13 Dec 1996 00:16:37 +0000
From: John Wells <jwells@PACIFICCOAST.NET>
Subject: Re: Server crashing [resolved?]

>> Hmmm. I've seen enough fan related problems here to make me wander
>> if it wouldn't be a good idea to connect fans to a led that can be
>> looked at from the outside.
>
>I've toyed with that idea (in my mind), a thin bi-metal sensor,
>squeezed between the heat sink and CPU, connected to some sort of
>display.

(Although off the Netware track...) PC Power and Cooling advertises a
1"x1.5" temperature alarm that plugs into a standard 4 pin disk power
connector and which sets off an alarm at 110F. Perhaps you could thermally
connect its temperature sensor to the CPU heatsink.

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

Date: Fri, 13 Dec 1996 16:05:02 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet Thinnet cable troubleshooting

>>	Ohm meter. Apply to a Tee connector and see 25 Ohms or a several
>>more. Anything else means bad wiring (short/open too many terminators,
>>too few terminators, where the terminator count must be two).
>
>Disconnect Tee from the server or any othe active signal before
>testing or you will get strange readings.

	Not really necessary. Yes, the values bobble, but the basic readings
are obvious anyway. No need to shut down equipment or bother users.

>>	Visual inspection. Look for stubs off Tees. There must be none,
>>not even one inch long. Look for bad connectors. If you find any twist-on
>>kinds remove and trash them.
>>	Wire too long: 185 Meters max. Check it.
>>	Wire is crummy. Don't mix kinds, use proper 50 Ohm coax labeled
>>IEEE 802.3 on the jacket. Black stuff (RG-58/letter) varies a lot and
>>won't do.
>>	Joe D.
>
>If you can find, beg, borrow or  st... a TDR (Time domain
>reflectometer) it works very well in this situation to find the wierd
>spots in you cabling system.  It has saved me much time and
>frustration.

	Yes, an excellent tool. Alas, folks who have trouble diagnosing
the simple stuff won't be able to cope with the fancy test gear. They
can count ceiling and floor tiles and come close to the cable length.
That's not to insult anyone, but complicated gear does boggle minds
unaccustomed to the equipment and what it is displaying. I make TDRs
from a scope and a resistor, when needed.
	Joe D.

>John L. Stevens

---------

Date: Fri, 13 Dec 1996 17:55:44 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Ethernet Thinnet cable troubleshooting

>>	Wire is crummy. Don't mix kinds, use proper 50 Ohm coax labeled
>>IEEE 802.3 on the jacket. Black stuff (RG-58/letter) varies a lot and
>>won't do.
>>	Joe D.
>
>Interesting.
>Would you recommend using RG-58 MILSPEC coax?
>I'm asking this because I know that many navy ships are fitted with
>RG-58 MILSPEC coax and I value your opinion.
-----------
	The most important property of the cable run is absence of reflections.
The second is proper impedance so collision detection and bit recovery work
correctly. The third is low loss (10 dB round trip loss budget).
	RG-58 comes in many variations where the "nominal" impedance varies.
Alas, the variation of impedance amongst reels with the same label is still
a couple of Ohms or more. That's too much for well populated Ethernet segments.
	The IEEE802.3 labeled stuff is supposed to obey tighter specs than
RG material. It also has much better shielding properties because of the
aluminum foil sheath under the braid.
	The average technician isn't up to speed on the many RG specs, nor
validating that cable in hand meets those specs, nor on the necessity to get
all of a run from a single reel. So black cable stuck together from pieces
usually has trouble, and such can be seen with a TDR.
	To make sure people don't cause more trouble than necessary just
use the IEEE802.3 labeled stuff for Ethernet. Don't use the RG stuff.
Please don't be dazzled by the word "milspec." Remember, the intended use of
RG coax is not Ethernet. Look at your Navy ship and notice all the heavy
braid sheaths over cables. Ever wonder about that? Ask the ETs about cross
talk, even with coax runs.
	Finally, recall that coax is a much better medium than twisted pair.
But average people can't make decent BNC connections, nor choose cable well
enough, and so on. Thus 10BaseT is popular for people reasons, not because
of transmission line quality (twisted pair is poor stuff). [Please save
obvious stories about disconnected Tee connectors; we know them all.]
	Joe D.

---------

Date: Thu, 12 Dec 1996 21:49:37 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: 

	All of you are right... To a point. There are many reasons that a
10Base-2 (and 10Base-5, a/k/a "thicknet") segment can go down: Some of them
are pretty esoteric; and some are just downright stupid. For example:
	1) Somebody steps on a cable, causing an impedence "bump" and the
reflections it sets up. Just go to your Smith chart and plug in the
numbers. Surprisingly, in my troubleshooting experience this is the most
common cause of failure;
	2) Bad transceiver or NIC: About once per year I see a small
Macintosh 10Base-2 LAN that has a transceiver go south -- Bringing down the
whole LAN;
	3) Poor cable connectors: The idiot who decided to use BNC
connectors must be related to the Cable Guy -- Ya know, the dude who brings
F59 connectors into our living room to give us our MTV?! To  *properly*
install a BNC connector requires a special stripper and crimping tool to
prevent any impedence "bumps" at the connection point. Personally, I use an
Ideal Crimpmaster with the combo RG58 & RG59 dies; and an Ideal stripper
with a slider adjuster for RG58, RG59, and RG6 cable diameters. [Cost:
About US$100 for the set.] Personally, I prefer soldered-on PL-259 and
SO-239 connectors, as found on 10Base-5 LANs and in RF (radio use): But the
computer market has seen otherwise;
	4) Tees and loops: Joe touched on having stubs attached to the
branch of a tee; and he is 100% correct. But, if somewhere on the LAN
someone has an "idiot loop" connected this too will "screw the pooch."

	Now, let's take a moment and figure out exactly what happens when
one uses RG58 cable; and why it  *sometimes*  fails as a 10 mHz baseband
transmission line medium. In truth, it is because it is "too good" at
times. Standing waves, often referred to in RF circles as VSWR (Voltage
Standing Wave Ratio) occur due to mismatches in impedence along, or at the
ends of, the transmission line. RG58, by it's very physical construction,
has a lower DC resistance than so-called "Ethernet" cable. When
transmitting a radio signal, the lower the resistance, the better the
efficiency: This is why you see coaxial cables as thick as your wrist going
up broadcast towers.

	But, let's now shift gears and drop down to 10 megabit Ethernet:
Here, efficiency (losses) are not as important, so the circuit can tolerate
higher impedence mismatches because they are being damped out by the
resistance of the ethernet-grade cable. If you take two identical, perfect
cables -- One "ethernet" grade, and the other RG58 -- and put them
side-by-side in a LAN with identical sources along the length, you'll see a
higher VSWR on the RG58 cable because of the lower resistive damping. [Joe
*almost*  hit the mark when he said:

>The third is low loss (10 dB round trip loss budget).]

	Now, how to get LeAnne out of her pickle: Start subhubbing
workgroups and migrate them to 10Base-T. You can pick up 8 port hubs for
about $79 now, and connect the hubs together with the existing coax cable.
This way, you can "hide" the backbone cable where it will be safe from
physical damage -- And workstations gone haywire. It also maximizes your
return on existing cabling.

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

Date: Sat, 14 Dec 1996 14:24:30 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: TDR from a scope and resistor

>Hey Joe - can you summarize how to make a TDR with a scope and a resistor?
>Or, point us to a source that we might be able to find the information.
---------

       Y axis   <-------------------
				    |
       sync     <------             |
		      |             |
		      |   50        |
		o-----+-\/\/\/\/\/\-+------     center conductor
       cal pulse                             coax cable
		o-------------------.------     shield
		Gnd
       SCOPE

	Digital sampling scopes work well because the trace can be stored,
expanded, scrolled, viewed easily. But watch that the sampling rate is not
in sync with Ethernet packet pulses (20M transistions/sec).
	The resistor separates the voltage source cal pulse generator from
the cable so we can see the voltage difference between the generator and
the returned echo. It also terminates the line so pulses don't bounce off
the scope end.
	The scope's cal pulse generator can be replaced with an external
pulse generator, but keep the pulse amplitude low (< 1 V).
	I'll skip making a proper directional coupler because that's well
beyond the range of system managers. Yes, it is possible to detect signals
going each way on a transmission line and to deal with each separately.

	To the average system manager:
	1) use an Ohm meter to check the cable. Try measurments with leads
one way and then the other way. Be alarmed if a quiet wire shows any d.c.
voltage (volt meter test) because that will clobber collision detection
and it means a lan adapter is broken on the wire. Signals are 0 to -2V.
	2) measure the length of the cable run, by any means possible, and
don't exceed 185 meters (attenuation limit).
	3) remove all stubs (extensions from BNC Tee connectors). That means
no extensions are permitted, none.
	4) inspect cable for damage. Squashed cable isn't 50 Ohms at the
squashed place. Replace. Wiggle cables at the connectors.
	5) check connectors. Never deal in cheap BNC components. Never ever
touch a twist-on thingy; they are poison. Crimp connectors are very good,
solder/clamp connectors are very good but require more skill to assemble.
	6) again, only two terminators, and they must be at the absolute
very ends of the cable. Since there are only two ends that means two
terminators, one on each end. Sorry to undershoot intelligence here, but
experience shows folks have trouble adhering to such simple rules. Measure,
do not trust your eyes, some boards have terminators hidden away, trust
nothing.
	7) check your terminators. 50 Ohms please, each.
	8) use the proper cable for the job. Please do not raise the subject
of using other kinds of coax. It will not work satisfactorly and all you
will receive from us is admonishment to do the job right or not at all.

	If this is too technical for you then congratulations on recognizing
a situation for what it is. Then contact a person who does know these items
in detail. Don't expect an email message to give the equivalent of years of
specialized study and experience in a high technology area. On the other
hand plain common sense thinking is often highly effective.
	Joe D.

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

Date: Tue, 17 Dec 1996 07:18:33 -0500
From: Philip Reznek <preznek@VISYS.COM>
Subject: Re: Cat 5 connectors

>>>I built my last network ( 10BaseT ) with cat5 cables and just whatever
>>>rj45 connectors were being sold.  Now that I'm building another network
>>>( planned to become 100TX at a later date ) I see connectors for sale
>>>labeled as cat5, but it looks like the only difference is they are gold
>>>plated. I can't see how there could be any difference between a 20 cent
>>>connector and a 99 cent connector ( electrically speaking ) except a
>>>better connection.  Are all of us who designed our networks to go to
>>>100Mbs going to have to put new connectors on when we slap in those
>>>100TX cards and hubs?  Anybody know?
>>--------
>>	Like other things technical, not all items are identical that seem
>>alike to a casual observer. Get your requirements, state them to the
>>vendor, purchase and test. If the vendor does not understand your
>>requirments then change vendors. Just because it's for sale does not
>>mean it is wise to purchase it, and similar platitudes.
>>	Cat 5 has stringent requirments about maintaining twist into the
>>connector body. Stranded and solid wires require different connectors.
>>This stuff isn't a telephone extension cord. If doubts persist lay hands
>>upon a good quality cable tester box.
>
>	Do you know where to find the Cat5 electrical & mechanical specs;
>and or summarize them here for everyone?

Go to http://www.eia.org/eng/allstd/std/index.htm and search.  Or,
download http://www.eai.org/eng/allstd/std/index.cat.

What you're looking for are TIA publications, but the catalog is kept
on EIA.

On a previous topic:

Document # 757 Type: HTML
Headline: Commercial Building Grounding and Bonding Requirements for
Telecommunications (ANSI/TIA/EIA-607-94 DocID: 0 1655
eng\allstd\std\files\TIAEI607.HTM

This topic:

Document # 744 Type: HTML
Headline: Commercial Building Telecommunications Cabling Standard
(ANSI/TIA/EIA 568 A 95) (Oct., 1995) DocID: 0 727
eng\allstd\std\files\TIA-568A.HTM

Document # 802 Type: HTML
Headline: Additional Transmission Specifications for Unshielded
Twisted-Pair Connecting Hardware (Feb., 1994 DocID: 0 1843
eng\allstd\std\files\TSB40-A.HTM

My recollection is that there are three standards that apply for a
package price of about $350 for the set.  Individual totals are more.
And no, you don't get a peek at the text on-line.  You'll find
ordering information after you locate a document.

I also recall if you phone the order line, the people will be happy
to give you an exact idea of the contents.

---------

Date: Tue, 17 Dec 1996 13:50:00 -0400
From: "BURTT, PETER (AEL)" <PBURTT@GOV.NB.CA>
Subject: Re: Cat 5 connectors

>Do you know where to find the Cat5 electrical & mechanical specs; and
>or summarize them here for everyone?

For bending radius, min dist from EMI, etc. I've found the
following to be a good resource...

http://www.cis.ohio-state.edu/hypertext/faq/usenet/LANs/cabling-faq/faq.html

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

Date: Tue, 17 Dec 1996 18:28:42 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Where to ask Ethernet nuts&bolts questions

	Since we've gotten down to tiny little things (pins on RJ45
connectors) I thought some of you would like to know where all things
Ethernet are discussed in detail (with some of the folks who wrote the
specs). That place is NEWS group  comp.dcom.lans.ethernet.  There you
can berate Rich Seifert for inventing the darned sliding clip on AUI
connectors, and so on. Caution: here be tigers.
	Joe D.

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

Date: Mon, 30 Dec 1996 15:14:51 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Cache memory allocator out of memory problem

>	 We just purchased a new server to replace an old IBM microchannel
>machine that has been crashing on us latetly.  The new server is equiped
>with an AMI Atlas PCI II system board with 512k cache, Pentium 200
>processor, 64Mb of RAM, two 4.3Gb Wide SCSI-2 hard drives, 8 Speed CDROM,
>Trident 1Mb ISA SVGA video card, Adaptec 2940UW PCI Ultra Wide SCSI adater
>(for the two hard drives), Adaptec 2920 PnP PCI SCSI adapter (for CDROM and
>External Tape drive), and EtherExpress 10/100 Lan adapter.
>	During the software installation we configured the hard dives with
>the following partitions:  HD#1 partitioned into a dos partition and three
>volumes.  DOS has 55Mb, SYS has 488Mb, USR has 1517Mb, and APP has 1953Mb.
>HD#2 has one 4012MB partition for volume US2.
>	Everything went pretty smooth until we tried mounting the volumes.
>When we tried mounting US2 we got the error:
>
>	Insufficient memory available to mount volume.
>	Volume US2 NOT mounted.
>	1.1.39 cache memory allocator out of available memory.
>
>	I was able to dismount APP and USR and then mount US2, but not get
>them all mounted together.
>	I perused the FAQ and found some information on this subject and
>tried all the remedies to no avail.  I tried using the register memory
>command and now the server knows there is 64Mb available.  I tried puting
>the "Set auto register memory above 16 megabytes = off" and "Set reserved
>buffers below 16 meg = 200" commands in the startup.ncf file (no help).  I
>then tried Joe's acid test and ran "server -ns -na" and "memory" commands
>and NetWare only finds 16Mb at that point.
---------------
	Alas, the acid test is a good one. You didn't mention which version
of NetWare is involved, so let us assume it is NW 4.10. In that case there
is help available to NW in decoding what you system has in memory capacity
even though the cpu and CMOS memory decline to reveal that information
conveniently. PCI bus machines can be that difficult. The help is installation
of the compendium patch (translation: "really big") 410PT6.EXE, located in
updates\nwos\nw410 together with all the other things needed adding, and
available from ftp.novell.com and faithful mirrors thereof.
	To quote from that patch:

LOADER   EXE
============

	SYMPTOM:

	3) ADDED support for using the new BIOS call int 15 sub
	function E8 for memory detection on PCI machines and other
	ISA machines that have more that 64 Meg of memory.

...
	13) ADDED the new DoProtectedModeBIOSCall to the loader for
	use by ODI with new PCI device drivers.  This API allows a
	driver to make protected mode calls to the BIOS.

	If that still does not help then I have only one more recommendation:
beat up on the machine's Bios Setup (and any supplemental configuration
programs shipped with the machine) to set the memory capacity correctly.
Actually, I have another: try loading himem.sys (not emm386 et al, just
himem.sys) in config.sys. That can sometimes coerce the machine into
revealing its true capacity, and other times it just becomes a hazard best
avoided.
	And add a guess to the list: turn off all Plug & Play support. That
stuff easily confuses hardware when poked by the Bios.
	Were I in your shoes I'd strip the machine to bare metal, get it
working with NW, and only then start adding more peripherial boards. And
I trust not memory SIMMs, so look around for others to borrow to sort out
system design difficulties.
	The moral of the story is don't let the machine win without a
struggle. Apply all the patches and probe every nook and cranny to find
a way to the goal. Even subtrafuge (himem.sys) is legit.
	Joe D.

---------

Date: Tue, 31 Dec 1996 05:01:06 +0100
From: Bo Persson <bop@GANDALF.SE>
Subject: Re: Cache memory allocator out of memory problem

[Floyd: above message reply text deleted]

I had this problem installing NetWare 3.12 on a new PCI machine. It turns
out that there is a slight problem when you reach 64 MB of RAM, because
this wasn't considered in the original PC design. (IBM PC started at 16 KB!
and was never intended to have more than 1 MB).

To see 64+ MB of RAM, the software has to use an "undocumented"
BIOS function that wasn't available when NetWare 3.x was designed.
You have to apply a "loader" patch to your SERVER.EXE to get
this fixed. Yot will find that in 312PTA.EXE at

ftp://ftp.novell.com/pub/updates/nwos/nw312/

While you are there, you might want to take a look at the other patches
in the directory as well :-)

Take a look in 00Index and patlst.txt !

---------

Date: Tue, 31 Dec 1996 12:09:57 -0500
From: Dave Henderson <djhender@CC.OWU.EDU>
Subject: Re: Cache memory allocator out of memory problem

Thanks to all for the advice on my problem, especially Joe D.

	FYI:   I had downloaded  the 312 patches (312PTA.EXE) and installed
them prior to sending out my initial message and forgot to explain that in
the message.  One of the patches was LSWAP.NLM that runs LOADER.EXE.   This
didn't seem to help so I contacted my vendor and he came up today and
upgraded the BIOS on the system board.  We tried running LSWAP.NLM  from the
Server.312> prompt and it errored out saying the \NWSERVER\ LOADER.EXE and
\NWSERVER\SERVER.EXE could not be found.  the directory NWSERVER was never
created during the patch install.   We created the directory copied the
appropriate files to it and ran LSWAP.NLM  again.  This cured my problem. I
then checked the floppy that I ran the patches from initially and didn't see
a NWSERVER directory on there either.  The LSWAP.NLM and LOADER.EXE were in
the \NATIVE\LOADER directory.   I now suspect that LSWAP.NLM never ran on
the initial install of the patches and the error flashed by (Pentium speed)
so fast I didn't see it.  So, I don't know if the BIOS upgrade was really
needed.

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

Date: Mon, 13 Jan 97 05:28:07 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Fault Tolerance -Reply

>Errr. Can someone explain to me what is so great about hardware that
>needs it own tailor-made patches, uses higher priced hardware and
>uses integrated hardware. Not to mention beeing depanded on
>one vendor.

Compaq no longer needs custom patches, haven't for some time. They DO
produce driver updates, however for things like SCSI interfaces, NICs,
etc. They DO have certain advantages, like any tier 1 hardware - things
like ECC memory, hot swap drives integrated in the case, better cooling
for loaded systems, motherboard architecture designed for servers, and
management software that takes advantage of the customized hardware. A
good example is looking at insight manager; you can actually view the
current PCI/EISA bus utilization, processor utilization, hard drive
runtime, stored history for correctable and uncorrectable memory errors,
etc, etc, etc. There's also things like 3 year warranty - with 1 year on
site, etc.

Are tier 1 servers the ONLY solution? Of course not! I can tell you,
however that my clients with Compaq and HP Netware servers have fewer
problems with hardware. Those of you who recall the early days of NT,
OS/2 or Citrix may also recall the value of using compaq or other name
brands - they're the first certified, and when on the bleeding edge in
terms of software it becomes obvious that there's no such thing as 100%
compatible.

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

Date: Tue, 14 Jan 1997 16:19:49 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Read from a non present page

>>	It means what it says. That implies a wild pointer. You can add
>>a console SET command to try working around the problem. You can try
>>quarantining NW Connect (Domain for NW 4.10).
>>	It can also mean your memory system is not what you believe it
>>to be, such as a machine incapable of handling memory over 64MB without
>>side effects. To find out try it with only 64MB, if you can find the time.
>>	As a point of curiosity, NW 4.11 treats many of these crashes like
>>the flu: it quarantines the crashed process and the server continues to
>>run in a guarded state.
>
>Joe,
>	As usual your responses are quite enlightning.  I am not getting a
>crash because I am allowing the read from a non present page.  You hit the
>nail on the head when you talked about memory.  The machine is an inherited
>clone, I have another server (Dell Poweredge 2100/200) that does not have
>this problem, and is setup exctly the same way.
>	Could this problem be the cause of users getting errors in Windows
>95 and Macs when they try to save to disk, and it tells them they have no
>rights to the directory, then if they try about 10 minutes later it works
>fine?  Or another bizzare one, when using NAL and auto launching Eudora,
>some stations get a GPF, however after bootup is completed, you can double
>click the icon and evrything is fine.  Another weird error, if a user has
>full rights (Supervisor) to their directory and in the environment the home
>directory is set to the root of their folder, when shutting down and windows
>95 wants to write the desktop, Nethood, startup and user.dat file and
>folders to their directory, it gives them the error that the drive may not
>support long name spaces... yet I have the OS2 name space added and loading
>on all my drives...  is this something addressed in Intranetware?

	All I can do here is put myself in the position of the motherboard
and guess what might happen. The common case is a PCI board with say a
Triton-1 chipset which can cache only the first 64MB of memory, and
addresses above this alias down. It takes little imagination to see where
misunderstandings could occur, if they do occur.
	There are, I believe, other motherboards with the socket space for
much memory but without the decoder glue logic + Bios support to use it
properly. My own dual Pentium boards (ASUS PCI/E P54NP4) went through a
Bios revision to cover exactly this situation.
	Some Bios' support leaving a 1-2MB hole in address space under
16MB, to deal with ATI and friends memory mapped video boards. Close the
hole.
	Slow down memory access, by Bios setup conditions. Turn off those
helpful bus buffers (a few bytes), again in Bios setup. Allow for two bus
cycles between bus accesses, or more to be conservative. And so on.
	Motherboards are very inexpensive these days, so a swap is not a
major investment for clone-style machines. Reducing memory to 64MB for
a test is a no-cost check.
	Joe D.

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

Date: Tue, 14 Jan 1997 18:58:17 -0600
From: Rick Rominger <rominger@ix.netcom.com>
To: netw4-l@bgu.edu
Subject: Re: Fault Tolerance -Reply

>> >Errr. Can someone explain to me what is so great about hardware that
>> >needs it own tailor-made patches, uses higher priced hardware and
>> >uses integrated hardware. Not to mention beeing depanded on
>> >one vendor.
>>
>> Hi Arthur!
>> Compaq no longer needs custom patches, haven't for some time. They DO
>> produce driver updates, however for things like SCSI interfaces, NICs,
>> etc. They DO have certain advantages, like any tier 1 hardware - things
>> like ECC memory, hot swap drives integrated in the case, better cooling
>> for loaded systems, motherboard architecture designed for servers, and
>> management software that takes advantage of the customized hardware. A
>> good example is looking at insight manager; you can actually view the
>> current PCI/EISA bus utilization, processor utilization, hard drive
>> runtime, stored history for correctable and uncorrectable memory errors,
>> etc, etc, etc. There's also things like 3 year warranty - with 1 year on
>> site, etc.
>
>Thanks for the update concerning custom patches. Didn't know about it.
>As you might have guessed I've had some *bad* experiences with
>Compaq hardware and software and support and service.
>From those days on my views concerning Compaq became
>slightly colored. That's why I posted the question.
>To refresh my views on the subject Compaq.
>
>Back to the plusses and placed in a more general view
>(I mean compared to other vendors hardware).
>
>Do you really need ECC nowedays? It's been a long time that
>I detected failures that ECC might have overcome.
>
>Customized hardware usually needs customized drivers.
>Their prices are higher and you become more depanded on
>the vendor. And maybe run the risk of not getting full performance
>in favor of the customization. In case of trouble your only source
>is really just one (which can be a plus in some cases).
>
>Built-in features can come in the way of operations or performance.
>And do you really need them? There are many ways to detect
>bottlenecks. And many indications to inform you.
>
>1 year warranty on site is very common (at least here).
>And after that simply replacing the faulty hardware is often
>faster, cheaper and gives you more in return.
>That is if it breaks on you before you upgrade/replace the system.
>
>In short. In practise I rarely use management software to determine
>bottlenecks or locate problems. Integrated hardware usually cost
>me more time to get it working and keep it up to date with the rest
>of the system. Besides that I'm not happy when it goes NOK on me.
>And hardware updates or adding of extra hardware usually cost more.
>
>Hot swap drives and better cooling are nice.
>The motherboard design is something I place under a question mark.
>Maybe the design is more to benifit the extra's.
>
>> Are tier 1 servers the ONLY solution? Of course not! I can tell you,
>> however that my clients with Compaq and HP Netware servers have fewer
>> problems with hardware. Those of you who recall the early days of NT,
>> OS/2 or Citrix may also recall the value of using compaq or other name
>> brands - they're the first certified, and when on the bleeding edge in
>> terms of software it becomes obvious that there's no such thing as 100%
>> compatible.
>
>Fewer problems is not what I see.
>Most problems that I see concerning choice of hardware are the result
>of wanting too much for as less money as possible or not take into
>account that hardware has to be protected against the environment,
>tempature and power surges.
>
>100% compatible = buying the hardware the software was tested on
>
>* Arthur B.                   arthur-b@zeelandnet.nl

For years I have built servers from standard computers, bought from many
vendors; seldom have I had a problem that couldn't be solved.  Some of the
2.2 systems I installed years ago are still going strong.  That said, the
issue of whether to pay for a Super server like Compaq or HP becomes not
one of price, but one of performance and reliability.

In many environments, the 486 on your desktop would do fine as a server if
you merely add enough memory and disk space.  You can even save mony by
ordering the machine with a monochrome monitor and card.  Add a decent UPS
and Voila...a server.  And if the server goes down, you merely buy another
one, or swap out some parts, and you are back up and running.  You may have
to restore a backup.  Down time= 4-8 hours if you have the parts lying around.

In other environments, being down for _ANY_ length of time costs money.  In
some cases _serious_ money.  In certain environments, being down can cost
lives (granted, there are few, but there Are some).  The question you must
ask yourself, and the question you will be asked is, how much does it cost
to be down?  Compaq, HP and others make servers that are optimized for high
bus-transfer speeds--critical to a high performance server.  They have
built-in redundancy, better cooling, typically higher-quality components,
more expandability, higher reliability, the list goes on and on.  We use
Compaq servers where I work.  Each has dual redundant, load-balancing power
supplies; RAID 5 disk arrays; 256+ MB of RAM; remote control functionality;
the ability to produce metrics to identify and support the need to upgrade;
the ability to support multiple processors; the intelligence to page me if
ANYTHING fails; and a four-hour parts replacement warranty (costs extra of
course).  In addition, they are Rack mounted, designed to be easily worked
on and added to, and happen to be the industry standard.  One never has to
wonder if a Hewlett Packard printer will be compataible with Windows.  In
much the same vein, I never have to wonder if Netware will support Compaq.
I believe that Novell develops their software on Compaqs.

You couldn't give me a Compaq Workstation, but I would recommend no other
server as highly.  All that said, the reality is, you can pay extra at the
front end, by buying more expensive and reliable hardware--or at the back
end when it all falls apart (which may never happen) and you are under the
gun to get it working again so the company can do business.  If having the
network down doesn't cost much, justifying the dollars necessary for
high-end servers could be a tad difficult.

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

Date: Sat, 18 Jan 1997 03:09:00 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: 1 volume on multiple disks: is it faster?

>>>>question is: "is Netware capable of realizing the
>>>>benefits of multiple read heads from multiple
>>>>drives in a non-RAID set up"?

Yes. Netware does.
If you have multiple harddisks and multiple requests for harddisk
data access in a multi-user environment it does help if you've got
a controller that can do multiple reads and writes.
The controller does the job. Netware only requests.
Netware is software and will never out beat a hardware product
like a controller. Novell did good by directing Netware to let the
controller worry about getting the data that is requested.
And the people that assembly the fileservers offcourse <grin>.

Will spanning benifit performance?
Yes and no.
Netware doesn't guide on which harddisk the data must be put
(think of the decreased performance if Netware does keep
track of that) on spanned volumes.
So the controller does. First harddisk available gets the data.
Even that out and you wind up not beeing able to tell which
parts of which files are on which harddisk.
Concludes the write request.

Now one process request a read from a harddisk...
Netware caching is 'aware' on which harddisk the requested
data is. That is it gives the controller some numbers that
will tell it on which harddisk it is.
The controller will retrieve the requested data from the
harddisks (on average all harddisks must be accessed to
get all blocks of data of the requested file) on average in
the fastest way possible. However, it has to deal with
multiple requests from multiple processes.
So the more data requests from harddisk the bigger are
the chances that the controller must wait and thus
slow down the time to complete the data retrievel.
But harddisk requests are only needed when the needed
data isn't in the Netware cache. So that means that the
least accessed data is retrieved the fastest from a spanned
volume. The most accessed data usually is in cache.
Which is in RAM. If the most accessed data isn't in RAM
you either don't have enough RAM or your users query
for very different data all the time.
In an overall test a spanned volume wins but it's the
most requested data that counts and that should be
in RAM as much as possible.

In all cases a spanned volume misses the point.

Case 1 - Users trigger lots of harddisk requests.
A spanned volume will help you here but that is
an option when you're interested in performance.
RAM is a lot faster. Why not invest in that?
And if adding RAM isn't enough why not invest
in software that will aid the cache?

Case 2 - Users request much of the same data.
Most requests will be handled by cache.
A spanned volume will not make much
difference in such an environment. It will increase
the risk in loss of youngest data mutation loss.

Case 3 - Mixed case1 and case 2
Adding might still be an option.
And if not, why not add an extra server and devide
the most and least requested data?
At least you minimize the risk of loosing the
youngest data mutation (which cost the most to
restore).

If performance is all you want then don't invest in two disks
serving one spanned volume.
Invest in only one disk and invest the rest in RAM.
Servers do use cache and it's the fastest medium yet to hold data
on that needs to be accessed.
Don't forget to rewrite your disasterplan.
Don't say that to put you down. One thing is for sure...
Harddisks will break down and they hold the youngests data (which is
what users want to have access to right now). Accoording to
Murphy (believe me, I know him, he usually is one hour ahead of me)
harddisk failures happen at the worst possible time (say two hours
before your planned, booked and paid vacation and your backup
admin was just run over by a car). Better be prepared...

>>Well, there is mirroring, which I guess could technically be
>>considered a crude form of RAID.  You will get a gain in performance
>>by mirroring if your controller is up to the (multi) task.
>>
>>...  crude? , it_is_RAID1
>
>And RAID1 is crude, IMHO.

RAID 1 is mirroring and still better then just one disk.
Mirroring is one controller for one pair of harddisk
(one HDU beeing the mirror of the other).

>>>Expanding that to duplexing, which I believe does meet one of the
>>>definitions of RAID (Level 1 or 2?), you see increased performance
>>>without as much demand on the controllers.
>
>>... not ... duplexing and mirroring are separate. Duplexed
>>controllers don't need mirrored drives, one can duplex controllers to
>>a single disk, w/no gain in performance.
>
>Whoa, you lost me there.  In NetWare, duplexing -does- involve
>mirrored drives.  Two drives, two controllers.  Drives are mirrored
>with separate controllers.

RAID 2 is duplexing.
Duplexing beeing two controllers each with a harddisk
(one HDU beeing the mirror of the other).
Mirroring beeing a proces where each read or write to/from
the master harddisk is beeing copied to the slave harddisk.

Compared to RAID 1 you gain performance increasement
as far as writes are concerned.

>>>And mirroring and duplexing provide -redundancy-, quite the opposite
>>>of spanning.  If you are looking to gain perfomance, duplexing will
>>>outperform spanning -and- provide an increased level of fault
>>>tolerance.  The trade-off is volume size.
>>
>>... I don't follow this last sentence. Mirroring has 50% overhead,
>>but nothing at all to do with volume size.
>
>Not.  When you mirror, as long as the controller is capable, you can
>gain performance.  The controller can read/write from/to whichever
>drive is available.  Yes, the writes have to go to both drives
>-eventually-, but reads definitely gain performance.  No way is
>there a 50% overhead.

Mirroring has 100% overhead compared to duplexing because
in the first case the controller must perform two writes while
in the second two controllers get one write request at the same time.
So each write takes at least twice as long on a mirrored system then
on a duplexed system.
Performance decrease on writes is thus 50% (mirror versus duplex).

Allowing write requests to go first to the slave drive would make the
slave drive the master drive, because the master drive should be the
drive that is most up to date.
In such an environment allowing read requests to be handled by the
slave drive would require some sort of watchdog to prevent getting
a read respond from the slave drive that is overruled by a pending
write request to the slave drive (pending because the first write
request was handled by the master drive thus making it unavailable
thus freeing up the slave to respond first to the read request).

>My statement about volume size means that given two drives with X MB
>each, you can span them for a total volume space of 2X MB, or you
>can mirror/duplex them for a total volume space of X MB.
>
>David Hanson

---------

Date: Sun, 19 Jan 1997 00:18:18 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: RAID levels

>>RAID 1 is mirroring and still better then just one disk.
>>Mirroring is one controller for one pair of harddisk
>>(one HDU beeing the mirror of the other).
>>
>>RAID 2 is duplexing.
>
>No, RAID level 1 covers Disk Mirroring AND Duplexing. RAID 2 is Disk
>Striping with Bit Interleave. RAID 2 is more closely related to RAID 0
>than RAID 1, except data is written across the drives 1 bit at a time
>rather than in blocks. RAID 2 also maintains an extra drive for checksums.
>Unless you are working in a mainframe environment, I doubt you will ever
>see an implementation of RAID 2 (certainly not in a NetWare environment).
>
>Shawn Rappaport

Shawn, I stand corrected.
Looked it up and placed a simplified listing below.
However. RAID 2 does parallel read/writes.

Now I'm left wandering where I got my original RAID 2 remark from...


RAID 0
Spanned volume

RAID 1
Mirrored disk
Duplexed disk
First or second choice in Netware environments depanding on the situation.

RAID 2
RAID 0 system but at the bit level with multiple parity disks.
Example: four data drives requires three parity disks.
Every disk access occurs in parallel.

RAID 3
RAID 0 system but at the byte level with one parity disk.
Plus: any one drive may fail without that causing loss of data.

RAID 4
RAID 3 system but at the sector or block level.

RAID 5
RAID 4 system but the parity disk is spanned also.
Resulting in each disk having part of the (virtuel) parity disk.
First or second choice in Netware environments depanding on the situation.

RAID 6
Can be:
RAID 5 system with added hot spare disk -or-
RAID 5 system with extra added disk so that two drives may fail -or-
RAID 5 system with modified striping method.

RAID 7
RAID 4 (?) system with caching using a dedicated processor.

Stacked RAID: RAID 0/1, RAID 0+1, RAID 10
RAID 0 system but each disk is actually a RAID 1 array.
Example: spanned volume over two pairs of mirrored disks (total=4).

Stacked RAID: RAID 5
RAID 5 system but each disk is actually a RAID 5 array.
Plus: you can build arrays with large capacity.

---------

Date: Sun, 19 Jan 1997 10:12:33 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: RAID Level 0 correction

	Arthur B wrote today about RAID levels; but he didn't quite get the
RAID Level 0 definition quite right: RAID 0 is  *not*  "spanning" (where
smaller drives are combined into a single large volume): RAID 0 is
*striping*  where the data stream is divided among two or more drives.

	RAID 0 is typically used in video and photo editing workstations in
order to maximize sustained transfer performance:
	1) To avoid dropped video frames while capturing and printing to tape;
	2) When you are opening and saving photo files in the 10's to 100's
of megabytes;
	3) When using a scratch disk with Photoshop.

	With RAID Level 0, the object is to maximize sustained transfer,
with data safety and access times are ignored. This is especially true in
video, where if a drive blows out, just run the tape and recapture... No
big deal.

	RAID Level 4 is essentially a RAID 0 array, with an extra HDD for
parity information to provide a modicum of data safety.

	An excellent source for RAID info is at Carnegie Mellon University.

---------

Date: Mon, 20 Jan 1997 02:37:42 +0100
From: "Arthur B." <arthur-b@ZEELANDNET.NL>
Subject: Re: RAID Level 0 correction

>Arthur B wrote today about RAID levels; but he didn't quite get the
>RAID Level 0 definition quite right: RAID 0 is  *not*  "spanning" (where
>smaller drives are combined into a single large volume): RAID 0 is
>*striping*  where the data stream is divided among two or more drives.

Indeed. It's called striping.

But dividing the data stream amongst two or more drives only comes
into the picture, as far as Netware is concerned, when Netware is
talking about a spanned volume in relation with RAID 0.

If one would have a Netware situation where two disks and two volumes
are concerned then all data for the one volume goes to the same
harddisk. RAID 0 is about spreading the data amongst several
harddisks (the first available) to increase performance.
Within Netware the "target" (volume) is usually on one disk only.
You can however increase performance by deviding the "target"
over several harddisks.
This is why I referenced RAID 0 as beeing a spanned volume
in my simplified listing.

---------

Date: Sun, 19 Jan 1997 10:34:28 -0500
From: Steve Kurz <skurz@NORFOLK.INFI.NET>
Subject: RAID Level Definitions (Long)

Just for clarity, here are the accepted definitions of the RAID
levels.

The term RAID (Redundant Array of Inexpensive or Independent Disks)
was coined in 1987 by a group of computer scientists who met in
Berkeley, California with a mission to define alternate ways by which
multiple disks could be combined to provide increased levels of data
fault tolerance and performance.

RAID levels are defined as follows:

RAID-0
	Consists of Striping data across multiple drives in parallel
	sectors across multiple disks. I/O transfer rate is increased
	compared to that of a single disk. This level of RAID does not
	protect data. A single disk failure can cause a total loss of
	data.

RAID-1
	Commonly called "MIRRORING", data is duplicated on a pair of
	disks for data protection. In addition to redundant protection,
	read performance can be faster than a single disk due to
	overlapping reads.

RAID-3
	A single drive is used to accomplish data protection similar to
	that used in DRAM (parity). Typically the drive spindles are
	synchronized and the group or array of disks behave as a single
	large disk. For any access RAID-3 requires all disks to respond
	regardless of the size of data requested. The system is only as
	fast as the slowest drive in the array. Data cannot transfer
	until the last bit is in from the last drive. Random read/write
	environments will generally achieve a level of performance
	significantly below that of single disks.

RAID-4
	Parity is interleaved on the sector level rather than the byte
	level at this array level. Small reads can be satisfied by a
	single disk providing for improved performance. Writes still
	require two disk involvement (data and parity) or more correctly
	data drives plus one (D+1) for transfers spanning more than one
	data sector. The parity disk is the bottleneck during write
	operations. Performance is significantly better than a single
	disk under read conditions but suffers from a write penalty.

RAID-5
	Parity information is spiraled across all drives. This design is
	meant to address the single drive parity throughput bottleneck of
	RAID-4. Level 5 works well in heavy read applications. Maximum
	throughput is limited to total drives minus one (N-1) times
	individual disk throughput rates. Typical write groups are
	limited to 5 drives; as many as 12 have been seen. The
	distributed parity tries to improve write performance but still
	requires a two drive involvement for every write. Writes still
	require at least a two disk involvement (data and parity) or more
	correctly data drives plus one (D+1) when spanning more than one
	data drive. A read of the parity drive sector followed by a
	parity calculation using the write data and then a write of this
	new data to the parity drive. An additional full rotation of the
	parity disk is required to complete the parity update.
	Distributed or spiraled parity introduces a high
	processor/calculation overhead to maintain parity locations.
	Write environments, especially random write environments,
	generally achieve a level of performance significantly below that
	of single disks. OLTP random writes (8K typical UNIX) can achieve
	throughput rates less than half that of single disks. Caching
	improves performance in random write applications until the cache
	fills at which time fundamental limitations in parity management
	limit performance.

RAID-6
	A dedicated parity drive has independent data and control paths
	and can receive cached transfers from an independent parity bus,
	a cache bus or an external bus. Independent dedicated cache and
	control/data paths extend to each disk in the array. This level
	is considered a dedicated device memory cache with independent
	transfer and control paths. This level is generally believed to
	have performance advantages over level 5 in large and small file
	reads and still has potential to improve on its small and large
	file writes.

RAID-0/1 or 10
	Consists of striping data across multiple RAID-1 disks in
	parallel sectors. I/O transfer rate is increased compared to that
	of a single disk. A single disk failure does not cause a loss of
	data. In addition to redundant protection, read performance can
	be faster than a single disk due to overlapping reads. Striping
	provides for load balancing and improved read and write
	performance as compared to single disks. Obviously the investment
	in disks is doubled because of the mirroring.

RAID-7
	RAID level 6 improved on level 5 by adding asynchronous and
	cached transfers without providing asynchronous control and data
	paths for all I/O activity. Level 7 provides complete independent
	and asynchronous I/O paths for each I/O and device path. Host
	interface and I/O devices have separate cache as well as
	independent control and data paths. Each device is connected to a
	high speed data bus with a central cache to service multiple host
	and I/O paths. A real-time embedded process oriented operating
	system is central to the architecture. One major benefit is the
	incorporation of parity generation in the dedicated cache under
	control of the real-time operating system. Under heavy load the
	dedicated parity drive can be queued and cached to more optimize
	updating of parity resulting in increased performance. Reads in
	one area of the disk array do not affect write activity. Multiple
	read or write requests, equal to the number of data drives, occur
	concurrently from disks. Data is striped on a granular level at
	2, 4, 8, 16 or 32K per disk. Granularity can be optimized to
	improve data access and result in increased performance.
	Granularity allows a single disk in the array to satisfy a single
	read request. RAID-7's ability to stripe across up to 46 data
	drives in a single array provides load balancing superiority over
	all other RAID levels. Shared access to the same data within the
	array is provided as a standard configurable capability. To
	properly take advantage of this aspect of the RAID-7
	architecture, HACMP or some other method of file locking or
	coordination of files needs to be incorporated.

---------

Date: Mon, 20 Jan 1997 08:08:41 -0500
From: Dan Schwartz <dan@SNIP.NET>
Subject: RAID!  :)

>>The term RAID (Redundant Array of Inexpensive or Independent Disks)
>							       ^^^^^
>Most "modern" definitions have also changed "Disks" to "Devices".

	True: I have seen RAID striping used on CD's for better multimedia
playback, and on DAT's for faster backup.

	A couple of final points on RAID Level 0:

	1) I usually choose a stripe size equal to or an even multiple of
the allocation block size for the volume, i.e. if the volume allocation
block size is 32 kilobytes then I set the stripe size PER DISK to 32, 64,
128, or 192 kilobytes;

	2) Watch out for the definition of "stripe size:" Some formatters
define it as the stripe of data placed on each drive, while others define
it as the chunk size of data that is spread across the drives that make up
the array;

	3) Watch out for bad blocks with RAID 0: They can destroy performance;

	4) Onboard disk drive caching algorithm plays a larger than
expected part in RAID 0 performance, especially when the SCSI-2 Error
Recovery Parms ARRE (Auto Read Reallocation) and AWRE (Auto Write
Reallocation) on Parameter Page 1 are enabled;

	5) Test, test, test before placing an array into service: Different
settings can radically alter the performance.

	For some sample graphs of RAID 0 and drive performance with various
settings, point your browser to
<http://www.snip.net/users/dan/HDD-Test.html>

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

