Testing Gigabit Network Adapters on platform TYAN Trinity GC-SL.
Part Two: 64bit PCI Interface
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:
- 3Com 3C996B-T Gigabit Server Adapter on a Broadcom BCM5701 chip.
- CNet ProG2000L Gigabit Ethernet Card on a Realtek RTL8169 chip.
- Hardlink HA-64G Gigabit Ethernet Adapter on an Altima AC1001
chip.
- TRENDnet TEG-PCITX2 Gigabit PCI Adapter on a DP83820BVUW chip.
- TRENDnet TEG-PCISXM2 Fiber Gigabit PCI Adapter on a Marvell Yukon
88E8010 chip.
- ZyXEL Omni Lan PCI G1 on a ZX1701 chip.
- SysKonnect SK-9844 SK-NET GE-SX Dual Link, Fiber on a SysKonnect
XaQti XQ11800FP chip.
- SysKonnect SK-9843 SK-NET GE-SX, Fiber on a SysKonnect XaQti
XQ11800FP chip.
- SysKonnect SK-9843 v2.0 SK-NET GE-SX, Fiber on a Marvell Yukon
88E8010 chip.
- SysKonnect SK-9822 SK-NET GE-T Dual Link on a SysKonnect XaQti
XQ11800FP chip.
- SysKonnect SK-9821 SK-NET GE-T on a SysKonnect XaQti XQ11800FP
chip.
- SysKonnect SK-9821 v2.0 SK-NET GE-T on a Marvell Yukon 88E8010
chip.
- Intel 82545EM Gigabit Ethernet Controller, embedded into the TYAN
Trinity GC-SL mainboard (64bit PCI interface).
- Intel 82547EI Gigabit Ethernet Controller, embedded into the
Intel D875PBZ mainboard (CSA interface).
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:
- Platform: Tyan Trinity GC-SL (S2707) (or Intel D875PBZ, when
testing adapters on a CSA bus);
- CPUs: Pentium 4 2.0GHz and 3.0GHz;
- Memory: 512Mb and 1024Mb registered DDR;
- HDD: Maxtor 20GB (IDE, 5400RPM)
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 Methods
Windows 2000
The 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:
- 1514 bytes (no Jumbo-frames)
- 3014 bytes
- 6014 bytes
- 9014 bytes
- 16128 bytes
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:
- Maximum packet size is 1514 bytes (no Jumbo frames)
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize = ffff
Iperf startup parameters:
client: iperf -c 10.0.0.1 -M 100000 -w 64K -l 24K
server: iperf -s -m -M 100000 -w 64K -l 24K
NTttcp startup parameters:
transmitter: ntttcps -m 1,0,10.0.0.2 -a 4 256K -n 10000
receiver: ntttcpr -m 1,0,10.0.0.1 -a 4 -l 256K -n 10000
Chariot startup parameters:
test duration is 3 minutes, generator script parameters:
We used the supplied High Performance Throughput script.
- Packet size 3014, 6014, 9014 and 16128 bytes (Jumbo Frames
enabled)
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters
TcpWindowSize = 20971520 (20 Mb)
Tcp1323Opts = 3
Iperf startup parameters:
client: iperf -c 10.0.0.1 -M 100000 -w 1M -l 24K
server: iperf -s -m -M 100000 -w 1M -l 24K
NTttcp startup parameters:
transmitter: ntttcps -m 1,0,10.0.0.2 -a 4 256K -n 10000
receiver: ntttcpr -m 1,0,10.0.0.1 -a 4 -l 256K -rb 20000000 -n 10000
Script parameters for Chariot are the same.
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.4
For 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
/sbin/ifconfig eth0 down
/sbin/ifconfig eth0 MTU $mtu_size up
The following MTU sizes were set for the tests:
- 1500 bytes (no Jumbo frames)
- 3000 bytes
- 6000 bytes
- 9000 bytes
- 16000 bytes
netPIPE startup parameters:
receiver: NTtcp -b 65535 -o logfile -P -r
transmitter: NTtcp -b 65535 -o logfile -P -t
Chariot was run with the same parameters as in Windows 2000.
List of network adapters
Intel 82545EM Gigabit Ethernet Controller
This 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
- supports a 32/64bit PCI bus v2.2 at 33/66 MHz and a PCI-X bus at
133 MHz
- 64 KB FIDO IO buffers
- transfers up to 64 packet descriptors at a single operation,
which allows optimal usage of the PCI bus throughput
- Host Offloading: hardware segmentation of TCP traffic,
hardware checksum estimation for IP, TCP and UDP frames
- supports Jumbo frames up to 16 KB
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
and packet filterin for up to 4096 simultaneous VLANs
- Interrupt moderation controls: Interrupt moderation controls:
algorithms for reducing the number of interrupts generated by receive
and transmit operations.
- supports SNMP and RMON counters
- ASF 1.0 support (Alert Specification Forum)
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:
- CSA support with theoretical bandwidth of 266Mbytes/sec and
direct connect to the MCH of Intel® 875 chipset
- 40 KB FIDO buffers for IO operations
- Host Offloading: Transmit TCP segmentation IP, TCP, and UDP
checksum off-loading capabilities on RX and TX
- Jumbo frame support up to 16KB
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
and packet filtering for up to 64 simultaneous VLANs
- Interrupt moderation controls: algorithms for reducing the
number of interrupts generated by receive and transmit operations
- supports SNMP and RMON counters
- ASF 1.0 and 2.0 (Alert Specification Forum)
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T;
- VLAN Support: YES;
- Connector: RJ-45;
- Interfaces: 32-/64-bit, 33/66 MHz PCI; 32-/64-bit, 33/66/100/133
MHz PCI-X;
- Drivers: Linux 2.2, 2.4, 2.6; Windows XP, 2000, NT 4.0; Novell
NetWare 6.x, 5.x, 4.2; UnixWare 7; OpenServer 5; Sun Solaris X86;
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:
- supports 3.3/5 Volts 32/64bit PCI bus v2.2 at 33/66 MHz and a
32/64bit PCI-X bus v1.0 at 33/66/100/133 MHz
- 10/100/1000BASE-T speeds in half and full duplex modes
- 96 KB deep packet buffer memory
- two RISC processors with a cache size of 16 KB for an extended
packet classification
- TCP/UDP/IP checksum offloads
- TCP segmentation offloads
- algorithms to reduce interrupts to the CPU
(transferring several packets at a single interrupt)
- supports a PXE 2.0 compatible Boot ROM
- supports ASF 1.0 (Alert Specification Forum)
(remote control capabilities for OS-absent network adapters)
- supports ACPI-compliant Wake on LAN
- SNMP MIB II (802.3x) interface to collect statistics
- ACPI 1.1a compliance
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
for up to 64 simultaneous VLANs
- supports IEEE 802.1P Layer 2 Priority Encoding (up to four
priority levels)
- external EEPROM support
- Jumbo frame support up to 9KB
- 802.3x compliant flow control
- supports link aggregation, link trunking (802.3ad),
bidirectional load balancing
(irregardless of switches and their manufacturers (e.g. Fast
EtherChannel and Gigabit EtherChannel Support))
- integrated software interface that allows cable analysis: length
and quality of the line, polarity and order of cable pairs.
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T
- VLAN support: YES
- Connector: RJ-45
- Interfaces: 32-/64-bit, 33/66 MHz PCI v2.2
- Drivers: Windows XP, 2000, NT, ME, 98; Linux; Mac OSX;
RTL8169
controller from Realtek possesses the following features:
- Integrated 10/100/1000 transmitter
- Supports PCI rev.2.3, 32-bit, 33/66MHz
- Autodetects cable types
- Supports Wake-on-LAN
- Supports Microsoft NDIS5 Checksum Offload (IP, TCP, UDP) and
largesend offload
- Supports IEEE 802.1P Layer 2 Priority Encoding
- Supports IEEE 802.1Q VLAN tagging
- TX and RX FIFO size - 8K/64K
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T
- VLAN support: YES
- Connector: RJ-45
- Interfaces: PCI Rev.2.1 64bit, 66MHz
- Drivers: Windows 98/Me/NT/2000: NDIS 4/5; NetWare Server: Ver.
4.x, 5.x; Unix/Linux
AC1001 microcontroller is a 10/100/1000Base-T Ethernet controller
with an embedded transceiver. Key features:
- supports 32/64bit PCI v2.2 at 33/66 MHz
- 10/100/1000BASE-T speeds in half and full-duplex modes
- flow control in full-duplex mode
- ACPI compliant Wake on LAN support
- 48 KB on-chip packet buffer
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
for up to 64 VLAN tags
- supports IEEE 802.1P Layer 2 Priority Encoding (up to four
priority levels)
- SNMP MIB II interface (802.3x) for statistics gathering
- supports PXE compatible Boot ROM
- external EEPROM support
- Jumbo frames support
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T
- VLAN support: unknown
- Connector: RJ-45
- Interfaces: 32/64-bit 33/66MHz PCI Rev.2.1/2.2
- Drivers: Windows 98/Me/2000/NT4/XP, Linux, Novell Netware Server
5.x
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:
- supports 32/64bit PCI bus v2.2 at 33/66 MHz
- 10/100/1000BASE-T speeds in half and full-duplex modes
- 96 KB on-chip packet buffer
- IP, TCP, and UDP checksum (IPv.4 frames) off-loading
capabilities
- on-chip 8 KB TX and 32 KB RX packet FIFO;
- supports Flash/PROM interfaces for remote loading
- serial EEPROM support (as external memory to load configuration
at startup)
- SNMP MIB II and Ether-Link MIB (RFC. 1398) interfaces to gather
statistics
- ACPI 1.0 compliance
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
VLAN tags
- 802.3x flow control
- supports 802.1D and 802.1Q Priority Encoding (QoS)
- Jumbo frames support
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:
- Standard: IEEE 802.3z 1000Base-SX
- VLAN support: unknown
- Connector: SC Type for 50/125µ and 62.5/125µ
- Interfaces: 32/64-bit PCI Rev.2.2
- Drivers: Windows 98SE/ME/NT4/2000/XP Linux Kernel 2.4.x or later;
Netware 5.x. 6x
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:
- supports 32/64bit PCI bus v2.2 at 33/66 MHz
- 10/100/1000BASE-T speeds in half and full-duplex modes
- 128 KB on-chip packet buffer
- TCP/IP and UDP checksum off-loading capabilities on RX and TX
- Jumbo frame support
- IEEE 802.1Q VLAN support with VLAN tag insertion and stripping
for up to 64 simultaneous VLANs
- Marvell VCT technology for extended cable diagnostics
- software shipped with 88E8010 allows to create IEEE 802.3ad Link
Aggregation and Link Failover
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T
- VLAN support: YES
- Connector: RJ-45
- Interfaces: 32/64-bit 33/66MHz PCI Rev.2.1.2.2
- Drivers: Windows 98/ME/2000/XP, Novell NetWare Client 32/Server
4.x/5.x, RedHat Linux 6.x/7.x;
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
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!
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:
- Standard: IEEE 802.3z 1000Base-SX
- VLAN support: YES
- Connector: SC Type for 50/125µ and 62.5/125µ
- Interfaces: 64bit/66MHz and 32bit/33MHz, 3.3 or 5V PCI rev2.1,
2.2
- Drivers: Novell NetWare 4.11, 5.x and 6 (LAN driver); Windows
98 SE/ME/ NT 4.0/Windows 2000/2003 Server (x86,Intel 64Bit and AMD
64Bit)/XP; AIX v4.3.3/ 5.1; SUN Solaris 2.5.1, 2.6, 7, 8 and 9 (x86,
SPARC, SPARC 64-bit); Linux 2.2, 2.4, 2.6 (Open Source available),
Linux 2.4 for Itanium (OpenSource available); Free BSD (x86 and Alpha;
3rd party); HP-UX 11
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:
- two independent FIFO buffers on a 32bit bus (4 KB TX and 8KB RX)
- supports copper and optical communication medium (1000BASE-SX,
1000BASE-CX, 1000BASE-LX)
- SNMP and RMON monitoring support
- TCP/IP and UDP checksum off-loading capabilities
- Jumbo frame support
- supports IEEE 802.3ad Link Aggregation and Link Failover (with
drivers)
- supports 802.1q VLAN Tagging
- supports 802.3ac Frame Extensions for VLAN Tagging
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:
- Standard: IEEE 802.3z 1000Base-SX
- VLAN support: YES
- Connector: SC Type for 50/125µ and 62.5/125µ
- Interfaces: 64bit/66MHz and 32bit/33MHz, 3.3 or 5V PCI rev2.1,
2.2.
- Drivers: Novell NetWare 4.11, 5.x and 6 (LAN driver); Windows
98 SE/ME/ NT 4.0/Windows 2000/2003 Server (x86,Intel 64Bit and AMD
64Bit)/XP; AIX v4.3.3/ 5.1; SUN Solaris 2.5.1, 2.6, 7, 8 and 9 (x86,
SPARC, SPARC 64-bit); Linux 2.2, 2.4, 2.6 (Open Source available),
Linux 2.4 for Itanium (OpenSource available); Free BSD (x86 and Alpha;
3rd party); HP-UX 11
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:
- Standards: 10BASE-T/100BASE-TX/1000BASE-T
- VLAN support: unknown
- Connector: RJ-45
- Interfaces: 32/64-bit PCI Rev.2.2
- Drivers: Novell NetWare 4.11, 5.x and 6 (LAN driver); Windows
98 SE/ME/ NT 4.0/Windows 2000/2003 Server (x86,Intel 64Bit and AMD
64Bit)/XP; AIX v4.3.3/ 5.1; SUN Solaris 2.5.1, 2.6, 7, 8 and 9 (x86,
SPARC, SPARC 64-bit); Linux 2.2, 2.4, 2.6 (Open Source available),
Linux 2.4 for Itanium (OpenSource available); Free BSD (x86 and Alpha;
3rd party); HP-UX 11
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:
