[ H(1) | H(2) | H(4) | Novell FAQ Home Page ]

H.25.2 NetWare Memory Requirements -- How Much Is Enough?

A Novell Application Note Supplement published in December, 1994 entitled "Calculating Memory Requirements for NetWare 3 and 4" stated "The server memory calculations included in NetWare 3 and 4 documentation are out-dated and in some cases produce wildly incorrect requirements."

The Application Note Supplement mentioned previously included a more detailed worksheet for calculating server memory requirements. The same worksheet can be used for both 3.x and 4.x versions of NetWare. Even this worksheet is inadequate in many cases, for example when CD-ROMs are mounted as NetWare volumes. A separate Application Note Supplement contains additional considerations, but no definite forumlae, for multiple Name Space support. The worksheet, with additional comments and instructions follows:

    STEP 1:  DETERMINE THE FOLLOWING SEVEN VALUES FOR YOUR SERVER

V1. Enter the total megabytes of disk connected to the server:___MB

For example: enter 1 for each MB, enter 1024 for each GB. Do NOT include CD-ROM volumes that'll be mounted as NetWare volumes. These have their own memory requirements not adequately covered in these Novell formulas, and will be calculated later.

     V2. Calculate megabytes of useable disk space connected to server:___MB

If you are mirroring or duplexing all partitions this will be one-half of V1, otherwise copy V1.

     V3. Enter the server's volume block size (4, 8, 16, 32, or 64): ____KB

V4. Calculate disk blocks/MB (Divide 1024 by the value V3):____Blocks/MB

The Blocks/MB can be determined using the following table:

Block Size (KB) | 4 | 8 | 16 | 32 | 64 | -----------------+-----+-----+------+------+------+ Blocks/ MB | 256 | 128 | 64 | 32 | 16 |

V5. Calculate the total disk blocks (Multiply V2 * V4):____Blocks

This calculation assumes that all volumes on a server have the same block size. If you have various block sizes, separately calculate the number of blocks of each size, and add the number together to get V5.

     V6. Enter the maximum number of clients attached to the server:___Clients

Be sure to include as clients such devices as printers with built-in network connections or other external print servers, mail servers, application servers, and gateways that reside on computers separate from the file server but need to be "logged in" to the server.

     V7. IF SUBALLOCATION IS ENABLED, enter the maximum number of files that
         will reside on the server:_____Files

STEP 2: CALCULATE YOUR SERVER'S BASIC MEMORY REQUIREMENTS

Line 1: Enter the base memory requirement for the core OS:_______KB

Enter 2048 for NetWare 3, or 5120 for NetWare 4.

Line 2: Calculate the memory requirements of the NetWare Media Manager (Divide V1 by 10):_______KB

Line 3: If File Compression (NetWare 4.x only) is enabled, enter 250, otherwise enter 0:________KB

Line 4: If Suballocation (NetWare 4.x only) is enabled, calculate the required memory, otherwise enter 0:_________KB

Multiply V7 * .005 (or divide V7 by 200).

Line 5: Calculate the memory required to cache the FAT (Multiply Line V5 * .008):_________KB

Line 6: Calculate the memory requirement for file and directory caching using the following table:________KB

This calculation assumes a 0.4MB file cache per client memory requirement. The number decreases as the user size grows, based on the assumption that there is increasingly repetitive use of shared data already in the cache.

    	 Less than 100 clients    V6 * 400
      Between 100 and  250 clients    40,000 + ( [V6 - 100] * 200 )
      Between 250 and  500 clients    70,000 + ( [V6 - 250] * 100 )
      Between 500 and 1000 clients    95,000 + ( [V6 - 500] *  50 )

Line 7: Enter the total memory (KB) required for support NLMs:________KB

2,000 KB is recommended by Novell for BRIEVE (700), CLIB (500), INSTALL (600), and PSERVER (200). Almost all servers will require these, although INSTALL is probably only needed occasionally and could be loaded only when needed. If you will allocate memory to Btrieve's own cache over the default amount of 256 (an option available with Btrieve versions 6.x), add the additional amount to the 2,000 value. If you will be loading TCP/IP on the server, add XXXXXX KB.

     Line 8:  Enter the total memory (KB) required for other services:_______KB

