 |
 |
 |
|
||
|
||
| ||
|
|
|
|
|
||
|
||
| ||
|
We continue testing gigabit network cards. Since the time our previous review appeared, the technologies have made a big step forward and now gigabit adapters can be found integrated into a number of motherboards. But because they are mostly installed on 32-bit PCI buses, the advantage of their use becomes rather dubious. Tested cards:
Because there are no Intel gigabit adapters (on 64bit PCI buses) in Moscow, we used adapters integrated into test platforms. Besides, the CSA interface is also worthy of our attention, that is why we enlarged the test with adapters connected through it. The first part of our review features tests on a 32bit PCI bus, that is a gigabit board with a 64bit-PCI interface was placed into a standard 32-bit PCI connector (as they are backward compatible). This solution shows how gigabit adapters work on computers that have no 64-bit PCI interface (most home and office computers and entry-level servers). It also concerns the majority of gigabit adapters integrated into SOHO motherboards, as they are mostly installed on 32-bit buses. Intel's CSA (Communications Streaming Architecture) bus is quite another thing: it is connected directly to the MCHs (Memory Control Hubs) and the PCI bus is not involved. CSA gives a lower latency and a higher performance comparing to the traditional PCI bus. That is why adapters on the CSA interface are included into the second part of the review (where adapters are tested on a 64-bit PCI bus). 
 We declined to use "original" adapters with 32-bit buses in the first part of the testing because there's practically no difference between the circuitry of a 32-bit PCI adapter and the one of a 64-bit PCI. They both have similar results on a 32-bit bus. In some cases, however, the circuitries differ, as in the photos showing motherboards SK-9521 v2.0 and SK-9821 v2.0. In theory, they must look virtually identical. In practice, the right card (on a 64-bit PCI) has a mainboard with much more elements soldered. The first part of the review doesn't include all the adapters from the list above. The Intel adapters are absent, as the first one is integrated into the motherboard and "sits" on a 64-bit PCI bus, and the other one is placed on a CSA bus which is much faster than a 32-bit PCI one. The adapters were tested in pairs (two similar gigabit boards in different machines), but there was no pair for SysKonnect SK-9822 Dual Link, SK-9821, and SK-9821 v2.0 (all made for copper). We decided to install a dual-head SK-9822 Dual Link board from one side and SK-9821 (first or second version) from the other. And we take into account that SK-9822 Dual Link is the most expensive and powerful of the three boards (and is thus not a bottleneck of the liason). So, when you see SK-9821 (or SK-9821 v2.0) in the diagrams, it shouldn't be understood that two identical boards were tested (SK-9822 Dual Link was on one side), although all the results including CPU load were taken from SK-9821. Considering the restrictions above, the ultimate list of tested items looks as follows:
Total: 12 adapters. The theoretical basis of Gigabit Ethernet is laid in this article, and we're going straight to the testbeds. Computers of the following configurations were used as two testbeds:
Tests were made in two OSs:  Windows 2000 Pro with a preinstalled servicepack version 4.0.   Gentoo Linux 1.4 with a 2.4.24 core. We'll take a closer look at the platform on which test computers were made.  TYAN Trinity GC-SL board 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 that need a wide range of capabilities and a maximal 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 work of PCI-X/PCI boards, DDR memory, and has a built-in graphic adapter based on chip ATI RAGE XL, and all this is on a compact ATX form factor. Besides, the board has two integrated network adapters on Intel chips (Gigabit and FastEthernet). In other words, the platform suits perfectly for our tests. During the tests, we disabled (via BIOS or jumpers) all additional onboard controllers, such as USB, GigabitEthernet, etc. The Hyper-Threading option was also disabled, and the OSs were installed without its support. Both computers were directly (without a switch) connected to a 5e twisted pair cable 8 meters long (in the case of copper-oriented adapters) or to an optical 62.5/125µ cable 5 meters long (in the case of adapters that used optics for data transmission). Testing techniqueWindows 2000The following programs were used for TCP traffic generation and readout in Windows 2000:
The programs were started to estimate the speeds of data transmission and CPU load at standard packet sizes and with Jumbo Frames enabled. Other card settings were left in the default state. The Jumbo frame sizes varied:
Naturally, cards that only supported certain Jumbo frame sizes skipped these tests. We also tuned OSs a bit. Below are the parameters of program startups and Registry setting:
In the case of Iperf and NTTTCP each test was started 9 times, and then the best result in terms of speed was selected. The CPU load was measured by the program's integrated means for NTttcp and Chariot, and wasn't measured at all in Iperf, as the program doesn't allow to do it. Gentoo Linux 1.4For traffic generation and readout in Gentoo we used NetIQ Chariot and netPIPE version 2.4. The latter program generates the traffic with a gradually increasing data packet size (an N-size packet is transmitted several times, and the number of transmissions is inversely proportional to its size but can't be less than seven). This scheme enables to see the percentage of channel use depending on the size of the transmitted data.
Jumbo Frame was changed by changing MTU in network interface settings with the help of
Parameters of netPIPE startup: Chariot was started with the parameters similar to those in Windows 2000. Boards3Com 3C996B-T Gigabit Server Adapter 
 The 3Com 3C996B-T adapter is positioned as a server board. It has a low-profile PCI design and can be installed into U2 servers (as any other of the tested cards). The adapter has four LEDs, three of which indicate a speed mode (10/100/1000 Mb) and the last one shows data transmission by blinking. The card's basic characteristics:
