CodingBox Q&A Ask question

MCX516A-CCATの100G DACメッシュでlshwは40Gbit/sと表示、iperf3のシングルストリームは21Gbit/s止まり

Asked Active Viewed 49 AI translation from English
2

3ノードクラスタを組んでいて、ノード同士は100G DACで直結、経路にスイッチは挟まず、レプリケーション用のトラフィックが専用ファブリックを持てるようにインターフェースをブロードキャストボンドにしています。本番の負荷をかける前にベースラインを取りたかったのですが、数字同士が一致しません。

  • Mellanox ConnectX-5 EN x3、MCX516A-CCAT、デュアルポートQSFP28
  • ノードの各ペア間に100G DACを1本
  • AMD EPYCホスト、3台ともProxmox

ethtoolはまったく問題なしです:

# ethtool ens1
Settings for ens1:
        Supported link modes:   100000baseCR4/Full
        Advertised link modes:  100000baseCR4/Full
        Speed: 100000Mb/s
        Duplex: Full
        Link detected: yes

lshwはそうではありません:

# lshw -class network
  *-network
       description: Ethernet interface
       vendor: Mellanox Technologies
       capacity: 40Gbit/s

iperf3で2ノード間を測ると21Gbit/s前後で、どちらの数字にも近くありません。

すでに試したこと:

  • 両方のカードで2番目のポートにケーブルを挿し替えても変化なし
  • 同型の別のDACに交換しても変化なし
  • リンクはずっとアップしたままでカウンタのエラーも増えない

この2つのツールのどちらが嘘をついているのでしょうか、そして疑うべきはケーブルなのかカードなのかドライバなのか?

Comments 5

Accepted answer

投稿された内容からはDACを疑う材料は何もありません。ここでは無関係な現象が2つ起きています。

1つ目は数字の食い違いです。lshw -class networkは自分なりに算出したケーパシティの値を表示するだけで、このカードでは100Gでリンクが上がっていても平気でcapacity: 40Gbit/sと表示します。実際にネゴシエートされた速度を示すのはethtoolのほうで、あなたの出力では100000baseCR4/Fullがアドバタイズされた上でSpeed: 100000Mb/sとなっています。こちらは正常で、直す必要はありません。

2つ目はスループットです。他を触る前にまずスロットを確認してください:

# lspci -vv
        LnkCap: ... Speed 8GT/s ...
        LnkSta: ... Speed 2.5GT/s ... (downgraded)

LnkCapが8GT/sなのにLnkStaが2.5GT/sでトレーニングしているなら、配線の速度よりかなり低いところで頭打ちになっていて、ケーブルをいくら交換しても改善しません。カードを挿し直して、実際にフル幅で配線されたスロットに入っているか確認してください。

それから、シングルストリームでの計測はやめてください:

# iperf3 -P 8 -c <peer>

21Gbit/s前後というのは、このクラスのホストでコア1つが出せる程度の値なので、その数字単体ではほとんど何も分かりません。実行中のCPUも見て、アイドルステートが何をしているかも確認してください。バーストの合間に深いC-stateへ落ちるコアがあると、この速度域では実質的な帯域が削られます。

3 Taiwanlinkeng56TW Show original (English) AI translation

何か注文する前に、そのカードのlspci -vvからLnkStaの行と、実際に使ったiperf3のコマンドラインをそのまま貼ってください。100GでのシングルストリームはリンクではなくCPUコア1つを測っているだけで、これで何日も無駄にする人がいます。あと、テスト中に2番目のポートがアイドルではなく本当にメッシュのもう一方の経路を運んでいるか確認してください。1つのスロットから2つの100Gポートを同時に動かすのと1つだけ動かすのとでは、必要な帯域が違います。lshwは今は脇に置いておいたほうがいいです、この問題を見るためのツールではありません。

3 United Arab Emirateslambdahawk88AE Show original (English) AI translation

C-stateの話には1つ訂正があります。ホストがEPYCなら、この手のスレッドに毎回貼られるintel_idle関連の設定は何の効果もありません、そのドライバはAMDでは経路にすら入っていないからです。自分の環境で効いたのはカーネルコマンドラインのprocessor.max_cstate=2でした。考え方は同じで、プラットフォームが違うだけです。それ以外の内容はそのままで問題ありません、特にlshwからネゴシエート済みの速度を読み取らない、という点は。

2 SpainoptictechES Show original (English) AI translation

少し違う種類の不具合ですが、同じ系統のハードウェアなので、スロットの問題を片付けたらこれも切り分けておく価値があります。ConnectX-5のQSFP28ポートを直結メッシュにすると、レイヤ3で間違えるのが非常によくあります。私のところでは3ノードがMCX516A-CCA_Ax、ファームウェア16.35.4030でDOCA 2.8.0ドライバ、配線はMCP1600-C003E30Lの3m銅DACでした。すべてのリンクが100Gbpsでアクティブと報告されるのに、pingが1つも通りませんでした。メッシュの6つのインターフェース全部が、経路上にスイッチが一切ないまま単一の10.5.5.xサブネットのアドレスを持っていたので、カーネルには宛先がどの物理ポートに属するのか判断する手段がありませんでした。ノードのペアごとに10.5.5.x、10.5.6.x、10.5.7.xとサブネットを分けたら動き始めました。誰かが銅線を疑う前に、3台全部でip aとip routeを実行しておく価値があります。

1 Ukrainerxnode71UA Show original (English) AI translation

両方とも的中でした。lspci -vvを見るとLnkCapが8GT/sなのにカードは2.5GT/sでトレーニングしていて、これが最有力候補でした。3台全部でカードを別のスロットに挿し替えたらLnkStaが8GT/sで上がるようになり、iperf3 -P 8にしたら同じノードペアで即座にシングルストリームの数字を超えました。

ブロードキャストボンドは諦めて、Open vSwitchとRSTPでメッシュを組み直しました。3つのCPUスレッドと両方のポートにiperfを分散させると、今は95Gbit/s前後まで出ていて、このクラスタの用途としてはライン速度に十分近いです。lshwは相変わらず40Gbit/sだと言い張っていますが、もう気にしていません。

1 United Kingdomcoaxpilot98GB Show original (English) AI translation
Log in to comment. Log in