------------------------------------------------------------------ NOV-NIC2.DOC -- 19980327 -- Email thread on Network Interface Cards ------------------------------------------------------------------ Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Thu, 26 Jun 1997 20:32:08 -0600 From: Joe Doupnik Subject: Intel EtherExpress PRO/100B configuration The Intel EE PRO/100 family of Ethernet adapters has a driver parameter named TXTHRESHOLD which is very important to change for robust communications. I'll explain what it is, where a difficulty arises, and a simple workaround. It is the number of 8 byte groups to wait for from above before starting transmission. It's an early transmission permission grantor. The values range from 1 to 200, with 200 being 1600B and hence the msg to wait for the real end of packet before transmitting. The default is 8, wait 64B. Alas, early transmission leads to sending packet fragments on the wire. A case here yesterday and today reveals how bad this can be. My remote boot roms were very flakey, even on a quiet wire. Investigation showed fragmented packets from the client saying "send me the next 512 bytes of the boot image" and they were of course not understood. Thus booting was problematic at best. The same basic lan driver is in the boot roms as we run in clients and servers, but with no way to adjust parameters. The solution is to add phrase TXTHRESHOLD=200 to the load line of the driver. Alas, inetcfg.nlm does not want to accept it and either rebuffs our attempts or blithely removes the phrase. And we are not permitted to edit the sys:etc\netinfo.cfg file holding inetcfg's output commands. Thus we have to load the drivers manually in autoexec.ncf and remember to never let inetcfg run. Well, there are ways and there are ways. My bootrom vendor has been informed, and Intel has been very helpful in trying to find a solution. But I created a non-boot-rom solution and it's shown below. The file below is e100b.ldi, the description file for the e100b.lan driver. It has been modified by me to have inetcfg accept the TXTHRESHOLD phrase, pass it on to the driver at load time, and even add a mini-editorial via the F1 help message. I've chopped out the repetitous language sections to save space in this email message, but you should add my help message $E100B_12 to each language section. Joe D. ---------- ;DrIvEr DeScRiPtIoN SyntaxVersion: 1.00 ;- Internal Version 1.12 ;- File: E100B.LDI ;- Intel EtherExpress(TM) PRO/100B Installation Information File ;- This file handles all EE PRO/100 MODEL B adapters : ;- PRO/100 PCI with TX Physical Layer ;- PRO/100 PCI with T4 Physical Layer ;- PRO/10+ PCI ;- Modified by Joe Doupnik, jrd@cc.usu.edu, Utah State Univ, 26 June 1997 ;- to permit necessary selection of TXTHRESHOLD. Added matching help. Driver E100 { Description: $E100B_1 Help: $E100B_2 File: E100B.LAN Prod: PCI.8086.1229.0000.0000.* PAR: 2.00 PROMPT SLOT OPTIONAL { Help: $E100B_3 Type: DECIMAL (5) Values: 1 - 65535 Default: UNDEFINED } PROMPT SPEED OPTIONAL { Help: $E100B_4 Type: DECIMAL (3) Values: 0, 10, 100 Default: 0 Out: 'SPEED=%s' } PROMPT FORCEDUPLEX OPTIONAL { Help: $E100B_5 Type: DECIMAL (1) Values: 0, 1, 2 Default: 0 Out: 'FORCEDUPLEX=%s' } PROMPT IOMAPMODE OPTIONAL { Help: $E100B_6 Type: DECIMAL (1) Values: 0, 1 Default: 0 Out: 'IOMAPMODE=%s' } PROMPT TXTHRESHOLD OPTIONAL { Help: $E100B_12 Type: DECIMAL (1) Values: 8 - 200 Default: 8 Out: 'TXTHRESHOLD=%s' } FRAME FrameSelect { Help: $E100B_7 CDescription: $E100B_8 Choice: 'Ethernet_802.3' CDescription: $E100B_9 Choice: 'Ethernet_802.2' CDescription: $E100B_10 Choice: 'Ethernet_SNAP' CDescription: $E100B_11 Choice: 'Ethernet_II' Default: 1,2 } } Driver E10 { Description: $E10B_1 File: E100B.LAN Prod: PCI.8086.1229.0000.0000.* ParameterVersion: 2.00 PROMPT SLOT OPTIONAL { Help: $E100B_3 Type: DECIMAL (5) Values: 1 - 65535 Default: UNDEFINED } PROMPT FORCEDUPLEX OPTIONAL { Help: $E10B_5 Type: DECIMAL (1) Values: 0, 1, 2 Default: 0 Out: 'FORCEDUPLEX=%s' } PROMPT IOMAPMODE OPTIONAL { Help: $E100B_6 Type: DECIMAL (1) Values: 0, 1 Default: 0 Out: 'IOMAPMODE=%s' } FRAME FrameSelect { Help: $E100B_7 CDescription: $E100B_8 Choice: 'Ethernet_802.3' CDescription: $E100B_9 Choice: 'Ethernet_802.2' CDescription: $E100B_10 Choice: 'Ethernet_SNAP' CDescription: $E100B_11 Choice: 'Ethernet_II' Default: 1,2 } } DLANG: 4 ;English $E100B_1 = "Intel EtherExpress(TM) PRO/100B LAN Adapter" $E10B_1 = "Intel EtherExpress(TM) PRO/10+ PCI LAN adapter" $E100B_2 = "This driver supports the following EtherExpress(TM) PRO/100B family adapters ->\n PCI with TX Physical Layer\n PCI with T4 Physical Layer\n\n" $E10B_2 = "This driver supports the following EtherExpress(TM) PRO/10+ PCI adapter\n\n" $E100B_3 = "Slot number for the adapter.\n" $E100B_4 = "Line speed override for the adapter. Disables auto-\n negotiation. Valid options are 0 (Auto), 10, or 100." $E100B_5 = "Force the operating mode to Full Duplex.\n Valid options are 0 (Auto), 1 (HALF), 2 (FULL)." $E10B_5 = "Force the operating mode to Full Duplex.\n Valid options are 1 (HALF) and 2 (FULL)." $E100B_6 = "Force the driver to use I/O mapped mode.\n The default mode is memory-mapped.\n Valid options are 0 (DEFAULT) or 1." $E100B_7 = "The driver defaults to 802.2 frame format. You may use this default to select from the other 3 options => 802.3, Ethernet II and Ethernet SNAP." $E100B_8 = "E100B 802.3" $E100B_9 = "E100B 802.2" $E100B_10 = "E100B SNAP" $E100B_11 = "E100B E_II" $E100B_12 = "Early Transmission permitted after value times 8 bytes. DEFAULT is 8 (64B); optimum is 200 (1600B) meaning wait for full a packet (no noticable performance penalty). Early transmission can generate packet fragments and poor response. Recommended value is 200." LANG: 6 ;French $E100B_1 = "Intel EtherExpress(TM) PRO/100B LAN Adapter" $E10B_1 = "Intel EtherExpress(TM) PRO/10+ PCI LAN adapter" $E100B_2 = "This driver supports the following EtherExpress(TM) PRO/100B family adapters ->\n PCI with TX Physical Layer\n PCI with T4 Physical Layer\n\n" $E10B_2 = "This driver supports the following EtherExpress(TM) PRO/10+ PCI adapter\n\n" $E100B_3 = "Slot number for the adapter.\n" $E100B_4 = "Line speed override for the adapter. Disables auto-\n negotiation. Valid options are 0 (Auto), 10, or 100." $E100B_5 = "Force the operating mode to Full Duplex.\n Valid options are 0 (Auto), 1 (HALF), 2 (FULL)." $E10B_5 = "Force the operating mode to Full Duplex.\n Valid options are 1 (HALF) and 2 (FULL)." $E100B_6 = "Force the driver to use I/O mapped mode.\n The default mode is memory-mapped.\n Valid options are 0 (DEFAULT) or 1." $E100B_7 = "The driver defaults to 802.2 frame format. You may use this default to select from the other 3 options => 802.3, Ethernet II and Ethernet SNAP." $E100B_8 = "E100B 802.3" $E100B_9 = "E100B 802.2" $E100B_10 = "E100B SNAP" $E100B_11 = "E100B E_II" $E100B_12 = "Early Transmission permitted after value times 8 bytes. DEFAULT is 8 (64B); optimum is 200 (1600B) meaning wait for full a packet (no noticable performance penalty). Early transmission can generate packet fragments and poor response. Recommended value is 200." ------------------------------ Date: Thu, 31 Jul 1997 14:25:13 -0400 From: "George Raetzke, Northern Ill. Univ." Subject: Re: Using ATM in Netware file servers >Has anyone tried using ATM cards in 4.1 or 4.11 file servers. If so what >brand of card are you using, and what problems (if any) have you had? I am currently using the Madge Collage ATM adapter in a few of my servers. So far they seem to be working quite well. A sales rep from Olicom talked my boss into testing one of their adapters. I started to install in, but the install program was so bad, I yanked it right out and dropped a Madge in. The only thing that has bit me so far, is that the VLAN is case sensitive. ------------------------------ Date: Sat, 2 Aug 1997 22:17:03 -0600 From: Joe Doupnik Subject: Re: Intel Etherexpress Pro/100 (non revision B) >Does anyone have an experience with the Intel Etherexpress Pro/100 >cards which are not the current rev. B version? > >Are there problems or reasons I shouldn't use these in v4.11 servers? ------ Non-rev B boards come in ISA, EISA, and PCI variants. The PCI one causes endless trouble here at boot time by clobbering the PCI part of system memory (>>>>> 1MB) but can be made to work part of the time. The EISA variant is current production and works pretty well. I have not touched the ISA equivalent. The board of choice from Intel is the rev-B PCI board, based on performance and better domesticated PCI behavior. At quantity prices of US$60 it is a bargin. Joe D. ------------------------------ Date: Tue, 12 Aug 1997 08:30:46 -0400 From: Shimshon Farkash Subject: Re: win95 and Client32 Please read carefuly the doc "Client32 and 3Com adapters" at http://ourworld.compuserve.com/homepages/mcox/netware.htm This is a good advise to every one who used 3Com adapters and Client32. I had problems and this doc help me to solve them. ------------------------------ Date: Tue, 26 Aug 1997 12:46:00 +0000 From: Jon Hall Subject: Re: Query about client load order >Just a short and inconsequential question about the client load order. >In the VLM client model, the nic driver lies below the link support layer, >above which lie the protocol components and then the requester. Following >the physical model then, you would think that the NIC drivers should be >loaded first, and then the LSL, followed by the protocols and finally the >VLM components. Why then is the lsl loaded before the NIC drivers? LSL (despite the name) isn't really a layer as such; it's more like the glue bonding the layers together (a bad analogy, I know). NICs register themselves and their capabilities with LSL; protocol stacks interrogate LSL to find out what NICs are available. This is why LSL has to load first. --------- Date: Tue, 26 Aug 1997 10:11:16 -0600 From: Joe Doupnik Subject: Re: Query about client load order ------- That seems logical, until one asks how the various components rendevous. Scanning memory for signatures, scanning interrupts for signatures and so on have limitations. The LSL is the manager of ODI and establishes itself on a "well known" interrupt chain, Int 2F, where other modules can locate it. Once located each module registers itself with the LSL, as a lan driver, as a protocol stack, etc, and then modules can ask the LSL about other modules. The actual operations are load the LSL, then the lan drivers, and then the protocol stacks. The reason for this is the stacks try to attach (bind) to a lan driver and need them available for inspection. Hence, LSL, then lan drivers, and finally the stacks. ODI is amazingly flexible and clever. One may load and unload components dynamically, save the LSL, provided there are no bindings needing support. And one may even use a protocol stack as a fake lan adapter, as is done with IP Tunneling and NW/IP to make the TCP/IP stack look like a lan driver to ODI and yet still use a real lan adapter to get to the wire. I drew a picture of this in the list's FAQ. There can be layers of "lan adapters" or "protocol stacks" such that packets are passed along a chain, and this is often used for encrypted traffic as well as for packet snooping. Joe D. ------------------------------ Date: Wed, 8 Oct 1997 09:15:57 -0600 From: Joe Doupnik Subject: Re: Which NIC ? >>>For a server, is there a preference between a 3c905-TX 10/100 PCI >>>Network card and an Intel EtherExpress PRO/100 LAN Adapter? TIA. > >>Both will work. I've looked at both. I went away and spent money >>on the Intel board and have been pleased. The Intel board has better >>performance and is more adjustable than the 3Com unit. Also, on a >>small sampling, 3Com boards have a high dead-after-few-hours-use >>rate, but this may not be typical. A 3C905 board is basically a 3C509 >>board for a PCI bus. >> Joe D. > >I believe the Intel EtherExpress PRO/100 LAN Adapter comes in two >flavours with one specifically designed for servers - and considerably >more expensive. Is this the one you are referring to here ? I have both versions of the Intel board: Intel EtherExpress PRO/100B and EtherExpress PRO /Server. The above refers to the 100B client flavor, less expensive, board. The Server kind is a completely different board and I have had terrible trouble making it work with the PPro motherboard in one server, and Intel can't help. The Intel EE PRO/100B and 3C905 are both client class adapters. They don't have much buffering and they still want assistance from the driver to manage that buffer. The Intel EE PRO/Server has an on-board i960 cpu and more memory to lighten the burden on the server's cpu. Note: the PCI bus EE PRO's are not the same as the EISA bus versions. What is surprizing in practice is the 100B performs very well in a server. I see 20% or less server cpu utilization when driving a 100Mbps wire to full capacity. Despite this I would prefer using the smarter server board, but that will require a new motherboard with better PCI bus handling. Joe D. ------------------------------ Date: Thu, 9 Oct 1997 16:10:19 +0200 From: Hans Nellissen Subject: Re: NIC MAC address code > I know the manufacturer codes it's identity in the NIC by >using assigend serial number blocks but I can't find any information >on what code blocks belong to what manufacturers. Can anyone point me >to this information. I thinkthe IEEE administers this but they don't >say on their public WWW site. InterNIC doesn't either. http://www.cavebear.com/CaveBear/Ethernet/vendor.html ------------------------------ Date: Mon, 3 Nov 1997 17:50:23 -0600 From: Joe Doupnik Subject: Re: NE2000 10/100 NICs? >Is there a 10/100 NIC, either ISA or PCI, out there that will still use >a NE2000 MLID? > >We're running networked Win for Workgroups and can't see moving away >from the NE2000 driver, as I've standardized on NE200 for all our >machines (450+)... --------- You really do not want an NE2000 clone at 100Mbps Ethernet. Believe me. Technically it is a very poor decision. I would suggest you would be well advised to bite the conversion bullet firmly and do a good upgrade job. You have heard comments on this list about various fast Ethernet boards, and the best advice we can offer is to run extensive tests on many of them to find the kind which fits your needs. I work with these things, and now and then even write drivers for them, so the first paragraph does mean what I said. Joe D. ------------------------------ Date: Mon, 1 Dec 1997 08:31:13 -0600 From: Terry Kalister Subject: Re: Token Ring Beaconing >Have you ever seen a server causing an abend every time the token ring >beacons? There is something critically wrong with your token ring network if it is beconing much. Token ring will deal with most minor ring problems but a beacon is its last ditch effort to let you know you have major problems. A beacon removes the station causing the beacon from the ring. Beacons can be caused from a bad card, ring length too long, bad wiring between stations, bad patch cable, etc. Put a sniffer on your ring and find out who the culprit is. If the server is abending, it could be the token ring card in your server that is beaconing. --------- Date: Mon, 1 Dec 1997 21:56:45 +0700 From: Garind P Subject: Re: Token Ring Beaconing If you have client32 with Win95B/OSR2, set the token ring card adapter as IBM Token ring. And set the card as AT-bus card, not PnP, without IRQ interupt using the manufacturer setup program (usually DOS program) ------------------------------ Date: Wed, 10 Dec 1997 16:55:13 -0600 From: Joe Doupnik Subject: Re: Collisions? >>I'm running 3.12 on a HP Netserver LC with a 3c5x9 nic. The >>send ok single collision count: 7,081,523 The send ok multiple >>collision count: 2,329,193 ...is this indicitive of a failing >>NIC or traffic coming from somewhere else? > >Does your network seem to be functioning correctly? When a collision >happens it causes the NIC's involved to "stop and wait" then try >retransmitting. If something is misfiring and causing collision after >collision then the network will stop working. > >I have seen this happen when a thicknet transciever went screwey. It was >doing something which either causes a collision or triggered a collision >and my collison count on the server was climbing exponentially. ------- What likely happened was getting the transceiver set wrong and emitting "heart beat" bursts onto the network. These are 0.9 microsec (regular Ethernet, divide by 10 for Fast Ethernet) tests of the emergency collision system, if this were a real collision we would be doing useful work, at the trailing edge of each packet. It is yet another bright idea from the IEEE802.3 committee, to ensure the transceiver's collision detection logic is functioning (on every pkt). They appear to be collisions to listeners on the net, the net grinds to a halt. Heart beat goes only to an Ethernet adapter, never the net, and only to those prepared to deal with it. Joe D. ------------------------------ Date: Thu, 11 Dec 1997 19:04:56 -0600 From: Joe Doupnik Subject: Re: Collisions? >> What likely happened was getting the transceiver set wrong and >>emitting "heart beat" bursts onto the network. These are 0.9 microsec >>(regular Ethernet, divide by 10 for Fast Ethernet) tests of the >>emergency collision system, if this were a real collision we would >>be doing useful work, at the trailing edge of each packet. It is yet >>another bright idea from the IEEE802.3 committee, to ensure the >>transceiver's collision detection logic is functioning (on every pkt). >>They appear to be collisions to listeners on the net, the net grinds >>to a halt. Heart beat goes only to an Ethernet adapter, never the net, >>and only to those prepared to deal with it. >> Joe D. > >Joe, I'm confused. Are you saying that a misconfigured transceiver >could actually send heartbeat bursts onto the network, as opposed to >just sending them to the adapter?=20 > >I didn't know that was possible. I didn't know there was a definition >of a what a heartbeat would even be, on the network. ----------- Answering two questions in one message. Ken's query. Yes, it is indeed possible to get backward, especially if plugged into a hub's AUI port. Locally this is known as the "DELNI Effect" after DEC's venerable AUI-ported hub of many years ago (original Ethernet in a box). This is in the IEEE 802.3 specs if you have purchased a copy. The heartbeat burst is a tiny collision pulse, intended for compliant receivers to say "Yup, the detector worked again" but which across the net looks like a "late collision" jam signal and hence packets most often are dropped like a hot potato. The heartbeat stuff goes out the AUI port. It is rarely used in this day and age of reliable equipment. Mike's continuing dilemna. The server's ODI driver is able to count things most drivers don't. They will reveal how many frames were sent with no competition, after one bump, after several bumps, and those that failed to go out from excessive retries or failed equipment. Several bumps per try is quite normal on a busy wire and is not a concern. For those who still think collisions are some horrible event, this is several hundred percent collision rate. Total losses are of concern. The counts will go up if there is traffic, so the more traffic the more bumps total, as common sense would indicate. Naturally, the Ethernet controller chip has to be of the kind which reveals such statistics because all this bumping stuff is handled by that big square piece of silicon. It is a natural and essential part of Ethernet's sharing the medium. There are many reasons frames do not get through. Flakey wiring is one. Inadequate LAN adapters and drivers is another, a common one. Misconfig'd equipment is another. A broken LAN adapter on the net can emit garbage and drag things to a crawl. A wild LAN adpater can do the same by saturating the wire, and the vendor LAN adapter self-test program is normally an excellent way of making trouble. Use a LAN monitor (say Lanalyzer) to check. Weak LAN adapters will begin to fail under Packet Burst stress, and under intensive SPX back and forth chatter during backups. Weak adapters can be on client and/or server. There's more. Some adapters can emit partial frames when their transfer of packet bytes from driver to LAN adapter across the system bus is delayed by competition for the bus. This is termed "DMA underrun" and is controllable on some adapters. For Intel EtherExpress boards set TXTHRESHOLD=200 to tell the board not to start transmitting until all packet bytes have made the bus trip. Each board is different so please check your details. If PCI bus set the PCI latency to 40 or less clock ticks on all peripherals, thus reducing bus hogging. Some LAN adapters have an "interrupt early" feature upon packet reception which causes the machine to sit for a millisec or more waiting for the rest of the frame to arrive. If this feature can be turned off do so, else change to another brand of board. As I have been told, the feature is used to support the horrid interrupt latency on NT systems where all the time is needed to get the receive act together. NW servers and clients do not need this wasted time. A weak wiring plant or a hub beginning to die of old age, and similar, are hard to spot unless swapping tests are done. Twisted pair stations detect collisions by hearing data while sending, and that can arise from too much Near End CrossTalk (NEXT in the jargon), which in turn says fix the wiring with better qualtiy and better handled stuff. Check that all four wires are connected properly because mis-pairing generates lots of NEXT. I put all of this into the category of Necessary things to know about real networks but rarely written in texts or managers guides to this and that, or CNE exams. It's not secret; it is knowing the technology. Joe D. ------------------------------ Date: Thu, 18 Dec 1997 08:39:17 -0600 From: Steven Mitzel Subject: Re: Token Ring Network Card >At work we have a many, many network cards. All our IBM token-ring >network cards (number unknown). Most of them have the small white >switches on them. Does anyone how to configure these card, and what >drivers I should load, in DOS and in Windows 95 ? > >I also have some TokenLink III 16.4 (3c619c) to configure also (like >the about. I have some IBM 16/4 Token Ring cards with the white switches on them. They are ISA cards. If you happen to have the manual "Token-Ring Network 16/4 Adapter Hardware Library - Guide to Operations" (dark brownish-red book), this shows all of the settings for each of the switches. If you do not have this, I could get you the information for the dip switches. 1-6 ROM Address 7-8 IRQ for the card 9 Primary or Alternate LAN adapter 10-11 Shared RAM size 12 Adapter Rate Switch (ON = 16Mbps; OFF = 4Mbps) I'm on a NetWare 4.10 network. These are the settings in my C:\NWLCIENT\STARTNET.BAT file (which is called from the Autoexec.bat file) for my Windows 3.1 clients: SET NWLANGUAGE=English C:\NWCLIENT\LSL.COM C:\NWCLIENT\LANSUP.COM C:\NWCLIENT\IPXODI.COM C:\NWCLIENT\VLM.EXE For the Windows 95 clients, I use the "IBM Token Ring 4/16Mbs" adapter right off of the Windows 95 CD. Nothing in the Autoexec.bat or Config.sys. --------- Date: Thu, 18 Dec 1997 11:16:08 -0600 From: Brian Scott Subject: Re: Token Ring Network Card Well, you are in luck. All (well almost all) IBM 16/4 Token-Ring cards that have dip switches, have the same settings. These settings are for the switch block with 12 switches. On the cards with both STP and UTP ports there are an additional two switches, but they should be labeled on the card. Off is with the switch is in the up position ( away from the card ). Switch 1 to 6 set the ROM address The two recommended settings are: CC000 off on on off off on (primary) DC000 off on off off off on (Alternate) These switches are actually the middle 6 bits of a byte. The high bit is always 1 and the low bit is always 0. Off = 1, On = 0. Switch 7 and 8 are the IRQ. IRQ 2 = on on, IRQ 3 = on off, IRQ 6 = off on, IRQ 7 = off off Switch 9 is for selecting primary/alternate adapter. primary = off ( port A20 ) alternate = on ( port A24 ) Switch 10 and 11 are for the RAM size. 16Kb = off on (recommended) 8Kb = on on, 32Kb = on off, 64Kb = off off Switch 12 is the speed 16Mbps = off, 4Mbps = on Drivers: DOS: either token or cntr2000. We use witch ever is newer at the time. We use both the 16 and 32 bit versions of these as needed. Win95: I think we use "IBM Token Ring 4/16", but the "IBM Token Ring (All types)" also works. Most of the 95 systems we have are now pci, so we don't have that many ISA adapters in this setup. Also if you need I have recommened settings for using IBM ISA Token-Ring cards with Sound Blaster cards ( non pnp ). On 17 Dec 97 at 16:13, Dave Skinner wrote: >Hi there. > >At work we have a many, many network cards. All our IBM token-ring >network cards (number unknown). Most of them have the small white >switches on them. Does anyone how to configure these card, and what >drivers I should load, in DOS and in Windows 95 ???? > >I also have some TokenLink III 16.4 (3c619c) to configure also (like >the about. ------------------------------ Date: Fri, 19 Dec 1997 21:46:00 -0600 From: Joe Doupnik Subject: Re: 3COM 3C509 in server - a no-no? >This is interesting. Does anyone (probably Joe D.) know the buffer size >on the 3C590 and 3C905 - which would at least partially explain why the >590 outperforms the 905 (at least in my experience). ----------- No, I have no idea. From years of hard knocks I've decided to avoid 3Com Ethernet boards as not well designed for my uses. There is much more to Ethernet board-life than buffer capacity, but it is important. It is extremely tightly coupled with the ability of its driver to keep that silicon buffer emptied. That in turn means fast transfers across the system bus. PCI is better at this than EISA which is much better than ISA. There are bus masters and bus masters, and non-bus masters (shared memory, port i/o), and performance varies a lot in this area. I suggest visiting 3Com's technical areas and get the specs, for what they will tell you. Careful stressful testing is the real way of discovering performance. Joe D. ------------------------------ Date: Sat, 20 Dec 1997 13:25:23 -0600 From: Joe Doupnik Subject: Intel EtherExpress PRO/Server Ethernet boards This is a short note on local experience with the fancy and expensive Intel EtherExpress PRO/Server PCI Ethernet boards. These units have an on-board i960 processor and 1+MB of packet storage memory. They run rather warm. Until this weekend I was unable to employ the boards because the INW 4.11 server hosting them would halt solidly when their driver, e100snw, was loaded. The motherboard was an ASUS XP6NP5 (PPro 200 PCI/ISA, 440FX PCI chipset). I changed the motherboard to an Intel VS440FX unit, uses same chips, and the Ethernet boards are working very well indeed thus far. Hence, the ASUS board was unable to accomodate the sophisticated PCI bridging work needed with these Ethernet boards. Motherboards are cheap. A beware. The Intel motherboard has a Bios which uses part of segment E000, in addition to the regular segment F000 material. Initially I was unable to flash update the Bios. Then the light dawned and I swapped out the current video adapter for one which does not ghost its Bios into E000. That solved the problem; flash updating succeeded. At the moment stress testing is occuring. There are three EE PRO/Server boards in the server, two driving 100Mbps lans (hubs and clients) and one driving a 10Mbps lan (for the moment). Using Perform3 to create as much lan traffic as possible without affecting the SCSI disk farm I find server cpu utilization to be about 17%. That's driving two 100Mbps lines at full (95%) capacity and one mere 10Mbps line at the same capacity. The server is loafing. Joe D. --------- Date: Sun, 21 Dec 1997 10:44:35 +0200 From: Mike Glassman - Admin Subject: Re: Intel EtherExpress PRO/Server Ethernet boards Regarding the issue of the Intell 100 PCI ethernet cards. We used them on a few servers, all of which are NOT Intel boards due to the fact that there was some clash between the board and the cards. This may have been fixed since then, but Intel support here in Israel agreed that there was a problem. The only thing I did not like about the cards, is that they would "pulse". At very odd times the cards would slow down and then shoot back up to speed without any visible reason. We did a thoruough check on all the wires, hubs, memory, boards, the lot and could not solve the issue. Using the 3Com 100 cards solved the problem completely. I have seen a few too many problems with Intel cards not working well on Intel machines but working fine on others, and have come to the conclusion that Intel is great at boards and pc's, but their card technology leaves a bit to be desired. It's either that or the fact that they have departments that don't talk to each other. Another such example is the Intel EISA 10/100 Ethernet cards. These cards work well on Intel servers so long as you never put more than one in a server. The moment you put more than one, the cards intermittently freeze and after a short while AbEnd the server. Then of course if you try to flash the cards to update the BIOS, if there is more than one card, it fakes the flash and doesn't actually do it. This may of course have been solved since I did this (about half a year ago), but it has left me with a bit of a bad taste when it comes to Intel fast NIC's. ------------------------------ Date: Sun, 21 Dec 1997 09:15:04 -0600 From: Joe Doupnik Subject: Re: 3COM 3C509 in server - a no-no? >>for what they will tell you. Careful stressful testing is the real way >>of discovering performance. > >I ran perform3 on this particular network, using 8 PC's on 2 segments, and >Perform3 could not get started. Lots of disk requests, but no >reading/writing. What does that tell me? Could not get started, etc? I don't understand the comments. Try perform3 dummy 12 1 4096 512 on the first client and perform3 on all the others. Ensure they all are using the same directory (so they use the same sync file), and the directory is on the file server. I stress tested my system yesterday this way, with 42 clients doing mostly the same cooperative Perform3 and the remainder looping in iozone.exe. I used perform3 dummy 300 1 65535 1024 to yield a 5 hour run. >I have battled with performance probs on this network, but is much better >now after some tuning. Stability also much better. > >To my original question: would NE2000's do better as a quick fix? Depends on what's wrong. NE-2000's are stable slow reliable beasts. There are some clones of it which are peculiar but most are normal. The suggestion is find and fix what's wrong rather than tinkering with things around the edges. Joe D. ------------------------------ Date: Sun, 21 Dec 1997 20:07:13 -0600 From: Joe Doupnik Subject: Re: 3COM NICS and lanalyzer, etc >Original question was about 3COM nics forwarding info up the ODI stack >don't remember the details, but I suspect the question deals with >"promiscuous mode" and LAN ANALYSIS. > >Both 3COM and NOVELL have told me the 3COM cards do not work in an analyzer >for detailed error info. > >The reason 3COM gave me is many of the errors are handled on the NIC by the >ASICs and not forwarded. > >This may be OK for a workstation NIC, but not what you want when attempting >to forward errors to your analyzer software, so you will need a different >NIC on the monitoring station. > >NE2000 or SMC NICs ( in think INTEL recently bought SMC ) should work. >I don't know about the INTEL NICs --------- The story is only half complete. LZFW and other diagnostic programs report on send/receive errors and a host of other things which occur processing packets. These are just counters maintained by the ODI lan driver and read-out by the interested diagnostic programs. Such counters are cheap to implement but the Ethernet adapter hardware needs to reveal them and the driver writer has to look at the hardware to get the indications. Many ODI lan drivers do a thorough job of reporting conditions noted in the silicon, and many include custom statistics as well. From your comment it appears that 3Com's Ethernet controllers decline to report many situations. Then there is the business of Ethernet multicasting. Ethernet boards are supposed to support an array of multicast physical addresses (MAC addrs) but some do and some don't. Applications software needs to load those addresses into the driver. I recall a vague comment that 3Com chose to support one multicast address only, but that is probably an inaccurate statement. I have had no difficulty using LZFW over NE-2000 clones nor over the Intel EE PRO/100B boards. I see the sundry errors and can look at collision fragments byte by byte, etc. In fact I was doing just this a few minutes ago while stress testing the EE PRO/server boards against the client style 100B units. There are boards whose driver tries to shield users from tinkering, yet still have hooks to engage/defeat special features. The amount varies by vendor. The Intel boards have a lot, nearly all undocumented, and 3Com boards have almost none. That spans the range. These knobs are normally without documentation and one needs to be a shrewd guesser to know what they do. I just tamed, I hope, the PRO/server board to not get caught sending partial frames if the PCI bus is very busy, but I won't know for sure until tomorrow (tests are running overnight). I had done the same last spring for the client 100B units. ----- Another piece of technical trivia on the Intel EE PRO/server boards gleaned this evening. When transmitting packet after packet server cpu utilization registered about 0% (zero). I'm filling a 100Mbps wire with PBurst groups 22KB and smaller from the server (running Perform3) where the data origin is still the server's cache memory. There is no interrupt activity reported by Monitor (INW 4.11)! The on-board i960 cpu of the adapter is apparently soaking up all the driver workload and doing calls rather than interrupts to the operating system to move data memory to memory. The server is doing the NCP work but with a PPro 200 that is quickly accomplished at no visible cpu load. Thus if I didn't look elsewhere the server could be driving many 100Mbps Ethernet wires full tilt from cache memory and I wouldn't know from the Monitor snake or cpu utilization. Thus if a server really has to push bytes across the wires (say 100Mbps wires) while doing lots of other things then boards of this class are worth looking into. Joe D. ------------------------------ Date: Tue, 23 Dec 1997 00:15:43 UTC From: Robert Moss Subject: Re: 3COM 3c905 and 3c509 We installed a few of the 3c905 PCI boards when we upgraded the PCs in our department. Now, installing an ethernet adapter isn't really rocket science so I didn't expect to spend more than a few minutes per machine. All the PCs were running Win95. One spotted the new card, installed drivers and ran happily ever after. One would spot the card, install the drivers but not see the network. This was an all day project and I can't recall what finally made it work. The last machine seized tighter than an Indian as soon as it saw the new card ( tried several to eliminate bad card ). Finally gave up and went back to the original 3C509 and couldn't get it to work either. After several hours I just whopped out FDISK. Runs fine now. I should've taken the hint, but I proceeded to put the 3C905 in a new 4.1 server. This system would run for a day or two and then, without any warning or error messages, start kicking off users. After 5 or 6 minutes the server would hang and require a reboot. There was never an indication of what the problem might be. As soon as I replaced the 3C905 with a trusty old 3C509 the problem went away. 3COM tech support says they never ever ever heard of a problem with the 3C905 card and a Novell server. Right. ------------------------------ Date: Tue, 30 Dec 1997 23:17:03 -0700 From: Joe Doupnik Subject: Re: Intel EtherExpress PRO/Server Ethernet boards >The pulsing problem wasn't caused by the Intel boards, but by the Intel >100 NIC's. As far as my experience goes, the only problem I have with >Intel on this issue, is that their own NIC's sometimes work better on >other machines than on their own. > >This is a typical situation of what happens when one hand doesn't know >what the other is doing. > >Mike Glassman > >> Could you tell me which HUB you were using when you had this pulsing >> problem? We are just about to purchase 3 new servers from DELL, and >> they come w/ these blasted Intel boards. Up until now, we have used all >> 3COM boards w/ Synoptic hubs (Great combo)... and I'm worried that we are >> going to find things like this which will cause me a headache on my network. >> >> > The only thing I did not like about the cards, is that they would >> > "pulse". At very odd times the cards would slow down and then shoot >> back up to speed without any visible reason. We did a thoruough check on >> all the wires, hubs, memory, boards, the lot and could not solve the >> issue. Using the 3Com 100 cards solved the problem completely. ---------- The "pulsing" (or should we say surge) problem is most likely tied to two things. One is the board's trying to space frames based on perceived network load and spacing of empty time on the wire. The second is the willingness to send frames which are only partly transferred across the PCI bus (TX dma underrun). Both "should" go away with very simple changes. As always with PCI buses, throttle the PCI latency to about 32 bus clock ticks, to give other peripherals a chance at the bus. Below is the top of my own e100snw.ldi lan driver info file. If you use this with Load inetcfg, Boards, select Options, then there will be two new options to tweak: TXTHRESHOLD (please set this to 200) and NOADATAPTIVETHRESHOLD (please set this to 1). EE PRO/100B client boards get the same treatment except omit the NOADAPTIVETHRESHOLD components. Client 100B boards in clients accept TXTHRESHOLD=200 on their load e100bodi command lines. All this is likely a continuation of the Intel engineers seeking ways of implementing Ethernet anti-capture mechanisms, inspired by Mart Molle's BLAM proposal, but in their own terms. That's just my guess. At the risk of some complaints here is the top couple dozen lines of that file so I won't have to repeat this on the list again. Note, the Help text should be repeated for each of the languages in e100snw.ldi (a text file). Omissions made to save mail bandwidth. One also needs to be wary of Packet Burst itself because I have noted it to go unstable in just the "surge" fashion noted when it is pushed a little too hard and a few frames are dropped. My changes basically remove the possibilty of frames being dropped from damage upon transmission. Joe D. -------------- Excerpts of Intel file e100snw.ldi, modified by me. ;DrIvEr DeScRiPtIoN SyntaxVersion: 1.00 ;- Internal Version 0.62 ;- Changes: ;- 02/05/97 V0.62 : Changed Duplex to ForceDuplex ;- : Changed ISLVLAN to VLANMODE ;- 01/22/97 V0.60 : Fixed Message $E100SNW_5. Changed DUPLEX to FULL ;- 11/30/96 V0.47 : Original Version. First Transmittal to SWEAT ;- Modified by Joe Doupnik, jrd@cc.usu.edu, Utah State Univ, 20 Dec 1997 ;- to permit necessary selection of TXTHRESHOLD and NOADAPTIVETHRESHOLD. ;- Added matching help. ;- File: E100SNW.LDI ;- Intel EtherExpress(TM) PRO/100 Server Installation Information File Driver E100SNW { Description: $E100SNW_1 Help: $E100SNW_2 File: E100SNW.LAN Prod: PCI.8086.5200.0000.0000.* PROMPT TXTHRESHOLD OPTIONAL { Help: $E100SNW_13 Type: DECIMAL (1) Values: 8 - 200 Default: 8 Out: 'TXTHRESHOLD=%s' } PROMPT NOADAPTIVETHRESHOLD OPTIONAL { Help: $E100SNW_14 Type: DECIMAL (1) Values: 0 - 1 Default: 0 Out: 'NOADAPTIVETHRESHOLD=%s' } DLANG: 4 ;English $E100SNW_1 = "Intel EtherExpress(TM) PRO/100 Server Adapter" $E100SNW_2 = "This driver supports the EtherExpress(TM) PRO/100 Server Adapter" $E100SNW_3 = "Slot number for the adapter.\n" $E100SNW_4 = "Line speed override for the adapter. \n Disables auto-negotiation. \n Valid options are 0 (Auto), 10, or 100." $E100SNW_5 = "Duplex mode override for the adapter.\n User must specify speed when specifying Duplex. \n Valid options are 0 (Auto), 1 (HALF), 2 (FULL)." $E100SNW_6 = "Connector to use for network connection.\n Valid options are 0 (Auto), 1 (TPE), 2 (MII)." $E100SNW_7 = "Selects Vlan Mode for the driver.\n Valid options are 0 (Standard Mode: No VLAN), 1 (ISL VLAN).\n The default mode is non VLAN mode." $E100SNW_8 = "The driver defaults to 802.2 frame format. You may use this default to select from the other 3 options => 802.3, Ethernet II and Ethernet SNAP." $E100SNW_9 = "E100SNW 802.3" $E100SNW_10= "E100SNW 802.2" $E100SNW_11 = "E100SNW SNAP" $E100SNW_12 = "E100SNW E_II" $E100SNW_13 = "Early Transmission permitted after value times 8 bytes. DEFAULT is 8 (64B); optimum is 200 (1600B) meaning wait for full a packet (no noticable performance penalty). Early transmission can generate packet fragments and poor response. Recommended value is 200." $E100SNW_14 = "No Adaptive Threshold, default 0 for off. 1 for on. If on (1) use with TXTHRESHOLD=200 to delay transmission until an entire packet has been transferred across the system bus and hence eliminate Tx DMA underruns." ------------------------------ Date: Fri, 2 Jan 1998 08:42:16 -0700 From: Joe Doupnik Subject: Re: Switching to 100Mb >At the moment I'm running a 10Mb network on 3 X 4.11 servers. I will >be soon starting a phase over plan too 100Mb. I run a public school >network and this phase over will take probably 3 years with our >limited funding. > >I have a few questions about this upgrade - > >I plan on installing Intel EtherExpress 100 server adapters in my 3 >servers. Each server will also have a standard ne2000 card in it, >most likely PCI. At the moment all 3 servers have 2 cards in them, am NE-2000's are ISA bus only, not PCI. >I likely to run into any problems doing this and what are your views >on the Intel server cards ? Please go back over the list's traffic for the past few weeks and review my comments on the Intel EE PRO/100 Server board. Recall, the list is archived, and you can click to it by visiting netlab1.usu.edu and following the signs. I use these boards and they are extremely picky about the motherboard. Given the right motherboard they work terrifically. But the regular client style EE PRO/100B or now 100+ boards work well too (use more cpu cycles, but we generally have them to burn). To justify the Server boards (at about US$550 each, versus under US$70 for the 100B/100+ units) you must have very heavy traffic and a very busy server. >All 3 servers are simply used for storage, one will be becoming the >backup server using Arcserve 6. The other 2 servers will have the >agent installed on them aswell. All 3 servers mainly provide >multimedia data to users, with huge amounts of digital video. TCP/IP >is also running across the network providing internet access, and 2 of >my servers route the internet packets. Keeping this all in mind what >is the best packet size for the network ? At the moment I have 4202 >byte size packets. No, please. Ethernet frames are 1500 bytes of data. This is a networking basic. Tell the server the max frame size is 1518, to allow for headers and a tiny amount of bookkeeping. >At the center of my new network I plan on installing a 3Com Switch >3000 10/100. Has anybody had any troubles with this switch and what >do people think of it. I'v picked it at this stage, because I have >heard so many good things about it and that 3Com have already made a >backbone module for it ready for 1000Mb networks. Chasing technology on a limited budget is a risky proposition. Engineers ask "Do I really need this feature?" before investing in it. Need != want, and all that jazz. Joe D. ------------------------------ Date: Fri, 2 Jan 1998 17:54:45 -0700 From: Joe Doupnik Subject: Re: Switching to 100Mb >>Each server will also have a standard ne2000 card in it, most likely PCI. > >A local vendor offers "32bit PCI NE2000 cards". All the NE2000's I've ever >seen were 16bit ISA cards, as were the clones. Can a NE2000 clone really >be 32bit/PCI? ---------- NE-2000's have a very well defined systems interface. They are ISA, and they use regular port i/o plus a regular interrupt. There is no, and I do mean none, advantage of putting these on a PCI bus because, amongst other reasons, the port i/o for packet data occurs one byte at a time, not even two which the ISA bus can support for a 16-bit board. NE-2000 drivers must see the board as such a conventional ISA device. When faced with off color "NE-2000" clones I recommend looking in another direction. Solid standard boards are widely available at good prices these days, so please avoid the wierd stuff. Come enroll in my ODI lan drivers class this term (starts Monday). USU registered EE juniors only, must speak MS assembly language and C. We run on what we write, a class motto. Joe D. --------- Date: Fri, 2 Jan 1998 21:12:27 -0700 From: Joe Doupnik Subject: Re: Switching to 100Mb >>> No, please. Ethernet frames are 1500 bytes of data. This is a >>>networking basic. Tell the server the max frame size is 1518, to allow >>>for headers and a tiny amount of bookkeeping. > >>I thought that if MAXIMUM PHYSICAL PACKET RECEIVE SIZE was set to 4202 >>(which I commonly see), it was simply an upper limit -- smaller packets >>were created and moved around just fine. Or am I thinking of the wrong >>setting? > >Well, actually, it reserves memory in accordance with the above seting. >This can be seen by using Monitor|Resource Utilization|Permanent >memory|LSL Receive buffers. (I think that's correct) ----------- Precisely. And for that reason one reduces the errant value to proper size and thereby conserves server memory. We have gone over this many times, and it is probably in the list's FAQ (no time to look tonight, deep in a MS Office 97 installation to server mess). Joe D. ------------------------------ Date: Mon, 9 Feb 1998 15:37:48 -0000 From: Nick Kelly Subject: Re: 32 and 33 spec ODI. How do you know? Novell have a utility, DRVSPC.EXE, that will report the ODI spec of a LAN driver. This site has a copy: ftp://ftp.crimson.de/NOVELL/NWUTIL/ ------------------------------ Date: Mon, 23 Feb 1998 21:42:04 -0800 From: Randy Richardson Subject: Re: Binding Help?? >>When you are binding multiple protocol's to a single card >>(802.2,802.3...) how do you automate the binding so that the >>autoexec.ncf will run without intervention. I used INETCFG to set up >>the cards. When I bring the server up, the autoexec.ncf stops to ask >>questions like "Do you want to add another protocol to this card?"... > >This can come from several missing commands on the second NIC >Load command. For example, if the card loads in SLOT 2, and there isn't >a SLOT=2 on the second load command it will ask if this card is loading >a different frame type. Other missing commands will cause the same >problem. So, you need to look at the load command and experiment to >find out what it is missing. Once it is complete, it will automatically load. Make sure all your NIC driver LOAD statements have been moved to INetCfg.NLM. I've noticed that older versions of INetCfg.NLM will rarely create this problem, and the updated version seems to fix it. A trick to upgrading INetCfg.NLM to v3.30 is to install the IPX/IP Gateway (you don't actually have to enable the gateway). I'm running (the last time I checked) INetCfg.NLM v3.30e. ------------------------------ Date: Sun, 1 Mar 1998 23:36:28 -0800 From: Randy Richardson Subject: Re: Intel PCI NIC card >I am having some problems adding an Intel PCI Ethernet NIC to a >Novell 4.1 server. I keep getting the folowing error. Any thoughts? > [snip] >SERVER-4.10-1586: Loader cannot find public symbol: MSMScanBusInfo [snip] > Module NE3200P.LAN NOT loaded > >What exactly is the public symbol stuff? NE3200P.LAN is designed for a different NIC. Make sure you are using the correct .LAN modules for your Intel NIC. Failing that, consider the following: You need patches. Take a look at the following URLs: ODI33F.EXE: ODI 3.31/1.11 Update (recommended) http://support.novell.com/cgi-bin/search/patlstfind.cgi?2933514 intraNetWare Support Pack v4.0 (recommended) http://support.novell.com/cgi-bin/search/patlstfind.cgi?2931406 Common TCPIP.NLM for NW 3.12 and 4.x (recommended) http://support.novell.com/cgi-bin/search/patlstfind.cgi?2930326 The important one here is ODI33F.EXE, which will resolve all those "MSM" related messages. The Public Symbols are APIs (Application Programming Interfaces) used by the NLMs and OS to interact with each other. They "call" each other with previously agreed upon parameters (arguments). For example (simplified), if a user tries to browse a web site hosted on your server, a hardware interrupt would cause the .LAN driver (and in turn all the MSM-related NLMs) to call TCPIP.NLM, which in turn would call HTTP.NLM (or whatever web server you're using). Newer NLMs sometimes provide more Public Symbols (or subroutines) that didn't exist in previous versions. ------------------------------ Date: Sat, 7 Mar 1998 00:25:45 +0000 From: Richard Letts Subject: Re: Mysterious MAC Address 0180C2000000 >I think this may help you > >The vendor code for 0180C2 is: >Enance Source Co., Ltd. PC clones. Erm, I think that would be 00:01:80:c2:xx:yy addresses Do an altavista search for +0180C2000000 and you'll get several useful references, includng a 'how it works' guide on the 3com site in particular: Spanning Tree Addressing Transparent and source route transparent bridges participate in a Spanning Tree domain, which is identified when the destination address field of the Spanning Tree packet is the hexadecimal group address 0180C2000000. Source route bridges participate in a different Spanning Tree domain, which is identified when the destination address field of the Spanning Tree packet is the hexadecimal bridge functional address 030000008000. Both addresses are shown in canonical addressing format. ------------------------------ Date: Tue, 17 Mar 1998 10:23:49 -0700 From: Joe Doupnik Subject: Re: Intel NIC >Has *ANYONE EVER* had any success with combining an Intel >EtherExpress PRO/100 NIC and *ANY* version of a Netware Client for >NT4(server)? I don't think the combination is possible. ------- Works here. I bring up NT least often so details are not at my fingertips, nor am I interested in ferreting out details. Please keep in mind that PCI bus compatibility plays a large role in these things, and consequently even your display adapter has a chance of confusing the system. Joe D. --------- Date: Tue, 17 Mar 1998 11:19:25 -0800 From: Kevin Brackley Subject: Re: Intel NIC We have about 15 or so NT 4.0 workstations and 2 NT servers (although stripped down to be nothing more than a workstation) running NWCL 4.11 w/workstation manager, all running Intel Pro 100 (REV B <---really important) cards. REV A cards will not work with Client 32 or ODI drivers. ------------------------------ Date: Mon, 23 Mar 1998 20:40:12 -0500 From: Greg Mullane Subject: Re: Intel NIC >I've recently had the same problems with a couple >PC's here. Same situation, have tried 3Com 3C905 >nics and Intel EtherExpress Pro 100 nics too. >Microsoft client hooks up just fine, but Client-32 >will not see the tree or server. Nothing. I used to have the same problem, here's the workaround I use: Rule #1: Never trust Windows. Don't pick any network drivers from a list, always use the "Have Disk" button. The best way I have found is to add all the network components during the initial setup of the OS. For the Intel EtherExpress Pro 100, make sure that you are using the "Intel 82557-based PCI Ethernet" driver. It is the only one that works reliably. For the 3COM, their "3COM Fast EtherLink XL 10/100 MB Ethernet Adapter" works well in most cases. Here's the process, starting from the Network Configuration part of the setup: 1) Remove everything. Card, client, NetBEUI, etc.. 2) Add a card using "Have Disk" and pick the right driver. 3) Remove other clients, NetBEUI, IPX (everything else that popped up after you added the card) 4) Add TCP/IP 5) Add the client using "Have Disk". I usually copy it to a local directory first as it may not be able to read from a CD at this point. 6) Configure everything know while you are here (Tree, frame type, etc.) 7) Finish with setup Works every time, on Intel and 3Com. I've found that when I don't add the card at this point, it never works correctly with the client. ------------------------------ Date: Fri, 27 Mar 1998 11:57:07 GMT+1100 From: Rees Griffiths Subject: Re: INTEL Server Card Some months back I posted to the list with a problem with an INTEL Etherexpress 100 Server PCI card in a Netware 3.12 server. Thanks to feedback from list members and some hunting around on the Novell support site I was able to determine that I needed the following patches 312pt8.exe or later. Its now up to 312ptd.exe and the new ODI product installation odi33f.exe I've only this week been able to bring the server down and try out the above. Works fine. ------------------------------