The adapter is single-chipped too, with Broadcom Corporation's BCM5701 serving as a microcontroller. The controller is made using the
0.18µ CMOS technology and has an integrated physical-layer transceiver.
 Its characteristics are as follows:
The 3Com 3C996B-T is shipped with drivers (on a CD), diagnostic utilities, and additional programs. But we used newer driver versions for Windows and Linux found on the company's site.   Windows drivers have their own interface that provides a lot of variants of adapter configuration and diagnostics.   It includes the possibility to test the length and the parameters of the cable connected to the adapter.  But the interface doesn't allow to change the Jumbo frame size, and we had to do it in the old-fashioned way through the standard interface of adapter settings in Windows. The maximal Jumbo frame size is 9000 bytes, it can be changed with a 500-byte discreteness. The driver version used is 6.34 (released 16.02.2003). We used two drivers in Linux: Broadcom Tigon3 (tg3) version 2.3 and Broadcom BCM 5700 version 5.0.2. Both drivers were integrated in the core and supported up to 9000 bytes of MTU. CNet ProG2000L Gigabit Ethernet Card on Reaktek RTL8169 
 CNet ProG2000L is a gigabit adapter based on the Realtek RTL8169 chip, that has a very reasonable price (which has always been characteristic of Realtek-based products). The adapter has four green LEDs with the functions similar to those in 3Com. The card's basic characteristics:
 Realtek RTL8169 controller has the follwing characteristics:
