 |
 |
 |
|
||
|
||
| ||
|
|
|
|
|
||
|
||
| ||
|
The second part of the review is devoted to gigabit network adapters on a 64-bit PCI bus. Read Part One to see the test results for these adapters on a 32bit bus. Unlike 32-bit PCI buses, which can be found in all current x86 computers, 64-bit PCI buses are still a prerogative of servers and professional workstations. The bottleneck of a gigabit network adapter operating on a 32bit bus is the bus. In case of 64bit, it's the adapter. In fact, the CSA bus from Intel (reviewed below) solves the "bottleneck" problem of the bus with gigabit network adapters installed on common computers, but not all mainboards have CSA and it is used only for integrated adapters. We used the following cards in our tests:
Due to the lack of gigabit adapters from Intel (64bit PCI bus) in Moscow we used network adapters integrated into the testbeds. Adapters were tested in pairs (two identical gigabit adapters on different computers), but we didn't manage to find a pair to the following adapters: SysKonnect SK-9822 Dual Link, SK-9821 and SK-9821 v2.0 (all over copper). We decided to install a dual-head SK-9822 Dual Link adapter on one computer, and SK-9821 (the first or the second version) on the other. And we take into account that SK-9822 Dual Link is the most expensive and powerful of the three adapters (and thus it probably cannot be the bottleneck of the combo). That is when you see SK-9821 (or SK-9821 v2.0) in the diagrams, it means that the tests were performed not between two identical adapters, but with SK-9822 Dual Link and SK-9821, and the readings (including CPU Load) were taken only from SK-9821. The second part of the review studies the same adapters, which had been tested in Part One, the only difference is the bus, to which they were connected. But D-Link DGE-510T is not included into the list (it has a 32bit PCI interface), two network adapters from Intel are added instead: the first is embedded into TYAN Trinity GC-SL and operates on a 64bit PCI bus, the second works on a CSA bus on the Intel D875PBZ mainboard.  Intel 875P chipset - schematic diagram Communications Streaming Architecture (CSA bus) is connected directly to MCH (Memory Control Hub) and constitutes an internal project of Intel. At present it is implemented in chipsets i865 and i875. For long-run prospects CSA allows to install various devices requiring fast access to system resources and, which is sometimes more important, access with a guaranteed throughput of a dedicated channel. At present, though, there exists only one solution for this bus - Gigabit Ethernet Intel PRO/1000 CT chip (Kenai II CSA) - and the prospects for other solutions (not from Intel) are more than obscure. In reality, hardly all mainboard manufacturers will agree to use this rather expensive chip from Intel - in this case CSA will be left out of job. The reasons that urged Intel engineers to organize a dedicated bus for a gigabit network adapter (in fact, CSA was created with this task in mind) from the northbridge (in defiance to the traditions) are obvious: throughput shortage in the previous solutions. In fact, theoretically maximum throughput of a 32bit PCI bus running data transfers in case of an external network adapter is 133 MB/sec (in reality it is always lower because of losses to service data transfers), which in practice can already limit gigabit network adapters, besides there are other PCI-devices as a rule requiring "taking care of". Moreover, a data stream from a PCI bus does not head directly to memory, it must also pass "coordinations" on the level of inter hub connection controllers (in case of Intel chipsets) in both hubs-bridges. For example, activity of the hard disk subsystem curtails the bus throughput from the network adapter even more, thus even the performance of embedded Gigabit Ethernet chips can be limited from above because of the connection to the southbridge. With all this in mind, the advantages of connecting a network controller directly to the northbridge (closer to memory) via a bus with redundant throughput at 266 MB/sec are obvious. It is evidently less than the throughput of a 64bit PCI bus, but the latter is designed for the northbridge; and speaking of CSA, it, firstly, can be used in Desktop solutions, and, secondly, it's an independent bus, and unlike a 64bit PCI, it is linked only to a gigabit controller. The theoretical basis for Gigabit Ethernet is given in this article. We are going straight to the testbeds. Computers of the following configurations were used as two testbeds:
The tests were performed under the two operating systems:  Windows 2000 Pro with service pack v4.   Gentoo Linux 1.4 with kernel v2.4.24. Let's take a closer look at the platform used for the testbeds.  TYAN Trinity GC-SL adapter used for the testbeds is based on a ServerWorks Grand ChampionGC-SL chipset and is claimed by the manufacturer to be ideal for OEM companies and system integrators who need a wide range of features and a maximum bandwidth of the servers at a moderate cost. The platform supports Pentium 4 CPUs with Hyper-Threading and a 533-MHz system bus. Trinity GC-SL also supports simultaneous operations of PCI-X/PCI boards, DDR memory, and has a built-in graphic adapter based on chip ATI RAGE XL, and the features are in a compact ATX form factor. Besides, the board has two integrated network adapters on Intel chips (Gigabit and FastEthernet). In other words, the platform perfectly suits our test purposes. During the tests, we disabled (in BIOS or with jumpers) all additional onboard controllers, such as USB, GigabitEthernet, etc. The Hyper-Threading option was also disabled, and the operating systems were installed without its support. All external adapters were tested in a 64bit PCI slot supporting 66 and 100 MHz. Both computers were directly connected (without a switch) by a 5e twisted pair cable 8 meters long (for copper adapters) or by an optical 62.5/125µ cable 5 meters long (for optical adapters). Test MethodsWindows 2000The following programs were used for TCP traffic generation and readout in Windows 2000:
The programs were run to estimate the data transmission speeds and CPU load at standard packet sizes and with Jumbo Frames enabled. Other card settings remained by default. The Jumbo frame sizes varied:
Naturally, cards that didn't support certain Jumbo frame sizes skipped these tests. We also fine-tuned the operating system. Below are the program startup parameters and registry settings:
With Iperf and NTTTCP each test was run 9 times, and then the best (the fastest) result was selected. For NTttcp and Chariot the CPU load was measured by the built-in program tools, and for Iperf - it was not measured at all (because it cannot be done in this program). Gentoo Linux 1.4For traffic generation and readout in Gentoo Linux we used NetIQ Chariot and netPIPE v2.4. The latter generates traffic with a gradually increasing data packet size (N-size packet is transmitted several times, the number of transmissions is inversely proportional to its size, but not less than seven). This schema illustrates the bus usage depending on the volume of transferred data. Jumbo Frame size was changed by modifying MTU in network interface
settings using the following commands
netPIPE startup parameters: Chariot was run with the same parameters as in Windows 2000. List of network adaptersIntel 82545EM Gigabit Ethernet ControllerThis is an embedded controller on the Trinity GC-SL mainboard operating on a 64bit PCI bus. This controller was disabled with a jumper by default (when the other adapters were being tested). Initially Intel 82545EM was positioned as an embedded solution for server or workstation mainboards. Key features
In Windows tests we used the latest drivers v7.3.13.0 from the company web site.  The drivers are universal and have their own GUI with many options to configure and diagnose adapters.   Besides adapter details you can diagnose the cable connected to the adapters and get some information.   Unfortunately, you cannot set the Jumbo frame size to 3000 bytes in the menu, - the sizes are specified discretely: off (no Jumbo), 4088, 9014 16128 bytes. The reasons for this limitation are not clear, especially concerning the size of 4088 bytes - not all adapters from other manufacturers support frames of this size. We could skip adapter tests for this frame size, but in this case we would get a large gap between frame sizes of 1.5 and 9 KB. Thus it was decided to consider the 4088 size for a 6 KB frame (for other manufacturers), that is you should bear in mind that on the performance diagrams 6KB for Intel adapters means a 4 KB frame. In Linux we used the driver v.5.2.20-k1 included into the kernel. It allows arbitrary MTU sizes up to 16000 bytes. Intel 82547EI Gigabit Ethernet Controller
It's also an embedded solution, controller is installed on the Intel D875PBZ mainboard, which had been already reviewed on our web site. This controller is interesting because it sits on the CSA bus. It was Intel 82547EI that had been designed for the CSA bus on the Intel 865 and 875 chipsets. Key features:
Situation with drivers is identical to the previous controller Intel 82545EM. 3Com 3C996B-T Gigabit Server Adapter   3Com 3C996B-T adapter is positioned as a server card. It possesses a Low Profile PCI design and it can be installed into U2 servers, as all the other cards tested in this review. The adapter has four LEDs installed. Three of them indicate the speed mode of 10/100/1000 MBit, the fourth is used to signal data transfers. Main characteristics of the card:
It's a one-chip adapter with a microcontroller BCM5701 from Broadcom Corporation.
The controller is created using a 0,18-micron CMOS-technology with an
integrated PHY transceiver.
 Key features:
3Com 3C996B-T bundle includes a CD with drivers, diagnostics utilities and accompanying programs. On their official web site we discovered new driver versions, both for Windows and Linux, which were used in our tests.   Windows drivers have their own interface, which offers a lot of options for adapter configuration and diagnostics.   It includes an option to test the length and parameters of a cable connected to the network adapter.  But this interface does not allow to modify Jumbo frame sizes, so we had to do it the old way, via the standard interface of adapter settings in Windows. The maximum possible Jumbo frame size is 9000 bytes (it can be modified discretely with a 500-byte step). We used the drivers v.6.34 (dated 16.02.2003). In Linux we used two drivers. The first is Broadcom Tigon3 (tg3) v2.3, the second is Broadcom BCM 5700 v5.0.2. Both drivers were included into the kernel and allowed the maximum MTU size of 9000 bytes. CNet ProG2000L Gigabit Ethernet Card on chip Realtek RTL8169   CNet ProG2000L is a gigabit adapter based on a Realtek RTL8169 chip with a very attractive price (which has always distinguished products based on Realtek chips). The adapter has four green LEDs with the functions identical to the 3Com card. Main characteristics of the card:
 RTL8169 controller from Realtek possesses the following features:
The second chip installed on the card (Marvell 88E1000) is a physical layer controller (PHY).  Windows drivers did not have their own configuration interface, the whole thing was done with the built-in tools of the operating system. The drivers allowed Jumbo frame sizes from 3000 to 7000 bytes at a 1000-byte step. Drivers v6.11 were used. Adapter performance in Windows was rather low despite the 64bit PCI interface. In Linux we used drivers v1.2 included into the kernel (r8169). Unfortunately, the driver did not allow to set a larger than standard MTU size, rummaging in the driver depths was not successful either. That's why CNet ProG2000L is one of the two gigabit adapters in this review, which were not tested with Jumbo frames enabled in Linux. But even with a standard MTU size (1500 bytes) and a 64bit bus this adapter was not very stable - in the NetPipe test on a 64bit PCI bus the test sometimes froze (data transfers stopped) at the packet size of 196605 bytes (on a 32bit bus this situation appeared a little later on the verge of 262141 bytes). Hardlink HA-64G Gigabit Ethernet Adapter based on Altima AC1001 chip    Hardlink HA-64G already took part in the previous review of gigabit adapters. At that time the adapter showed problems with Jumbo frame support in both operating systems. But this time it supported giga-frames without any problems. The adapter has three indicators installed near the RJ-45 connector, which indicate with flashing links at 10/100/1000 MBit and a data transfer mode. It's a one-chip adapter using AC1001KPB from AltimaCommunications as its Ethernet-controller. Main characteristics of the card:
 AC1001 microcontroller is a 10/100/1000Base-T Ethernet controller with an embedded transceiver. Key features:
 In Windows we used the driver v1.0 from the company web site. Jumbo frame sizes in them vary from 1500 to 4000 at the step of 500 bytes. In Linux the adapter was tested with the Broadcom Tigon3 (tg3) driver v2.3 (similar to the adapter from 3Com). MTU size in tg3 can be set up to 9000 bytes. TRENDnet TEG-PCITX2 Gigabit PCI Adapter based on DP83820BVUW chip   TRENDnet TEG-PCITX2 is a dual chip adapter of the previous generation. Nevertheless its speed characteristics and its microcontroller popularity still appeal to manufacturers. PHY controller of the card has a heatsink. The rear panel contains six LEDs, the first three indicate 10/100/1000 Mbit link speed, and the rest indicate collisions, full-duplex, and activity. Main characteristics of the card:
 The card is based on a DP83820BVUW microcontroller from National Semiconductor. DP83820BVUW is a 10/100/1000 Mbit Ethernet-controller. It does not have an input transceiver, just interfaces to connect to an external transceiver and a PCI bus. Key features:
 The second chip (DP83861VQM-3) is a PHY transceiver. Due to overheating during operation this chip has a heatsink installed. Transceiver can operate at 10/100/1000 Mbit/sec in half and full-duplex modes. It supports automatic link configuration including speed, duplex, and flow control (IEEE 802.3u Auto-Negotiation).  In Windows we used the driver v5.0.1.24 from the company web site. In this driver Jumbo frame sizes can be set from 1500 to 16128 bytes, but in reality the adapter was tested on the maximum frame size of 9014 bytes, because when the frame size was set to 16128, no data transfer was detected (even packets with minimum size did not reach the destination). In Linux we used the National Semiconduct DP83820 (ns83820) driver v0.20. And though the MTU size could be changed up to 8192 (having previously modified the RX_BUF_SIZE variable in driver sources), the adapter did not work with Jumbo frames enabled. The same situation was with driver versions 0.15 and 0.18. That is the situation with the Windows driver repeated itself at the 16128 frame size. Thus, TRENDnet TEG-PCITX2 turned out the second adapter, which was not tested with Jumbo frames enabled in Linux. This situation surprised me because in the previous review with older drivers the card worked OK. TRENDnet TEG-PCISXM2 Fiber Gigabit PCI Adapter on a Marvell Yukon 88E8010 chip   TRENDnet TEG-PCISXM2 Fiber Gigabit PCI Adapter is a gigabit optical adapter. Copper or optical adapters (from the same manufacturer) usually use the same logics - they are equipped with the same microcontrollers and these cards actually differ only in PHY transceivers. Optical gigabit adapters have another essential distinction: they operate only at 1000 Mbit, that is 10 and 100 Mbit modes are not supported. The adapter has two LEDs (link and activity). Main characteristics of the card:
 Yukon 88E8010 controller from Marvell is a one-chip solution for a gigabit server card with an embedded PHY controller. It does not have an embedded transceiver, just interfaces to connect to an external transceiver and a PCI bus. Key features:
 In Windows we used the driver v6.13.0.0 (dated 28.04.2003) from the company web site. Jumbo frame sizes can be set from 1500 to 9000 bytes. In Linux we used the sk98lin driver v6.24. MTU size can be modified from 1500 to 9000 bytes in much the same way. In the NetPIPE test in Linux we found an oddity in the adapter operation, it will be described in detail a tad below by the example of SK-9844 Dual Link. In short, data transfer rate considerably dropped with certain packet sizes, it can be clearly seen on the NetPIPE diagrams on the third page of the review. This anomaly appeared only with 1500,3000 and 6000 MTU sizes, with MTU=9000 adapter operated flawlessly. ZyXEL Omni Lan PCI G1 on a ZX1701 chip  ZyXEL GN650-T is a gigabit adapter over twisted-pair copper cable. The card contains four LEDS (10/100/1000Mbit and activity). Main characteristics of the card:
