ASIX AX88772 USB ethernet adapter performance

I’ve always been skeptical of USB ethernet adapters. An old 10Mb adapter I have in my junk box can barely do 1Mb. I have in my hands a D-Link DUB-E100 adapter. It’s supposed to be able to do 100Mb. I was really expecting to expose the sham that is 100Mbit USB Ethernet adapters. Fortunately, I was very wrong and this device works perfectly. There was no appreciable increase in CPU usage in any scenario. Using mpstat, the %irq column essentially stayed at zero for all tests while using the D-Link.


$ lsusb | grep D-Link
Bus 001 Device 016: ID 2001:3c05 D-Link Corp. [hex] DUB-E100 Fast Ethernet [asix]
$ dmesg | grep eth2
[22867.448692] eth2: register 'asix' at usb-0000:00:1d.7-4, ASIX AX88772 USB 2.0 Ethernet

Server

  • Athlon X2 3600
  • Ubuntu 10.04 (2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010 i686)
  • Digital DS21142/43 Tulip rev 65 PCI 10/100Mb NIC (this thing is ancient)

Client 1

  • Thinkpad T43 (Pentium M 1.86GHz)
  • Ubuntu 10.04 (2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010 i686)
  • Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11) – tg3 driver

Client 2

  • Dell Mini10v (Atom 1.6GHz)
  • Ubuntu 10.10 (2.6.35-22-generic #35-Ubuntu SMP Sat Oct 16 20:36:48 UTC 2010 i686)
  • Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller (rev 02)

The network is flat. Just a simple Cisco 2950 and latency is about what you’d expect:


$ ping 172.16.8.45
PING 172.16.8.45 (172.16.8.45) 56(84) bytes of data.
64 bytes from 172.16.8.45: icmp_seq=1 ttl=64 time=0.178 ms
64 bytes from 172.16.8.45: icmp_seq=2 ttl=64 time=0.164 ms
64 bytes from 172.16.8.45: icmp_seq=3 ttl=64 time=0.163 ms
64 bytes from 172.16.8.45: icmp_seq=4 ttl=64 time=0.175 ms
^C
--- 172.16.8.45 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.163/0.170/0.178/0.006 ms

For all the tests, I’m using iperf version 2.0.4-5 from the Ubuntu repository. I’m not specifying window size since latency is very low. The result in each case is an average of five tests.

Server to Client 1 w/onboard Broadcom 10/100/1000
There was no averaging to do here. Iperf consistently reports 94.9Mbit.

$ iperf -c 172.16.8.45
------------------------------------------------------------
Client connecting to 172.16.8.45, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.8.4 port 41071 connected with 172.16.8.45 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 114 MBytes 94.9 Mbits/sec

Client 1 w/Broadcom to Server
With this scenario I got almost identical results.

Server to Client 1 w/D-Link
Latency is about 100 microseconds higher.

$ ping 172.16.8.32
PING 172.16.8.32 (172.16.8.32) 56(84) bytes of data.
64 bytes from 172.16.8.32: icmp_seq=1 ttl=64 time=0.333 ms
64 bytes from 172.16.8.32: icmp_seq=2 ttl=64 time=0.209 ms
64 bytes from 172.16.8.32: icmp_seq=3 ttl=64 time=0.249 ms
64 bytes from 172.16.8.32: icmp_seq=4 ttl=64 time=0.234 ms
64 bytes from 172.16.8.32: icmp_seq=5 ttl=64 time=0.278 ms
^C
--- 172.16.8.32 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.209/0.260/0.333/0.046 ms

Here’s the surprise. It can actually do 100Mb.

$ iperf -c 172.16.8.32
------------------------------------------------------------
Client connecting to 172.16.8.32, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.16.8.4 port 44384 connected with 172.16.8.32 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 114 MBytes 94.9 Mbits/sec

The reverse direction using Client 1 to send with the D-Link is slightly slower at 94.6Mbits/sec

Server to Client 2 w/Realtek
Latency:

$ ping 172.16.8.24
PING 172.16.8.24 (172.16.8.24) 56(84) bytes of data.
64 bytes from 172.16.8.24: icmp_seq=1 ttl=64 time=0.201 ms
64 bytes from 172.16.8.24: icmp_seq=2 ttl=64 time=0.185 ms
64 bytes from 172.16.8.24: icmp_seq=3 ttl=64 time=0.190 ms
64 bytes from 172.16.8.24: icmp_seq=4 ttl=64 time=0.181 ms
64 bytes from 172.16.8.24: icmp_seq=5 ttl=64 time=0.188 ms
^C
--- 172.16.8.24 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3996ms
rtt min/avg/max/mdev = 0.181/0.189/0.201/0.006 ms

Iperf:

[ 3] 0.0-10.0 sec 113 MBytes 94.8 Mbits/sec

Server to Client 2 w/D-Link
Latency:

$ ping 172.16.8.32
PING 172.16.8.32 (172.16.8.32) 56(84) bytes of data.
64 bytes from 172.16.8.32: icmp_seq=1 ttl=64 time=0.426 ms
64 bytes from 172.16.8.32: icmp_seq=2 ttl=64 time=0.316 ms
64 bytes from 172.16.8.32: icmp_seq=3 ttl=64 time=0.343 ms
64 bytes from 172.16.8.32: icmp_seq=4 ttl=64 time=0.461 ms
64 bytes from 172.16.8.32: icmp_seq=5 ttl=64 time=0.363 ms
^C
--- 172.16.8.32 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3996ms
rtt min/avg/max/mdev = 0.316/0.381/0.461/0.059 ms

Iperf:

[ 3] 0.0-10.0 sec 113 MBytes 94.9 Mbits/sec

Client 2 w/D-Link to Server
Iperf:

[ 4] 0.0-10.1 sec 113 MBytes 93.9 Mbits/sec

Conclusion
It works!