The other onboard chip, Marvell 88E1000 is a physical-layer (PHY) controller.  Windows drivers did not include their own configuration interface, and OS-integrated means were used. The drivers enabled to specify the Jumbo frame size between 3000 to 7000 bytes with a 1000-byte step. The driver version used is 6.11. In Linux we used core-integrated drivers (r8169) version 1.2. Unfortunately, the drivers didn't allow to set a higher-than-standard MTU size, and digging in their insides was to no avail either. As a result, CNet ProG2000L is one of the two reviewed gigabit adapters that weren't tested with Jumbo frames enabled in Linux. D-Link DGE-510T Gigabit Server Adapter on D-Link DL-2001  The company positions D-Link DGE-510T as an adapter for servers and desktop PCs. The adapter has 4 LEDs, two of which indicate operational speed (100 or 1000 Mb), one shows full duplex, and the last one activity. The board was made on a DL-2001 contoller about which no information could be found. The second chip hidden under an unremovable heatsink is evidently a PHY controller of an analogical Marvell 88E1000 (and maybe it is the latter one). The card's basic characteristics:
The adapter supports priority queues for ensuring quality service, embedded filtering of tagged VLAN Ethernet frames, and a hardware calculation of IP headers and IP checksums. The card has integrated FIFO memory buffers with a 32/8Kb reception/transmission size.  D-Link Windows drivers include no individual graphic interface (the same as the previous card). Strangely enough, you can only enable/disable a Jumbo frame in the driver but you can't specify its size. And it is unknown what size is finally set, but we'll deem it equal to 3000 bytes. The latest version of drvier from the company's ftp server was used. In Linux, the adapter was tested with driver dl2k version 1.17 embedded into the core. It enabled an up-to-8000-byte MTU size increase. Hardlink HA-64G Gigabit Ethernet Adapter on Altima AC1001    Hardlink HA-64G was one of the gigabit adapters we tested in our previous review. Last time, it had some problems concerning support of Jumbo frames in both OSs. But this time, gigaframes were supported all right. Beside the RJ-45 connector, there are three LEDs showing link at 10/100/1000 Mb and data transmission by blinking. It is a single-chip adapter and AltimaCommunications AC1001KPB is used as an Ethernet controller. The card's basic characteristics:
 AC1001 is a 10/100/1000Base-T Ethernet controller with an integrated transceiver. Its characteristics, in brief, are as follows:
 For Windows, we used drivers version 1.0 form the company's site. Jumbo frame sizes in them vary from 1500 to 4000 bytes with a 500-byte step. In Linux, the adapter was tested on a Broadcom Tigon3 (tg3) driver version 2.3 (similarly to the 3Com adapter). The MTU size can be set as large as 9000 bytes. TRENDnet TEG-PCITX2 Gigabit PCI Adapter on DP83820BVUW 
 TRENDnet TEG-PCITX2 is a dual-chip adapter of the previous generation. However, its speed characteristics and microcontroller still attract manufacturers. The PHY controller houses a heatsink. The back panel has six LEDs, three of which show 10/100/1000 Mb connection speeds, and the rest ones indicate collisions, full duplex, and data transmission. The card's basic characteristics:
 The card is based on a National Semiconductor DP83820BVUW microcontroller. DP83820BVUW is a 10/100/1000 Mb Ethernet controller. It has no embedded transceiver, only interfaces for the external transceiver and the PCI bus. Its characteristics:
 DP83861VQM-3, the other chip, is a PHY transceiver. It has a heatsink as it heats significantly. The transceiver can work at 10/100/1000 Mbit/sec in half/full duplex modes. It supports auto negotiation of speeds and modes included in the list above (IEEE 802.3u Auto-Negotiation).  In Windows, we used driver version 5.0.1.24 from the company's site. The Jumbo frame size could be set between 1500 and 16128 bytes. The adapter, however, was tested at 9014 bytes, as the maximal size of 16128 bytes didn't ensure data transmission and even minimal-size packets couldn't go through. In Linux, we used a National Semiconductor DP83820 (ns83820) driver version 0.20. Although the MTU size could be varied up to 8192 (if the RX_BUF_SIZE variable was changed in advance), the adapter didn't work with Jumbo frames enabled, and the story repeated in versions 0.15 and 0.18. So, we observed the same situation as was with the Windows driver at 16128 bytes, and TRENDnet TEG-PCITX2 was the second adapter not tested with Jumbo frames enabled in Linux. It was rather surprising for me as the card worked all right even with older driver versions in our previous review. TRENDnet TEG-PCISXM2 Fiber Gigabit PCI Adapter on Marvell Yukon 88E8010 
 TRENDnet TEG-PCISXM2 Fiber Gigabit PCI Adapter is a gigabit adapter designed for optical transmission. Adapters made for copper or optics (by the same manufacturer) usually have one and the same logic: they are fitted with identical microcontrollers, and the only real difference between the cards is PHY transceivers and the fact that optic adapters don't support 10 and 100 Mbits, they only work in a 1000-Mbit mode. The adapter has two LEDs (indicating link and activity). The card has the following basic characteristics:
 Marvell's Yukon 88E8010 controller is a single-chip solution for a gigabit server card with an integrated PHY controller. It has no embedded transceiver, only interfaces for the external transceiver and the PCI bus. Its characteristics:
 In Windows, we used driver version 6.13.0.0 (released 28.04.2003) from the company's site. The Jumbo frame size can be varied within 1500 and 9000 bytes. B Linux, we used the sk98lin driver version 6.24. The MTU size can be similarly varied within 1500 and 9000 bytes. ZyXEL Omni Lan PCI G1 on ZX1701  ZyXEL GN650-T is a gigabit adapter for a copper twisted pair. The card has 4 LEDs (10/100/1000 Mbits and activity). The card's basic characteristics:
We couldn't find specs for the ZX1701 controller installed on the adapter.  For Windows, we used driver version 1.10 (released 27.08.2003) from the company's site. The driver supports Jumbo frames but like the D-Link adapter, it only allows to enable/disable them. There is no way to know the actual size of the frames and like in the previous case, we'll deem it equal to 3000 bytes. The situation with Linux was much more interesting. Despite the support of the OS announced on the company's site, the core (at least the one version 2.4.24) had nothing that could support ZX1701. The floppy supplied in the package with the card had no Linux driver either. We only managed to find it on the company's Russian site, it was driver version 1.05 released in April, 2003. But that was not the end of the trouble. The driver supports Jumbo frames, and the MTU size can be increased to 9000 bytes. But at the size of 6000 bytes, data transmission halted in all the tests no matter how large the packet being transferred. And even at 1500 and 3000 the driver module could "fall" at any moment not to rise again. The only thing that helped was system reboot:
eth1: Link autonegation speed 1000M bps full duplex
Rhine-GE is AUTO mode
Unable to handle kernel paging request at virtual address 40000128
printing eip:
c0127388
*pde = 0ce7d067
*pte = 0f2b4025
Oops: 0003
CPU: 0
EIP: 0010:[<c0127388>] Not tainted
EFLAGS: 00010206
eax: 40000128 ebx: cd42b480 ecx: 0804a033 edx: 00000039
esi: 0804a033 edi: 00000000 ebp: cdf4b500 esp: ccf85ec4
ds: 0018 es: 0018 ss: 0018
Process ifconfig (pid: 1353, stackpage=ccf85000)
Stack: 000005dc cdea1200 00000287 c010b438 ce812000 d084fc00 d084fc00 000005dc
cdea1200 00000287 00000000 00000018 cd42b480 cdf4b500 00000000 0804a033
c01137b6 cd42b480 cdf4b500 0804a033 00000000 00000000 00000000 ccf84000
Call Trace: [<c010b438>] [<c01137b6>] [<c0111a45>] [<c01cc07d>] [<c010bd8d>]
[<c01c5770>] [<c0147d97>] [<c0113610>] [<c0107194>]
Code: 89 10 56 55 e8 8f 9a fe ff 5a 59 c6 43 2c 01 b8 01 00 00 00
bash-2.05a# shutdown -r now
Broadcast message from root (pts/0) (Tue Jan 20 09:55:20 2004):
The system is going down for reboot NOW!
So, the general impression of this card's work in Linux was negative. At least, it can be said about this particular driver version (considering there was no other at the moment). SysKonnect SK-9844 SK-NET GE-SX Dual Link, Fiber on SysKonnect XaQti XQ11800FP  The whole line of SysKonnect's adapters that we've tested is shipped in identical boxes (one of them is on 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 is designed for optical transmission. You can see the full card and its halves in the photos.   Two links allow to increase twice transmission speed (2Gbit in each direction) or to organise a fault-tolerant link. There will be a whole article devoted to link realisation at 2Gbit on these boards, while fault-tolerance can be analysed with the help of the diagrams above. Link A and link B were connected with optical cables onboard followed by traffic generation. Initially, the whole traffic went via link A. At the ~35th second, cable A breakdown was emulated (the cable was pulled out of the connector). However, data transmission didn't stop: the adapters switched to the other link (B) with switching time of about 300 milliseconds. At the ~55th second link A was restored, and once again, the adapters understood the situation switching the channel to link A. The back panel of SK-9844 Dual Link houses two triples of LEDs (Link, RX, and TX activity, three for each port) and a Status LED nearby port A. The adapter's basic characteristics:
We find it advantageous that so many OSs are supported. The adapter's functional units are allocated on different controllers. The network controller is represented by the XaQti XQ11800FP chip (XaQti is now part of Vitesse Semiconductor), the PHY controller by GigaPHY Am79761, and the controller of the PCI bus by SysKonnect Gigabit Ethernet L5A9338. The adapter has two ports, hence two network controllers and two PHY controllers onboard.   XaQti XQ11800FP's characteristics, in brief:
 The SysKonnect Gigabit Ethernet L5A9338 controller connects the adapter to the PCI interface. It suports standard PCI v2.2 and allows swaps with the system via the 32/64-bit bus at 33/66 MHz. The adapter has 4 Gal Vantech GVT7164 chips of SRAM memory 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. For Windows, we used driver version 4.21 from the company's site. The drivers are shipped with their own graphic interface that ensures a handy control over one or several adapters. The Jumbo frame sizes can be varied within 1514 and 9014 bytes.   The driver's interface is the same for the whole SK98xx series. Only some minor details may differ: for example, the interface will have no mentioning of port B if the adapter is single-ported. And it is easy to organise fault-tolerant connections: you only have to group the respective ports using the mouse. Channel aggregation can be organised in a similar way.   The driver also allows to view the traffic statistics.   Information about temperature and voltage, received from the sensors is monitored here. In Linux, we used the sk98lin driver version 6.24 with sk98lin_2.4.24.patch taken form the company's 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, traffic transmission almost completely stopped at certain packet sizes in the NetPIPE test (it all will be seen in the graphs). 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 with all SysKonnect adapters, and the reason for this is anyone's guess. Although the maximal speed test by means of Chariot showed no deviations. SysKonnect SK-9843 SK-NET GE-SX, Fiber on SysKonnect XaQti XQ11800FP
 SK-9843 SX is virtually identical to SK-9844, except that it has only one port. Circuitries are similar too, the only difference besides the sizes is that SRAMs are made by different manufacturers, although 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, and this holds true of all the following SK98xx adapters we tested.SysKonnect SK-9843 v2.0 SK-NET GE-SX, Fiber on Marvell Yukon 88E8010
 SK-9843 SX v2.0 is a substitute for the previous version of SK-9843. It is based on the Marvell Yukon 88E8010 controller (see the description of TRENDnet TEG-PCISXM2). The card has an optical interface and like the whole SK98xx system, it is supported by a standard SysKonnect driver with its own interface. The card also features two LEDs (link and activity) and has the following characteristics: The adapter's basic characteristics:
The Linux and Windows drivers are identical to the above-mentioned ones of the SK98xx family. The adapter's behaviour in Linux is similar too. SysKonnect SK-9822 SK-NET GE-T Dual Link on SysKonnect XaQti XQ11800FP The SK-9822 SK-NET GE-T Dual Link adapter itself was not tested as we found no pair for it. However, it was used when testing SK-9821 and SK-9821 v2.0 as they had no pair either. SK-9822 SK-NET GE-T Dual Link substituted both of them in the second testbed. Like SK-9844 Dual Link, it is a two-port adapter, which allows to organise fault-tolerant connections and involve channel aggregation. 
 The two photos above show the halves of the adapter. 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 counts that transceivers do not heat that much (and indeed, they were really just a little warm during the work). The adapter also houses a 1-MB memory allocated in 4 chips. The back panel contains two triplets of LEDs (link, TX and RX activity — three for each port) and a Status LED. The adapter's basic characteristics are as folows:
SysKonnect SK-9821 SK-NET GE-T on SysKonnect XaQti XQ11800FP
  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 corroborates the version that the fan installed on one of SK-9822 Dual Link's PHY is just a to-make-assurance-double-sure measure. The card also has a 1-MB SRAM allocated in four chips. The back panel houses a triplet of LEDs with the functions identical to those of SK-9822 Dual Link and a "Status" LED. The characteristics and the drivers used are similar to those of the previous card. It will be reminded that in this particular case, what we tested was not a pair of identical adapters but an SK-9822/SK-9821 liason, although all the readings were taken from SK-9821. SysKonnect SK-9821 v2.0 SK-NET GE-T on Marvell Yukon 88E8010
 SysKonnect SK-9821 v2.0 SK-NET GE-T is based on the Marvell Yukon 88E8010 microcontroller (as well as SK-9843 v2.0). The only difference between the adapters is the transmission environment (twisted pair) and consequently, the circuitry. A 128-KB memory buffer is integrated into the microcontroller. The back panel contains four LEDs, three of which indicate the 10/100/1000-Mbit link, and the fourth one shows data transmission. The characteristics and the drivers used are similar to those of the previous card. As in the case with SK-9821, what we tested was not a pair of identical adapters but an SK-9822/SK-9821 v2.0 liason, although all the readings were taken from SK-9821 v2.0. Navigation:
Evgeniy Zaitsev (eightn@ixbt.com)
12.04.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. |
