web-dev-qa-db-ja.com

1GBitカードの出力が80MiBに制限されているのはなぜですか？

1GiBネットワークカードが提供する最大帯域幅を利用しようとしていますが、常に80MiB（実際のメガバイト）に制限されています。理由は何ですか？カードの説明（lshw出力）：

   description: Ethernet interface
    product: DGE-530T Gigabit Ethernet Adapter (rev 11)
    vendor: D-Link System Inc
    physical id: 0
    bus info: pci@0000:03:00.0
    logical name: eth1
    version: 11
    serial: 00:22:b0:68:70:41
    size: 1GB/s
    capacity: 1GB/s
    width: 32 bits
    clock: 66MHz
    capabilities: pm vpd bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation

カードは次のPCIスロットに配置されます。

*-pci:2
     description: PCI bridge
     product: 82801 PCI Bridge
     vendor: Intel Corporation
     physical id: 1e
     bus info: pci@0000:00:1e.0
     version: 92
     width: 32 bits
     clock: 33MHz
     capabilities: pci subtractive_decode bus_master cap_list

PCIはPCIExpressではありませんか？レガシーPCIスロットですか？だから多分これが理由ですか？

OSはLinuxです。

linuxnetworkingethernetgigabit-ethernet
5
ctinnist

80MB /秒は実際にはかなり良いです！これは約640mbpsで、NICのギガビット容量にかなり近い値です。 TCPIPのオーバーヘッドとディスク速度を考慮すると、おそらく最大速度になっています。

38
Russ Warren

これを/etc/sysctl.confに入れてみてください

_# General 10gigabit/LFP tuning
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_max_orphans=1048576
net.ipv4.tcp_Orphan_retries=2

# Removes some internal buffering
net.ipv4.tcp_low_latency=1

# Time-wait sockets
# Do not turn on unless you know what you are doing!
#net.ipv4.tcp_tw_recycle=1
#net.ipv4.tcp_tw_reuse=1

# If PMTUD ICMP blackhole appears use
# RFC 4821, Packetization Layer Path MTU Discovery
net.ipv4.tcp_mtu_probing=1

# Netfilter's conntrack
# NB! For high-performance concerns you probably don't want to use `--state` rules at all 
#net.ipv4.netfilter.ip_conntrack_max=1048576
#net.nf_conntrack_max=1048576

# SACKs are an optimization to TCP which in normal scenarios improves considerably performance. 
# In Gigabit networks with no traffic competition these have the opposite effect. 
# To improve performance they should be turned off with: 
#net.ipv4.tcp_sack=0 

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout=15
# Decrease the time default value for tcp_keepalive_time connection
net.ipv4.tcp_keepalive_time=1800

# Increased backlog (default: 100/1000 depending on kernel)
net.core.netdev_max_backlog=10000
net.core.somaxconn=10000

# Timestamps adds additional 12 bytes to header and uses CPU
# NB! It caused massive problems for me under benchmark load
# with a high count of concurrent connections.
# ( http://redmine.lighttpd.net/wiki/1/Docs:Performance )
#net.ipv4.tcp_timestamps=0

# Portrange for outgoing connections
# (increase the ephemeral port range)
# NB! After that tuning you probably do not want to listen on port >= 1024
net.ipv4.ip_local_port_range=1024 65535

# Fixing 'Too many open files', Second useful on nginx+aio workloads
fs.file-max=16777216
fs.aio-max-nr=65536

# If you are under DDoS you can
kernel.panic=10
# Lower following values
#net.ipv4.tcp_synack_retries=2
#net.ipv4.tcp_syn_retries=2
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=15
#net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=15
# If you under ping flood
#net.ipv4.icmp_echo_ignore_all=1
_

接続するたびにエフェメラルポートが必要になるため、ファイル記述子が必要になります。デフォルトでは、これは1024に制限されています。開いているファイルが多すぎるという問題を回避するには、シェルのulimitを変更する必要があります。これは_/etc/security/limits.conf_で変更できますが、ログアウト/ログインが必要です。今のところ、sudoを実行して、現在のシェルを変更できます（rootとして実行したくない場合は、ulimitを呼び出した後、非特権ユーザーに戻ります）。

_ulimit -n 999999
_

TCPスループットの向上に役立つ可能性のあるもう1つの方法は、インターフェイスキューのサイズを増やすことです。これを行うには、次の手順を実行します。

_ifconfig eth0 txqueuelen 1000
_

輻輳制御で遊ぶことができます：

_sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control=htcp
_

いくつかの低レベルの調整もあります。カーネルモジュールパラメータ