Other services include NetWare for Macintosh, NetWare for SAA, NetWare SQL, OracleWare, NetWare Management System, and so on. The memory requirements should be listed in each product's documentation.

    STEP 3: CALCULATE YOUR TOTAL MEMORY REQUIREMENT

Line 9: Sum Lines 1 through 8 for your total memory requirement:______KB

Line 10: Divide Line 9 by 1024 for a result in MB:______MB

If you will not be loading additional Name Spaces or using CD-ROM volumes on your server, you are finished.

Optional Name Space support requires additional memory for directory caching. Each directory entry is 128 bytes long. NetWare caches the DET in 4 KB blocks, each containing 32 entries. When only DOS Name Space is loaded, accessing a directory entry for one file automatically brings the directory entries for 31 additional files in the same subdirectory into memory. Client requests to access any of these directory entries are then serviced out of memory without requiring another disk read.

When another Name Space is loaded, each file is given a second directory entry for the necessary Name Space information. Ideally, all the Name Space entries for a particular file are kept together in the same block.

This is a good reason for adding name spaces when you create the server, and not after - if you go back and add a name space later, then the DET entries for each file that exists at that point will be in two separate places. The original entry for the implicit DOS namespace will be wherever it was created, and the second entry for the other namespace will be in whatever was free space at the time you added the second namespace. Files which are added after that time will generally have their directory entries placed together.

[Thx S.M.D.]

With two Name Spaces loaded, a block can only hold directory entries for 16 files. With three Name Spaces, there are ten files per block (with two wasted entries), and eight per block with four Name Spaces. Because of this, clients' disk access speed will decrease noticeably as additional Name Spaces are loaded if the same amount of memory is allocated to caching directory entries. Having multiple Name Spaces loaded does not increase the memory used to cache the files themselves, only memory caching the DET. Thus, to accomodate the additional memory needed to prevent loss of performance, increase the number in Line 6 above by 25 percent for each additional Name Space loaded.

[NetWare 4.10's CDROM3.EXE's] CDROM.NLM uses a 64 KB block size for all CD-ROMs, reducing the memory needed for FAT caching. To calculate memory needs for CD-ROM volumes, use the following methods:

[Thx S.M.D.]

    Divide the total size of all files on the mounted CD-ROM volumes (in
    megabytes) by 10 to get the kilobytes required for the NetWare Media
    Manager:______KB

Divide the total size of all files on the mounted CD-ROM volumes (in megabytes) by 8 to get the kilobytes required for caching the FAT:____KB

Add the above two numbers, plus 80 KB for each CD-ROM volume. For example, for two CD-ROM volumes with a combined 1 GB (1,024 MB) of files, the result would be 102 KB + 128 KB + 160 KB = 390 KB.

This calculation does not allow any additional memory for file and directory caching of the CD-ROM; it is assumed that this requirement will be met by the formula in Line 6 above. If you have a server with a large number of CD-ROM drives atached compared to the hard disk space installed, this result may be inadequate.

Going through the above exercise will result in a memory requirements estimate usually several times the amount from the "quick and dirty" formula in the Red Book. It is a much more accurate number, but still an estimate.

[Many thanks to Jerry Heidtke for this info]

H.25.3 NetWare Memory Requirements -- And The Real World

Of course, any memory formula can only approximate the actual network and disk traffic you'll be experiencing when the server is really serving your users and/or other tasks (database/WWW/DNS server, routing, antivirus protection...) you assign to it. But if your server is up and running, you can just look to see if it is has enough memory _at the moment_ you look at it. At the console, load MONITOR and go to the Cache Buffers. Check the "LRU sitting time" item. "LRU" stands for "Last Recently Used page of cache memory" and the number is the typical time your data spend in the cache (without being accessed) before the cache is needed elsewhere. That is, if somebody wants to access the same data later, it will be reloaded from the disk.

If the value is less than 10 minutes, you should definitely add some memory. The recommended values (sources vary) are within the range from 12 to 20 minutes. More than one hour means you don't need that much memory ...at the moment.