We didn't manage to find separate specifications on the ZX1701 controller installed in the adapter.  In Windows we used the driver v1.10 (dated 27.08.2003) from the company web site. The driver supported Jumbo frames, but, similar to the adapter from D-Link, the driver allowed only to enable or disable giga frames support. But you cannot possibly know the exact Jumbo frame size. That's why, like in the previous case, we consider a Jumbo frame size set to 3000 bytes. In Linux the situation is more curious. Despite the announced support for this operating system on the company web site, we didn't manage to find anything in the kernel (at least in v2.4.24) that would support ZX1701. CD shipped with the card didn't contain Linux drivers either. We found the driver only on the russian web site of the company (for some reason, the english web site did not have the driver for that moment) - driver v1.05 dated April 2003. But hardships were not over yet. The driver supports Jumbo frames, MTU size can be increased up to 9000 bytes. But already with 3000 bytes the data transfer rate in the Chariot test was extremely low, and with 6000 and higher the data transfer ceased completely in all tests. But even with MTU at 1500 and 3000 the driver module crashed at random moments to be never restored, the only solution was to reboot the computer: eth1: Link autonegation speed 1000M bps full duplex On the whole, the operation of this card in Linux left only negative impression, at least with this driver version (and there were no other at that moment). SysKonnect SK-9844 SK-NET GE-SX Dual Link, Fiber, on SysKonnect XaQti XQ11800FP chips  The entire series of the SysKonnect adapters we have tested is shipped in identical boxes (one of them is in the photo above). The only difference between them is side stickers with the names of the products. And of course, full-size PCI boards have longer boxes.   SK-9844 Dual Link is a dual-head gigabit adapter of a full-size PCI form factor. It's designed for optical communication medium. On the two photos above you can see only halves of the cards, the card in full length is shown above the two photos.   These two links allow to increase data transfer speed twofold (2Gbit in each direction) or to organize a fault-tolerant link. A separate review will be devoted to the 2Gbit link implementation in these cards. But you can estimate the fault-tolerant feature in the diagrams above. Link A and Link B were connected with optical cables and after that we started generating traffic. Initially the entire traffic passed along Link A. At the ~35th second we emulated Cable A breakdown (the cable was pulled out of the connector). The data traffic never ceased, adapters switched to the second (B) link and proceeded with the data transfer. Switching took about 300 milliseconds. At the ~55 second Link A was restored, and again the adapters detected the situation and switched the traffic to Link A. The rear panel of SK-9844 Dual Link houses two LED triplets (Link, RX and TX activity) three for each port, and a "Status" LED near Port A. Main characteristics of the card:
Such a long list of supported operating systems is very pleasing. The adapter's functional units are allocated on different controllers. The network controller is based on a XaQti XQ11800FP chip (XaQti is now a subdivision of Vitesse Semiconductor), the PHY controller is on GigaPHY Am79761, and the PCI bus controller is based on SysKonnect Gigabit Ethernet L5A9338. The adapter has two ports, hence two network controllers and two PHY controllers onboard.   Key features of XaQti XQ11800FP:
SysKonnect Gigabit Ethernet L5A9338 controller connects the adapter with the PCI interface. It supports PCI v2.2 and allows data exchange with the system over a 32/64bit bus at 33/66 MHz. The adapter uses as a buffer four installed Gal Vantech GVT7164 chips of SRAM with the total size of 1 MB. The adapter's internal sensors can check temperature and voltage thus allowing to control the parameters and keep them within the normal range.   In Windows we used the driver v4.21 from the company web site. Drivers have their own GUI, which allows convenient control over a single adapter or a group. Jumbo frame sizes can be set from 1514 to 9014 bytes.   Driver interface is identical for the entire SK98xx adapter series. They may differ only in minor details: for example, the interface will not have references to Port B in single-port adapters. And it is easy to set up fault-tolerant connections: you only have to drag necessary ports into a group with your mouse. Channel aggregation can be organized in a similar way.   The driver also allows to view the traffic statistics.   Here you can monitor temperature and voltage information, received from the internal sensors. In Linux we used the sk98lin driver v6.24 with applied sk98lin_2.4.24.patch (from the company web site). The MTU size can be varied within 1500 and 9000 bytes. The adapter acted ambiguously in Linux. On one hand, the speed was quite high; on the other hand, data transfer almost completely stopped at certain packet sizes in the NetPIPE test (packets passed at a snail's pace). You will see it in the diagram. This happened at the MTU sizes of 1500, 3000, and 6000 bytes, while the adapter worked all right at MTU=9000. Interestingly, the situation repeated itself with all SysKonnect adapters, and the reason for this is anyone's guess. Although the maximum speed test by means of Chariot revealed no anomalies. SysKonnect SK-9843 SK-NET GE-SX, Fiber, on a SysKonnect XaQti XQ11800FP chip  SK-9843 SX is almost identical to SK-9844, except for a single port in SK9843 SX. Circuitry also seems the only difference (except for the sizes), SRAMs are from different manufacturers but they are both 1 MB. The adapter's characteristics coincide with those of SK-9844. In Windows and Linux we used the same driver versions, like in all other adapters of the SK98xx series tested in our lab.SysKonnect SK-9843 v2.0 SK-NET GE-SX, Fiber, on a Marvell Yukon 88E8010 chip  SK-9843 SX v2.0 replaces the previous version of the SK-9843 adapter. It is based on the Marvell Yukon 88E8010 controller (see the TRENDnet TEG-PCISXM2 description above). The card has an optical interface and is supported by a standard SysKonnect driver with its own interface (as is the case with the entire SK98xx series). The card also features two LEDs (link and activity). Main characteristics of the adapter:
The Linux and Windows drivers are identical to the above mentioned drivers for the SK98xx series. The adapter operated in Linux in the similar way. SysKonnect SK-9822 SK-NET GE-T Dual Link, on SysKonnect XaQti XQ11800FP chips We didn't actually test the SK-9822 SK-NET GE-T Dual Link adapter (we didn't manage to find a pair). But it was used to test SK-9821 and SK-9821 v2.0 adapters, because they didn't have a pair either. K-9822 SK-NET GE-T Dual Link was used as a substitute for the both cards in the second testbed. Like SK-9844 Dual Link, it's a two-port adapter, which makes it possible to organize fault-tolerant connections and involve channel aggregation.   The two photos above show adapter halves. Its circuitry is similar to that of SK-9844 Dual Link, but as SK-9822 Dual Link is designed for a copper twisted pair, it uses another type of PHY controller - namely, Broadcom BCM5400. Both PHYs are hidden under the heatsinks but, interestingly, the controller on Port A has a fan while the one on Port B hasn't. Evidently, Port B is not supposed to work constantly, but then again, what about channel aggregation? The company probably decided that transceivers do not heat that much (and indeed, they were really just a little warm during operation). The adapter also houses 1 MB memory allocated in four chips. The back panel contains two triplets of LEDs (link, TX and RX activity - three for each port) and a Status LED. The main characteristics of the adapter:
SysKonnect SK-9821 SK-NET GE-T, based on a SysKonnect XaQti XQ11800FP chip
   SysKonnect SK-9821 SK-NET GE-T is a single-port version of SK-9821. The PHY controller has a heatsink with no fan, which confirms the version that the fan installed on one of SK-9822 Dual Link's PHYs is just a reassurance. The card also has 1 MB SRAM allocated in four chips. The rear panel houses a triplet of LEDs (with the functions identical to those of SK-9822 Dual Link) and a "Status" LED. Characteristics and drivers used are similar to those of the previous card. I have to remind you again that in this case we tested a SK-9822/SK-9821 combo instead of a pair of identical adapters, although all the readings were taken from SK-9821. SysKonnect SK-9821 v2.0 SK-NET GE-T, on a Marvell Yukon 88E8010 chip
  SysKonnect SK-9821 v2.0 SK-NET GE-T is built on the Marvell Yukon 88E8010 microcontroller (like SK-9843 v2.0). From the said network adapter SK-9821 differs only by the communication medium (twisted-pair cable) and thus a slightly modified circuit. Memory buffer (128Kb) is integrated into the microcontroller. The rear panel contains four LEDs, three of which indicate 10/100/1000 Mbit link presence, the fourth LED indicates data transfers. Characteristics and drivers are the same as with the previous network adapter. As in case of SK-9821, we didn't test a pair of identical adapters, but a combo of SK-9822 and SK-9821 v2.0, but all the readings were taken from SK-9821 v2.0, of course. Navigation:
Evgeniy Zaitsev (eightn@ixbt.com)
27 May, 2004 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. |
