安物LANカード

テスト１とテスト２はサーバが同じでクライアントだけ変えてあります．
なので，両者の結果の差はクライアントの差と言うことになります．
ハードウェアのスペック的にはこんな感じ（↓）

クライアント＠テスト１ ＞ サーバ＠テスト１
クライアント＠テスト１ ＞ サーバ＠テスト２

なので，クライアント＠テスト１のスペックが低すぎてテスト１の結果が
悪くなっているのではありません．従って，テスト１の結果が悪いのは
クライアント側ソフトウェアの問題と言うことになりそうです．
と言うわけで，

結論１: 高価な NIC も厨房 OS ではその真価を発揮しない．
（漢なら Solaris/*BSD を使え！）

ちなみにこの結論は，参考値とも矛盾しません．

テスト２の結果を見てみると，AN983 は安物のくせに 82557 と比べて
一歩も引けを取らない性能を出しているのがわかります．

結論２: AN983 は案外高性能だ．

テスト３の結果を見てみると，クライアント側の NIC に関わらず put に
関して悪い結果が出ています．これはクライアント側のソフトウェア
（OpenBSD の ftp クライアントの put の実装）に問題がありそうです．
テスト３の get の値は，上記の結論に矛盾しません．

OpenBSD 3.0 は AN983 をあっさりと認識し，そのまま何の問題もなく動い
ています．しかしドライバのソース（if_dc_pci.c）を少し眺めてみると，
ベンダー/デバイス・コードを見て処理を分岐しさせている個所がいくつか
見つかります．このことから DEC 互換をうたっている AN983 も，ドライ
バによる作りこみが必要であることがわかります．使用する OS がこの NIC
をサポートしているか，事前に調べる必要があると思われます．

注意点１: ドライバが AN983 をサポートするか，事前に調べておく必要がある．
（ソースも見ずに「動かねー」とか「はまりまくり−」とか言ってるばかは
放置すること）

暗号化を伴う通信（https/ssh/ipsec など）を行う際，CPU の負荷は非常
に高くなります．これを行う際には，なるべく CPU の負荷を上げない NIC
を選択すべきでしょう．今回，CPU への負荷に関してはデータを取ってい
ません．しかし AN983 は基本的には DEC chip と同様の動きなので，CPU
への負荷は低いはずです．
＃が，データが無い以上断定的なことはいえません