Be sure you're checking LRU sitting time during the utilization peaks, when there are the maximum number of users actively attached.

[Thanks Jirka Hanika]

H.26 How to wire 10base-T cable using RJ-45 jacks

To wire 10base-T cable using RJ-45 jacks and 8-wire unshielded twisted pair cable, depending on your specification, here's what you'll need:

    		| Color Code   | 568A | 568B
      --------------+--------------+------+------
       Pair 1: tip  | white/blue   |  5   |  5
    	   ring | blue/white   |  4   |  4
       Pair 2: tip  | white/orange |  3   |  1
    	   ring | orange/white |  6   |  2
       Pair 3: tip  | white/green  |  1   |  3
    	   ring | green/white  |  2   |  6
       Pair 4: tip  | white/brown  |  7   |  7
    	   ring | brown/white  |  8   |  8

If you are starting with new wiring, use 568B. If you are using old AT&T installations (pre M11 and M100 jacks), use 568A.

[Thx D.E.C. & H.K.]

H.27 Advantages of purging files

In theory, manually purging files on NetWare should not be necessary. Experience has shown, however, that there are advantages to purging.

Purging files that are temporary in nature allows other more essential deleted files to have a longer "deleted but not purged" (ie. still salvageable) life. Also, any \TEMP directories, and all print queue directories (those funny numbered ones under SYS:system), should be marked with FLAGDIR [in NetWare 3.x, FLAG in NetWare 4.x and not possible in NetWare 2.x as it only stores one deleted file per user, and this is lost on logout] as "purgeable" e.g. FLAGDIR Z:\SYSTEM\10000001 PURGE

[Thx S.M.D.]

One other benefit of purging files manually (or explicitly with FLAGDIR) before NetWare is forced to re-use their space is that NetWare seems to run better (probably from less RAM wasted keeping track of deleted files). This improvement may be more noticeable in NetWare 3.x than 4.x.

Finally, the command SET MINIMUM FILE DELETE WAIT TIME = x timeunits can be used to set the time that must expire before NetWare considers deleted files purgeable.

[Thanks to J.P. for this info]

H.28 Moving user rights/passwords from server to server

There is no way to dump users out of the bindery with a password, there just isn't a function call to read the bindery password. There are several programs which will read all the user's properties (except password) and dump them into a file compatible with MAKEUSER.

Assuming that users on all the servers will stay the same, there are two ways I know of to transfer users to a new server. If you are totally reorganizing your servers, it would probably be best to start from scratch.

Method #1 - use your tape backup. This is also a great time to test it. We found out this way that ours wasn't handling the binderies correctly.

Method #2 - copy the bindery. You'll need something like the Trustee or TList program from JRButils or WSchrieb packages. Then, run Bindfix on the old server TWICE so that the .OLD files are current. Then BindRest the .OLD files on the new server.

[Thx B.F.]

Note: The text files from the above utilities don't quite match the format needed by GRANT, so some simple hand editing will be necessary before GRANT will accept them. Best to practice this before committing to the formal server change.

[Thx Joe D.]

Note2: The program from JRBUTILS mentioned above, for listing trustee assignments, is TrstList. It has an option to list the trustees as 'grant' commands (the version to be released in Nov, 1995 can also output as 'rights' commands for 4.x), so no editing is required unless of course you are moving to a volume of a different name.

    	ftp://netlab2.usu.edu/apps/jrb400a.zip
    For Netscapers:
    	ftp://netlab2.usu.edu/sys/anonftp/apps/jrb400a.zip

[Thx J.R.B.]

H.29 Spanning a volume across multiple hard drives

There are probably only two situations where you want to do this:

     - If you have redundancy, in the form of RAID, mirroring, or duplexing
     - If you simply don't care about the data you're putting on that volume.

If you span a volume across multiple hard drives, essential information such as the file allocation tables, the directory entry tables, and even the files themselves will be split across the drives. The loss of any single drive destroys the _entire_ volume, as some of each of the above types of data will be lost. That's right - not just the data on that one drive, but the _whole_ thing. Probably not what you want!

