 |
 |
 |
|
||
|
||
| ||
|
|
|
|
|
||
|
||
| ||
|
When we tested the Gigabit adapters last time we came to the conclusion
that the 32bit PCI bus working at 33 MHz is not efficient enough to unveil
the whole potential of microcontrollers of these cards. Especially in case
of server adapters with the 64bit PCI interface. That is why we tested
these adapters on the server platform with the 64bit PCI slots. The platform
is built on the AMD-760MPX based mainboards.
I must note that stability of operation of these mainboards on this chipset (or rather, of the chipset itself), in spite of the latest BIOS version, wasn't very good. That is why not all tests could be started, and the results were often far from expected. If these adapters hadn't been tested on the 32bit Intel PCI platform I would blame them. But the previous tests were bugless, and now we have errors everywhere. That is why I think that it is the AMD-760MPX chipset which is faulty. The adapters therefore were tested on the platforms based on the Intel's chipset. Stability of the AMD platform was compared to operation of these cards on the INTEL platform. In the latter case I noticed no problems in operation, though it's possible that it depends on certain manufacturers and certain models of mainboards. The bugs listed below were noticed on both stands depending on a number of the PCI connector used. A bit on the AMD-760MPX. This chipset is an extension of the AMD-760MP which is the first chipset from AMD supporting dual-processor configurations. This is what differs it from the AMD-760. There is one more difference, but the key one is the 64bit PCI bus support. Here are brief characteristics of the AMD-760MPX.
The tests are carried out on two computers: one based on the AMD Athlon 1700 MHz processor with the MSI K7D Master mainboard (uniprocessor configuration), the other on two AMD Athlon MP 1200 MHz processors installed on the Asus A7M266-D mainboard. The other components are identical for both computers:
The computers were directly interconnected (without a switch) by a 8m cable of the 5e category (almost ideal conditions). On the dualprocessor machine the OSes had the SMP mode enabled. But the processor's load was measured on the uniprocessor machine (on the AMD Athlon 1700 MHz). The theoretical aspects on the Gigabit Ethernet were given here, and now we are turning to the participants. CardsToday we have 5 cards with the 64bit PCI interface. The first card is Hardlink HA-64G, from MAS Elektronik AG     Next to the RJ-45 connector of the adapter are three LEDs indicating the established connection at the speeds of 10/100/1000 Mbit and data transfer mode by blinking. The network adapter uses one chip, the AC1001KPB from AltimaCommunications is used as an Ethernet controller.  The AC1001 microcontroller is the 10/100/1000Base-T Ethernet controller with an integrated transceiver. Here are its characteristics:
 Apart from the microcontroller the card has several other chips. One of them, located between the controller (or a transceiver if it's external) and RJ-45 connector, is used on every adapter. In this case this is PG243002 from YCL Electronics Co., Ltd; this is a passive filter for common-mode interference suppression. It allows making the segment longer up to 100 m at 1Gbit of data receipt/transfer. The chip is separated from the main controller because the technology of production of analog chips and logic differs. It's difficult to make the inductance characteristics acceptable in the CMOS chips (i.e. to include an inductance coil or a transformer into the chip). 
 Also, the card has a voltage stabilizer marked LMS1585 and EPROM memory chip 24LC32A of 32 Kbit.   For installation of the Hardlink HA-64G under the Windows we used the drivers supplied on a diskette with the card because there were no newer versions on the site. The driver has the minimal set of options and the Jumbo Frames can have values of 1500, 2000, 3000 and 4000. Nevertheless, when we enabled the Jumbo frames it was impossible to transfer data at all. For Linux we also used the driver supplied with the card (Gigabit Ethernet Driver AC1000 v.10.3 of 27/12/01), as there were no newer versions. In the Linux we found the driver "Broadcom Tigon3 support" which supports some Altima chips. But it failed to work with this card; well, it was expected because it's said to support only the AC1000 microcontroller. Unfortunately, the driver provided doesn't let us change the MTU size and enable the Jumbo frames support. Probably, it's possible to enable the support somewhere inside the driver's sources but I couldn't do it. That is why the Hardlink HA-64G was the only adapter tested without Jumbo frames (on MTU of 1500).  The second card is 3C996B-T from 3Com, it wasn't tested before.   The card has a Low Profile PCI design and can be installed into U2 servers, like other cards in the today's round. This is the only card whose drivers and utilities were recorded on a CD (the other cards come with diskettes). The adapter has 4 LEDs: 3 notify on the speed mode (10/100/1000 Mbit) and the fourth one blinks when data are transferred. The adapter is also based on one chip and uses the BCM5701 microcontroller from Broadcom Corporation. The controller is based on the 0.18-micron CMOS technology and has a physical-level transceiver.  Its characteristics:
(transmission of several received packets at one interrupt) (remote control of OS-absent network devices)  As a passive filter for common-mode interference suppression they used the S558-5599 chip from Bell Fuse Inc. The LT1764 chip (located on the right) is a voltage stabilizer. The 3Com 3C996B-T adapter comes with a CD with drivers, diagnostics utilities and additional programs. The English site has newer drivers both for Windows and for Linux.   For the Windows we installed the latest driver version (2.67). The interface provides rich settings for the network adapter and good diagnostics means. The Jumbo Frame size can be set from 1500 to 9000 in 500 steps. I have no complains about operation of the adapter in this OS. For the Linux I had three drivers in all. Two of them are Broadcom BCM 5700 with Broadcom NIC extension (NICE) v2.028 (of 05/11/2001) from the CD and the same driver of v5.05 (of 24/09/2002) downloaded from the site. Both drivers were successfully compiled but failed to work on the kernel v2.4.20. The version 5.05 displayed Segmentation Fault when we tried to activate the adapter, the version 2.028 showed Kernel Panic when we tried to send some data (e.g. ping). On the previous kernel version 2.4.19 both drivers were compiled and worked but didn't allow changing the MTU size (displaying Invalid argument). The last driver was taken from the Linux kernel - Broadcom Tigon3 (tg3) 1.43.2.80 (it's identical in the kernels 2.4.19 and 2.4.20). The adapter worked with it flawlessly. The other three adapters are based on two chips. All are built on the microcontroller DP83820BVUW from National Semiconductor. DP83820BVUW is a 10/100/1000 Mbit Ethernet controller. It doesn't have an integrated transceiver but only interfaces for communication with an external transceiver and a PCI bus.  Its characteristics:
 The second chip - DP83861VQM-3 - is a physical level transceiver. On most adapters it's covered with a heatsink as the transceivers heat much. The chip (when replacing a card right after turning off the system the chip, when without a heatsink, or the heatsink are very hot. The transceiver can work at 10/100/1000 Mbit/s in the half and full duplex modes. It supports IEEE 802.3u Auto-Negotiation. This time the bug described in the previous review (about an unknown PCI device) wasn't registered. 
