As of PicLan v 188.8.131.52 (and PicLan-IP v 2.0.0(build 142), The PCI driver in PicLan has been extended to support additional netwrok adapters based on the Digital "tulip" chipsets as well as look-alike "tulip" type chips.
Board with the following PCI chips have been tested and operate with PicLan:
A number of additional chips have also been entered in the PCI chiptype table, but zero testing has been completed so operation is unlikely.
Initially, boards that used the 21040 chip were the most common. Recently, a number of manufacturers have switched over to the 21041 chip, which provides somewhat enhanced support for non-intel systems as well as better documented interfacing with the AUI port on combo adapters. Currently, Linksys appears to be using the 21040 chip and both Compex and SMC appear to be using the 21041 chip. The 21140 chip is reportedly used by the SMC 100BaseT PCI board (called the EtherPower).
Initially, the following adapter have been tested in-house at Modular Software:
Because of the architechure of the 21041 chip, the PicLan driver may have difficulty in reading the ethernet node address from the card's ROM. If you have this problem, you can supply a manual node address for the PicLan driver.
Many of these boards are "combo" adapters supporting coax, twisted-pair, as well as AUI connectors. Support for the AUI connector is not well documented by DEC for the 21040 chip, so it is likely that the AUI port will not work with PicLan with 21040 based boards. These boards also support "full duplex" 10baseT connections. PicLan does implement this feature, but it has not been tested.
The PCI Ethernet support within PicLan is not available everywhere. Because of memory limitations, only the following clients and servers include support for these PCI adapters:
Testing of the PCI adapters at Modular Software include a limited number of systems, all Pentium clones.
With Piclan version 184.108.40.206, the PCI driver now uses a numeric parameter to configure the PCI adapter. This parameter is documented when you run the Pick PL-CONFIGURE program for a PCI device.
If you are configuring a Lite-ON PNIC board like the NetGear FA310TX, you should use 00 to 10 megabit half-duplex, 01 for 10 megabit full-duples, 10 for 100 megabit half-duplex and 11 for 100 megabit full-duplex.
If you are running without PL-DEV, the PCI driver will try to load after the IPX driver and before the ENET driver. If you are loading PL-DEV, the load order is IPX, EPKT, APKT, PCI, and ENET. You can use the /nopci switch to disallow the PCI driver with PL-DEV. The PCI driver will not attempt to load on pre 386 systems.
The PCI specification allows multiple adapters to share IRQ lines. Some operating systems support this. Pick does not. If you have a motherboard that assigns the same IRQ line to multiple adapters (for example, a PicLan network adapter and a Monolith PCI serial host adapter). then neither driver will function. Whether this happens to you is a function of the PCI setup functions within your system BIOS. It you think this is happening to you, call your dealer. Each motherboard is different and different proceedures are used in each case.
As is true with most test environments, PicLan is stress tested using test programs that are designed to simulate larger environments than would be practical to assemble. Using the multi-session capabilities of PicLan, DOS workstations are able to connect to as many as 256 ports on a Pick host system simultaniously. This allows the Pick host system to be fully stressed without requiring hundreds of PCs.
The test client program is called BUCKET2.EXE and is a DOS program that is designed to open and read a large number of sessions concurrently with minimal overhead. This program literally reads from network connections and discards the data (thus the name BUCKET). As far as the Pick host system is concerned, the bucket program acts like a lot of terminal users that never type anything.
In testing PicLan with PCI drivers, several characteristics were noted:
With a PCI to PCI network connection, the effective aggregate baud rates versus number of users was measured at:
Some additional testing at 100 Megabit were performed. The single-session bause rate was about 7,500,000 baud and the multi-session baud rate jumped to about 12,000,000 baud. This indicates that the network is not really the bottleneck, but it is instead the speed that the Pick and client can produce and consume meaningful data.
If you would like to test PicLan yourself, you can download the latest copy of BUCKET2.EXE from the BBS and run your own tests. Just put together fast systems running BASIC programs on the host that print a lot, log a lot of ports on, and see how much terminal I/O happens. One word of caution, don't try this on a live end-user's network. They can get a bit unhappy.