Keep in mind also that the MTBF (Mean Time Between Failure) of a number (n) of identical drives is the MTBF of one drive divided by n. That means n times as many failures, on average, in any given period, and each one of those failures takes your whole volume with it. Each time it fails, you'll be recreating the volume and restoring all that data. Oh, and if it's your SYS: volume, you'll have to reinstall NetWare first.

[Thx S.M.D.]

H.30 Load Balancing NLMs

The Novell document TID1200307, dated Mar 8/95, suggests:

     To load balance between NICs on a Novell network , you can
     use one of three (sic) different options:

(1) NLSP - NetWare Link State Protocol, found in

ftp://netlab1.usu.edu/pub/mirror/odi/ipx_rtr/ipxrtr.exe

or

ftp://ftp.cc.berkeley.edu/pub/nlsp/ipxrtr.exe

[Thx S.R.#2]

(2) Kalpana - 1-800-488-0775, provides inbound and outbound load balancing to provide additional server capacity without routing.

(3) NSI - Network Specialists Incorporated, 1099 Wall St. West, Lyndhurst, NJ 07071, (800) 775-4674, (201) 804-2799, (201) 804-8400, provides recovery and load balancing, reports when interface card or link is down.

(4) Ornetix - 800-965-6650, provides load balancing, peer level access with full security and network redundancy.

[Thanks to Joe Harrison for forwarding this info]

H.31 Should I use SCSI or IDE hard drives on the file server

Go SCSI. Here are three reasons:

(1) Want to add, say, a tape drive and a CD-ROM on the server? Most (though not all) ATA host adapters allow a maximum of two devices, and the rest stop at four. In normal use, SCSI goes to seven. Also, the selection of SCSI tape drives far exceeds that of ATA tape drives. And at the moment, at least, there's far more support for devices other than hard drives connected to SCSI than to ATA. Want to run a CD-ROM out of your server? You have many options if it's SCSI, and not many (presently zero, I think, though I'm not 100% sure) if it's ATA. Check the spec sheets for BackupExec, ARCserve, etc. and see how many ATA tape drives they support, and then see how many SCSI tape drives they support.

(2) SCSI is inherently well-suited for multitasking systems. The server can fire off several requests to the drive, and then go off and do something else (like servicing someone else's requests out of cache) until the drive has the data ready. Heck, the drive doesn't even have to return the results in the same order as they queries, if it can find a more efficient way to handle them. For ATA, not only can it only handle one request at a time (that's one in total, not one for each drive), the CPU generally sits idle while that request is being handled.

(3) Want to talk top speed? The most common SCSI these days is Fast SCSI-II, at 10 MB/s. The most common ATA is plain old ATA; I'm not sure how fast that goes, but it's significantly lower. The next step up for SCSI is Fast Wide SCSI-II, at 20 MB/s. No ATA variant gets that high; they top out at 11 or 13 MB/s or somewhere in that vicinity. I'm not saying that either one can sustain this (hard drives aren't anywhere near that quick yet, so it would take several drives per host adapter to sustain that transfer rate even for sequential access) or that most systems will show any significant performance difference, but someone is sure to say "ATA transfer mode blah blah blah runs at this speed, and SCSI only does 10," so let's compare apples to apples.

[Thx S.M.D.]

    TECHNOLOGY      INTERFACE  THEORETICAL THROUGHPUT     # OF DEVICES/BUS

    SCSI            Parallel   5 MBps (8-bit bus)         7 (excluding HBA)
    Fast SCSI       Parallel   10 MBps (8-bit bus)        7 (excluding HBA)
    Wide SCSI       Parallel   10 MBps (16-bit bus)       15 (excluding HBA)
    Fast-Wide SCSI  Parallel   20 MBps (16-bit bus)       15 (excluding HBA)
    UltraSCSI       Parallel   20 MBps                    8 or 4 (depending
                                                              on bus length)
    Wide UltraSCSI  Parallel   40 MBps                    16,8,4 (depending
                                                              on bus length)
    Ultra2SCSI      Parallel   40 MBps (16-bit bus)       15 (excluding HBA)
    Wide Ultra2SCSI Parallel   80 MBps (32-bit bus)       15 (excluding HBA)
    SSA             Serial     80 MBps per adapter        127 devices/setup
    FC-AL           Serial     200-MBps (dual-channel)    127 devices/setup
    USB             Serial     1.5 MBps                   127
    Firewire        Serial     50 MBps                    63
    FC-EL           Serial     200-400 MBps (estimated)

[Thx S.R.#2]

H.32 Expected bandwidth from "10 Mbit" ethernet

Lab tests have shown that an Ethernet network can approach 95% utilization. [Real world percents are more in the 50% to 60% range, before collisions make efficiency head toward zero.] Much depends on the number of nodes on a segment(s), the length of cable(s) and the packet (frame) size.

A 167k eText version of _Measured Capacity of an Ethernet: Myths and Reality_, by Boggs, Mogul and Kent, DECWRL 88/4, is available at:

    	ftp://netlab2.usu.edu/misc/ethercap.zip
    For Netscapers:
    	ftp://netlab2.usu.edu/sys/anonftp/misc/ethercap.zip

Also, the 336k _Binary Log Arbitration Method_, by M. L. Molle at:

    	ftp://netlab2.usu.edu/misc/blam.zip
    For Netscapers:
    	ftp://netlab2.usu.edu/sys/anonftp/misc/blam.zip

And Don Provan's 20k _Ethernet Frame Type History_ (heavily quoted in section L of this FAQ) at:

    	ftp://netlab2.usu.edu/misc/ethernet.txt
    For Netscapers:
    	ftp://netlab2.usu.edu/sys/anonftp/misc/ethernet.txt

[Thx Joe D.]

H.33 Performance considerations of Bridges versus Routers

Many have turned to multiport routers to divide their traffic into smaller units (segments), even though routers introduce a significant delay when processing the lan segments. Routers also complicate the network management tasks as the segments created by the routers should exits as a separate logical subnets.

A virtual lan minimises this problem by acting as a bridge rather than routing the traffic for different segments within the same virtual lan. Allowing multiple segments per subnet means fewer routing bottlenecks.

Virtual lans (layer 2) are based on a bridged architecture that transmits media access control (MAC) source and destination addresses. Traffic between virtual lans is handled by the router which provides security, filtering and traffic management.

There are two kinds of switching hubs:

* Port-Switching hubs: In this case the ports are grouped together and assigned to segments via network-management software. Port-switching hubs broadcast traffic to the group of ports which the recipient is a member of, limiting unnecessary traffic.

    	+----------------------+
    	|            __________|____User A
    	|            |         |
    	|  ------------------  |
    	|  ()   ()   ()   ()   |
    	|  ------------------  |
    	|                      |
    	|            __________|____User B
    	|            |         |
    	|  ------------------  |
    	|  ()   ()   ()    ()  |
    	|  ------------------  |
    	+----------------------+

* Segment-Switching Hubs treat ports as separate sements and forward the packets from port to port. They also transmits packets directly to their destination, thereby increasing the network capacity.

    	+----------------------+
    	| () () () () () () () |
    	| () () () () () () ()------User A
    	| () () () () () () () |
    	| () () () () () () ()------User B
    	| () () () () () () () |
    	| () () () () () () () |
    	+----------------------+

Each switch reads the incoming frame and learns the MAC address associated with each virtual lan. If the end station broadcast or multicast frames these packets are distributed to all ports in that end station's virtual lan.

Pure Ethernet switches cache the MAC address and information about which port the mac address is connected to. In virtual lan switches, a virtual lan number is added to the mac and port information in the forwarding table.

There are three methods of conveying the information:

* Signaling Messages

With Signaling Messages, when an end-station powers up, the local switch learns its virtual lan number and sends a high priority number to other switches so that they learn and update their forwarding tables. In a large network this synchronization process can become a bottleneck. Every time a station powers up it sends its frame, and this message must be propagated to all switches before the traffic can flow. Along with this synchronization the switches also send the cache table so that each of them can also update their table. This can cause the tables to grow to 1000 bytes or more.

* Frame Tagging

With Frame Tagging, a short tag is appended to the start of the frame that passes the backbone. The tag identifies the virtual lan it belongs to and also ensures that the switch knows the port group of each frame. The addition of this tagging information can cause these frames to become longer than Ethernet's maximum frame length, thus violating the ethernet's media protocol. Bridges and other forwarding devices treats these as long frames which means that these packets are discarded. Switch vendors implement prorietary schemes to deal with this problem.

* Time-Division Multiplexing

Switches that handle virtual lans at layer 2 can also use the standard spanning tree algorithm. The spanning tree algorithm is a very simple low-level protocol that is fine for bridges but it can be a problem when scaled up to a large virtual lan. Switch vendors also provide proprietary solutions to deal with this problem, typically by adding enhancements to the algorithm to make it faster and more robust.

Because layer 3 virtual lan switches can route and bridge, the need for routers in workgroups and departments is greatly reduced. One protocol problem is the inability to handle non-routable protocols like NetBios and LAT. Layer 3 switches cannot sub-divide non-routable protocols into differnet virtual lans. Layer 2 virtual lans are protocol-independent making them better suited to subdivide nonroutables.

Despite the problem with non-routable protocols, layer 3 virtual lans have more intelligence and processing power than layer 2 devices. Layer 3 devices also provide additional features such as filtering, where you can block or pass traffic by looking at the user defined frame fields. For example, switches can keep RIP/SAP traffic and Telnet packets off certain segments within a virtual lan.

With IEEE 802.10 secure data exchange it is possible to merge some layer 2 strengths within layer 3 virtual lans. This scheme specifies techniques such as fragmenting and then reassembling of frames that exceed the maximum allowed by the ethernet media protocol. Because of this 802.10 can convey virtual lan information accross a number of media types including FDDI, Ethernet, Token-Ring and HDLC networks.

As a rule of thumb, throughput decreases and latency increases as the amount of processing the switch has to perform to forward the packets to the correct port increases. The packet handling process involves looking up the MAC address which is a layer 2 function. Layer 2 can provide very high performance if the packets are being shunted between stations that belong to the same virtual lan. When the nodes are attached to different segments, the packets have to traverse over routers which could mean degradation. When handling 64-byte packets, ethernet switches deliver maximum wire speed rates (14,880pps)

A minimum size packet of 64 bytes takes 51.2 microseconds to propagate. Each frame also has an 8-byte preamble, not considered part of the frame, that takes 6.4 microseconds to propagate. Finally there is a 9.6 microsecond inter-frame gap. If you divide one second by the sum (67.2 microseconds), you get 14,880, the max number of packets a 10mbps can deliver.

A virtual lan can also take a performance hit when it handles larger packets. Cut-through switches process packets at a constant rate, regardless of packet size. Under Cut-Through switches read the mac address (the destination address) of each packet and then immediately send the packet along. The Cut-Through procedure reduces the latency or delay for a forwarding operation. In Store-and-Forward each incoming packet is stored in a memory buffer at the incomming switch port before it is forwarded to its destination. Loading the packet into the buffer takes time, the larger the packet the longer the delay. CRCs are used to ensure that frames are well-formed. Store-and-Forward switches discard RUNTS (short frames typically disrupted by a collision) and JABBERS (overly long frames sometimes caused by defective NICs). Cut-Through switches do not filter out these bad frames. Jabbers often look like broadcast frames to a Cut-Through switch and can cascade all over the network if nothing is done to eliminate them.

Today switches are implementing both Cut-Through and Store-and-Forward techniques. Initially the switch will be setup as Cut-Through but when the packet rate increases beyond user-defined frame settings the Store-and-Forward method will be used.

With Full-Duplex ports the ethernet connection does not have to listen for collision, as no other traffic source is there to collide with. For this reason a connection can freely receive and transmit at the same time. If everything is balanced properly you can attain 20mbps.

"100vg" eliminates packets collisions and permits more efficient use of network bandwidth. It does this by using a demand-priority access scheme instead of the CSMA/CD scheme used in 10BaseT ethernet and fast ethernet. It also requires users to install new network adapter cards, hubs and/or switches.

In each round-robin polling sequence, every port on the network has the opportunity to send one packet. When a tremendous volume of traffic is on the network, the hub or switch can take a long time to service normal requests, possibly causing timeouts and congestion. Thus, no matter which access method you use, depending on the traffic, things are bound to slow down and cause latencies.

[Many thx V.K.R. and J.R.B.]

Here are some URLs for switching equipment vendors:

> http://www.3com.com

> (3Com, look at LP2016, LP2500 & LP6000)
> http://www.ctron.com (Cabletron)
> http://www.cisco.com (CISCO, look at the Kalpana Switches)
> http://www.smc.com (SMC, look at the Tiger Switch)

[Thx J.M.#2]

H.34 Data Transfer by Bus type

The following table originally appeared in Network VAR:

    	BUS   WIDTH   Speed  Capacity
    	      (bits)  (MHz)   (Mbps)

ISA 8 8.25 4* ISA 16 8.25 8.25* EISA 32 8.25 33/40/80 VESA 32 CPU (40) 160 (max) MCA 32 8.25 33 PCI 32 33 132 PCI 64 33 264 PCI 64 66 528

* Uses two clock cycles per transfer

[Thx J.H. & S.M.D.]

H.35 Maximum wiring lengths

For 10Base2, the limits are:

    	Maximum length per segment:   185m
    	Minimum length PC-to-PC:      0.5m ?
    	Maximum PC's per segment:      30

If you are talking about the yellow cable (10Base5)

Maximum length per segment: 500m Minimum length PC-to-PC (2 vampire taps): 1.5m ? Maximum PC's (vampire taps, per segment): 50

[Thx M.M.]

Remember that a separate metal conduit or raceway will prevent HF signals from interfering with the signals in Cat 5 cable and vice-versa. Most cabling systems manufacturers have guidelines on distances to powerlines. Ask them for it. Consider installing enough wall-outlet's per square meter to run _everything_ except lightbulbs and coffee machines over the new cabling system, this includes your telephone system. The people who maintain your switch will appreciate being able to move people with phones in minutes, not days. You might pay a lot more in advance on cabling but a good cabling system will pay for itself because of less money spent on:

- Money spent on extra hours (extra personal)
- Time spent on changing cable
- Materials
- Finding cabling problems
- Calling in a cabling contractor
- Asking us to help :-)

[Thx H.K.]

Also on CAT5 structured cabling:

- 3 feet from all electrical in runs over 50 feet
- 1.5 feet from all analog/hybrid voice cable
- minimum bend radius 1.5"
- sloped approaches to wall stubs (conduit to box) rather than straight drops

[Thx L.D.]

H.36 AC Power and its effect on file servers

For good info, go to:

> http://www.apcc.com/

> and

> http://www.mcp.com

[Thx S.R.#2]

> http://www.magna.com.au

H.37 Negative numbers from CHKVOL -- yup, time to worry

Immediately you should run VREPAIR "at least twice" and "at least once more after you get no errors from it".

[Thx Joe D.]

H.38.1 Running Netscape across NetWare (vs dial-up)

Running Netscape from home is pretty straightforward. You just need a Winsock.dll like the shareware version from Trumpet or others.

Running Netscape across NetWare requires you load TCPIP.EXE as part of the client boot process, then having VTCPIP.386, WLIBSOCK.DLL and WINSOCK.DLL in the Windows System directory, with no duplicates of these files anywhere else. The latest version of TCPIP.EXE will auto-load VTCPIP.386, otherwise place a device=vtcpip.386 in the [386 Enh] section of system.ini...then follow the netscape documentation.

[Thx M.M.]

H.38.2 Running Netscape wherever (without dial-up facilities)

To learn how to run Netscape without dial-up facilities, click here to read MOZOCK.TXT and then click here to download MOZOCK.DLL.

[Thx F.P.M.]

[ H(1) | H(2) | H(3) | H(4) | Novell FAQ Home Page ]