[ 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.]
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.]
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:
[Thx H.K.]
Also on CAT5 structured cabling:
[Thx L.D.]
H.36 AC Power and its effect on file servers
For good info, go to:
and
[Thx S.R.#2]
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 ]