It means that it's not the adapter's driver to blame but a combination of certain mainboards and adapters.  The first board on the logic above is TRENDnet TEG-PCITX2 from TRENDware.   The transceiver is capped with a heatsink. On the back are 6 LEDs, three informing on the connection speed (10/100/1000 Mbit) and the others indicating collisions, full duplex and data transfer.   For installation of the network adapter into the Windows 2000 we used the latest driver downloaded from the company's site - v5.01.24. The driver offers abundant settings for adjusting and tuning the card, and the Jumbo Frame size can be set manually in the steps of 1, the maximum size is unknown. With the frame of 16128, which was maximum in the tests, the adapter worked without problems. For the Linux there are drivers only for the kernel 2.2.x. In the kernel version 2.4.x they are not compiled, that is why we used the OS integrated driver National Semiconductor DP83820 v0.18 (for kernel 2.4.19) and v0.20 (for kernel 2.4.20). But it has the maximum Jumbo Frame size set at 8192. Without correcting the source driver code it's impossible to set the packet size over 1500. On the driver v0.20 with Jumbo Frames enabled the adapter hang in the very beginning of the test (with the transferred packet size over 1024 bytes). The OS kept on working but the data couldn't be delivered as if the adapter was disconnected. With the driver 0.18 it happened a bit later, at MTU = 6000 and at the data volume exceeding 128 KB. On all other adapters with the DP83820 microcontroller such situation didn't occur.    The next adapter is SMC9462TX from SMC Networks. The transceiver has no heatsink. The card has 5 LEDs. Three show the operating speed and two indicate connection and data transfer. The latest driver (1.2.905.2001) for Windows downloaded from the site didn't work. During the booting (after installation of the driver) the OS displayed BSOD (blue screen). That is why we used the reference drivers in the tests (the same as for TEG-PCITX2) For Linux we used the integrated National Semiconductor DP83820, like in the previous case. The driver available on the site couldn't be compiled, and the compiled module which is supplied with the sources didn't start.  And the last card in the today's round is LNIC-1000T(64) from LG Electronics.    The transceiver is topped with a heatsink. The card has 6 LEDs with the functions identical to the TEG-PCITX2.   For Windows we used the drivers coming with the card because there were no new drivers on the site. From what I could tell, they are the reference drivers (identical to TEG-PCITX2) with the same functions, v5.01.24. The drivers for Linux were available only for kernels 2.2.x, that is why for the tests we used the same drivers as for TEG-PCITX2, i.e. the integrated one. Testing techniqueThe testing technique remains the same. In the Windows 2000 for TCP traffic generation and measurements we used Iperf 1.2 and NTttcp programs from the Windows 2000 DDK. The programs were used to measure data rates and CPU utilization at the following Jumbo Frame sizes:
The cards that didn't support certain Jumbo Frame sizes weren't used in these tests. Besides, the Iperf was run in the UDP traffic generation mode. The stream speed of the UDP traffic was fixed for the utility. The maximum speed reached was recorded as a test result. The maximum speed was calculated by the method of successive approximations with the minimum/maximum at 200/800 Mbit in 10 Mbit steps. The OS was also slightly tuned up. The startup parameters of the programs and settings of the register are the following:
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
Startup options of the Iperf in TCP mode: Startup options of the Iperf in UDP mode: Startup options of the NTttcp: Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
Startup options of the Iperf in TCP mode: Startup options of the Iperf in UDP mode: Startup options for NTttcp: Each TCP test was run 15 times, with the best speed result chosen at the end. In case of the NTttcp the CPU's load was measured with the program's own means, and in the Iperf it was done with the system monitor of the Windows 2000. In the Linux OS for traffic generation and measurements we used the netPIPE 2.4. The program generates a traffic with a gradually growing size of the data packet (a packet of the size N is transferred several times, the number of transmissions is inversely proportional to its size, but not less than 7). Such method shows the percentage of the channel utilization depending on the size of data transferred. The size of the Jumbo Frame was changed by changing the MTU in the settings
of the network interface by command
In the tests the following MTU sizes were used:
Startup options of the netPIPE:
Test resultsIn the tests under Linux the driver name and version, if there are several, are indicated in parentheses after the card name. 1. Windows 2000, transfer speed.  
  The 3Com 3C996B-T adapter wins in the most tests. The Hardlink HS-64G, at MTU = 1500, follows it. Unfortunately, we couldn't test it with the Jumbo Frames enabled, but I think the positions must remain the same. The advantage of these two adapters are on account of the new generation of the Ethernet microcontroller; two-chip adapters appeared much earlier. The SMC9462TX adapter shows much higher speeds in comparison with other two cards built on the same microcontrollers. It's quite strange, especially considering equal average results of these adapters on the 32bit PCI bus. Probably, it's caused by bad compatibility with certain mainboards or the AMD-760MPX chipset. In case of the minimal CPU load the 3Com's card goes ahead again (only 12% at the almost maximum speed for the 1Gbit Ethernet at MTU = 6000 !). The Hardlink's adapter showed the highest CPU load in spite of the latest microcontroller (with Jumbo Frames disabled); I hope the new drivers will improve the situation. I'm also surprised that the CPU load is quite high at MTU = 9000 and over on the two-chip cards. 3. Linux, MTU size. 
With the Broadcom's driver the 3C996B-T adapter performs much more efficiently as compared with the driver from TG3 (the documentation also recommends using the own driver). The other drivers have the expected results as well, only the two-chip adapters have a very "toothed" graph in case of disabled Jumbo Frames on v0.18. In case of v0.20 the graph gets smoother and the overall data rate gets higher markedly. 4. Linux, performance comparison at the same MTU size. 
These diagrams prove what we said above. The last one is the diagram of peak speeds of the adapters in netPIPE. The picture looks similar to the above ones except the fact that the speeds of the two-chip cards get equal (the SMC's adapter doesn't go ahead anymore).  ConclusionThe results should be confirmed by testing the adapters on another platform;
before this is done no fundamental conclusions should be drawn.
Evgeniy Zaitsev (eightn@ixbt.com)
Write a comment below. No registration needed!
|
Platform · Video · Multimedia · Mobile · Other || About us & Privacy policy · Twitter · Facebook Copyright © Byrds Research & Publishing, Ltd., 1997–2011. All rights reserved. |
