------------------------------------------------------------------------ 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 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" 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 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 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 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 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 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" 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" 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 To: "NetWare 4 list" 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 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" 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." To: 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." To: 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 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 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 To: "NetWare 4 list" 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" 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" 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 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 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 To: "NetWare 4 list" Subject: Re: EIDE VS. SCSI >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" 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 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 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 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 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 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 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 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)" 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 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 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 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 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 To: "NetWare 4 list" 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 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 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." 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 . 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." 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 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." 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 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 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 ------------------------------