_# /sbin/modinfo e1000
..snip...
parm:           TxDescriptors:Number of transmit descriptors (array of int)
parm:           TxDescPower:Binary exponential size (2^X) of each transmit descriptor (array of int)
parm:           RxDescriptors:Number of receive descriptors (array of int)
parm:           Speed:Speed setting (array of int)
parm:           Duplex:Duplex setting (array of int)
parm:           AutoNeg:Advertised auto-negotiation setting (array of int)
parm:           FlowControl:Flow Control setting (array of int)
parm:           XsumRX:Disable or enable Receive Checksum offload (array of int)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive 
_

また、ethtool(1)を介してアクセスできるさらに低いレベルのハードウェアチューニング。

PS。カーネルのドキュメント、特に Documentation/network /scaling.txt を読む

PPS。チューニング中にTCPパフォーマンスについて相談することをお勧めします RFC6349

PPPS。D-Linkは最高のネットワークハードウェアではありません。 pci-xまたはpci-64でIntelハードウェアを試してください

21
SaveTheRbtz

32ビットの33MhzPCIバスは、最大1,067メガビット/秒（Mbps）または133.33メガバイト/秒（MBps）を通過できます。

ギガビットイーサネットは、116メガバイト/秒（MBps）を伝送できます。

したがって、カードを使用してもshould回線を完全に飽和させることができますが、さまざまなオーバーヘッドがあるため、実際には約90％の使用率しか得られません。

いずれにせよ、毎秒80メガバイト（MBps）を取得している場合は、それほど遠くはありません。今のところ、それでかなり満足しています。

8
Chopper3

ギガビットイーサネットは10億をわずかに超えていますビット 1秒あたり。 8/10エンコーディングでは、これにより最大で1秒あたり約100MBが得られます。 32ビットPCIバスは133MB /秒を通過できるはずであり、それを飽和させることができるはずです（ファイバーチャネルカードでPCIバスの飽和を示し、バスの理論上の帯域幅に近い数値を得ることができます）、したがって、他のバストラフィックがない限り、ボトルネックの原因になる可能性はほとんどありません。

バスで帯域幅を使用している別のカードがない限り、ボトルネックはおそらく別の場所にあります。

2
ConcernedOfTunbridgeWells

GigE速度のボトルネックは、さまざまな場所から発生する可能性があります。

  • ディスクサブシステム：GigEの速度に到達するには、ある種のRAIDアレイに少なくとも3〜4台のハードドライブが必要です。これは、送信側と受信側に当てはまります。
  • CPU：GigEは、あなたが思っているよりもはるかに多くのCPUを使用できます。それが33MHzのPCIスロットにあることを考えると、私はここで手足に出て、このシステムはかなり古く、CPUが遅いかもしれないと言います。
  • TCP/IPオーバーヘッド：ネットワークを介して送信される一部のビットは、データペイロードではなく、他のオーバーヘッドビットです。これは、単一のGigEリンクで115MB/sを一貫してヒットおよび維持するシステムを持っていることを示しています。
  • PCIバス：NICそのPCIバス上の唯一のものですか、それとも別のデバイスと共有されていますか。
  • その他の要因：他の要因が多すぎてすべてを説明することはできませんが、最大の要因のいくつかは、他のディスクIOアクティビティが発生していることです。読み取り/書き込みの混合、多くの小さな= IOリクエストなど.
1
3dinfluence

私の経験では、80 MiB/sはかなり良いです。 NICとスイッチの組み合わせに関係なく、これほど高速になることはありません。 100Mbpsがほぼ同じ動作を示したことを覚えています。最近では、ギガビット機器が100 Mbpsモードで90％を超えて実行されているのを目にしますが、70〜80％の使用率で十分です。

比較すると、SMCスイッチとbroadcom統合NICに基づく自宅での最初のギガビット構成では、400 Mbpsをほとんど管理できませんでした。数年後、IntelおよびMarlinNICと一緒にNetgear管理スイッチを使用しました。通常、70〜80 MiB/sの持続転送の範囲にいることに気づきます。

さらに必要な場合は、複数のインターフェイスを結合することを検討してください。

0
Roy

私の長期にわたる研究の後、私は結論を投稿します：

  1. プロセスアフィニティとNIC irqアフィニティを修正して等しくする必要があります。irqbalanceプロセス（Linux）を停止する必要があります。
  2. カードはPCIeモードで実行されている必要があります。 x4。 PCIeスロットがこのモードをサポートしていない場合、カードはx1モードで実行され、ボトルネックが発生します。
0
ctinnist

ボトルネックになっているのはカードであると確信していますか？それは、相手側のデバイスとネゴシエートできる最高速度である可能性があるため、待機状態になります。他のデバイスは10/100の速度で実行されたままになる可能性があるため、80は少しオーバーヘッドがあり、ほぼ適切です。

0
Shial

スイッチの端を確認できれば、非常に良い速度が得られます

http://www.Cisco.com/en/US/tech/tk389/tk213/technologies_configuration_example09186a0080094470.shtml

0
Rajat