SFP+の2.5GbE対応

投稿日 編集日 カテゴリ 、

この記事で実現すること

スイッチングハブのSFP/SFP+ポートは2.5Gbps/5Gbpsに対応していない製品が多いです。元々、10GBase-T/1000Base-Tなどもスイッチに対し無理やり10G Base-SRのように見せかけて動作させており、SFPの世界にはNBase-Tが一般的に存在しません。ビジネス向けスイッチではそもそもの対応がされていない製品も多く、ホームユーザー向けもSFPがあまり一般的ではないことから2.5GbEのサポートは普及していません。しかしながら対応モジュールを組み合わせることで回避することは可能です。

SFP+スイッチの2.5Gbpsサポート

一般的なSFP＋スイッチは1G/10Gのみのインタフェースとなります。また、10GBase-Tモジュールでは「ASF-10G-T」という型番のSFP＋モジュールが一般的に良く知られています。日本のAmazonだと10GTek、ipolexの取り扱いがあります。これは内部のチップにMarvell社の88X3310が使われています。これはNBase-Tに対応したチップが使われており、スイッチ側をオートネゴシエーションにしておくとスイッチ上は10Gと認識していますが、端末側の速度に合わせ2.5G、100Base-TXもリンクアップします。

必ずしも全てのモジュールがオートネゴシエーションでリンクアップするわけではありません。例えば、Broadcomチップで80m対応の省電力モジュール「Cisco SFP-10G-T-80互換」は2.5GbEに対応したスイッチで2.5GbEと認識し正しく通信できますが、オートネゴシエーションモードではリンクアップしません。10GBase-Tで慣れている方はNBase-T対応が当然でもあり、少し違和感があるのでは無いでしょうか。

SFPモジュールの2.5Gbps対応状況について、まずは結論です。

10GBase-Tモジュール メーカー 2.5GbE速度 2.5GbEオートネゴ 発熱
ASF-10G-T ipolex,10GTek × ◯ ◯
Cisco SFP-10G-T-80互換 各社 ◯ × ◯
2.5GBase-Tモジュール FSなど各社 ◯ × ◎
S+RJ10 MikroTik ◯ ◯ ×
Aquantiaモジュール Supermicro,FS ◯ ◯ ◯

スイッチのPortをオートネゴ（10gbps）とし、モジュール側で2.5GbEをサポートする場合の制限は2つあります。1つ目は熱の問題で、2.5Gや100Baseであってもチップ自身は10Gbpsですから、消費電力および発熱量は高くなります。
2つ目は相手を2.5Gbpsと認識しているのはモジュール内部のチップだけであり、スイッチはその事実を全く知らないため、10Gbpsの速度でスイッチからSFP+モジュールに対してデータ送信します。このためSFP+モジュールはキャパオーバーとなり、データバッファが溢れ、データ再送が繰り返される事になります。つまり、一般的によく出回っているASF-10G-T（Marvell社の88X3310チップ）は2.5GbEとしては全く実用的ではありません。

実際に問題となるケースを説明します。クライアントは2.5GBase-Tを持つWindows10で10GBase-TのSFPモジュールを使いSFP＋スイッチにオートネゴモードで接続されています。サーバーはUbuntu20で10GbpsのSFP+DACケーブルで同じスイッチに接続されています。サーバーからデータをダウンロード、アップロードすることを想定し、iperf3を実行します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# クライアントで実行：上り

C:\Users\yoshi>iperf3 -c 192.168.x.181
Connecting to host 192.168.x.181, port 5201
[  4] local 192.168.x.164 port 62653 connected to 192.168.x.181 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   1.00-2.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   2.00-3.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   3.00-4.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   4.00-5.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   5.00-6.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   6.00-7.00   sec   281 MBytes  2.36 Gbits/sec
[  4]   7.00-8.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   8.00-9.00   sec   282 MBytes  2.37 Gbits/sec
[  4]   9.00-10.00  sec   282 MBytes  2.37 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec                  sender
[  4]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec                  receiver

iperf Done.

# クライアントで実行：下り
C:\Users\yoshi>iperf3 -c 192.168.x.181 -R
Connecting to host 192.168.x.181, port 5201
Reverse mode, remote host 192.168.x.181 is sending
[  4] local 192.168.x.164 port 62643 connected to 192.168.x.181 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   184 MBytes  1.54 Gbits/sec
[  4]   1.00-2.00   sec   153 MBytes  1.29 Gbits/sec
[  4]   2.00-3.00   sec   127 MBytes  1.06 Gbits/sec
[  4]   3.00-4.00   sec   121 MBytes  1.02 Gbits/sec
[  4]   4.00-5.00   sec   120 MBytes  1.01 Gbits/sec
[  4]   5.00-6.00   sec   121 MBytes  1.02 Gbits/sec
[  4]   6.00-7.00   sec   123 MBytes  1.03 Gbits/sec
[  4]   7.00-8.00   sec   121 MBytes  1.02 Gbits/sec
[  4]   8.00-9.00   sec   120 MBytes  1.00 Gbits/sec
[  4]   9.00-10.00  sec   119 MBytes  1.00 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.28 GBytes  1.10 Gbits/sec  16710             sender
[  4]   0.00-10.00  sec  1.28 GBytes  1.10 Gbits/sec                  receiver

iperf Done.

Windows（クライアント：2.5Gbps）からUbuntu(サーバー:10Gbps)へのアップロードは2.5Gbps相当の速度が出ていますが、Ubuntu(サーバー:10Gbps)からWindows(クライアント：2.5Gbps)にダウンロードする方向で1Gbps程度の速度に落ち込みます。ubuntuの送信リトライの数が16710と大きな数字になっています。

上記のiperf3の実行結果についてクライアント側でネットワークアナライザのWireSharkを使い、下りデータをキャプチャしたものが以下のグラフです。

まずは、往復遅延時間（Round trip）です。

X軸が時間の経過で10秒間、Y軸が往復遅延時間です。
問題は2つあります。1つ目は1ms（ミリ秒）を超える遅延（青いドット）がいくつか発生しています。2つ目は0ms〜1msの間に青いドットが集約され、青い帯のように見えます。LANの通信で帯に見える場合は数百μs（マイクロ秒）のレイテンシが発生し断続的に遅延が発生しています。レイテンシが小さいなら太い実線程度であり帯のようには見えません。

次に、スループットです。

X軸は時間の経過、Y軸は2つあり、茶色の実線および右の目盛りはスループットを表します。青色の点および左の目盛りは受信したデータ長を表します。
茶色のスループットは最初1.5Gbpsまでは上がり、その後スループットが落ち込んでいきます。グラフ上部の青い水平線はTCPのデータ1460バイトの点がプロットされたものが集まっており、実線に見えます。また、パケットが欠損するとこのように全体に青いドットが散らばり、中途半端なバイト数の受信を示します。

実際のパケットの中身を確認してみます。

IPの末尾181がubuntu、IPの末尾164がWindowsです。No307,309,310と1460バイトのTCPデータが受信されていますが、No311で318バイトを受信しています。ここで恐らくパケットが欠損したと思われます。その次の受信は、No313でシーケンス365001、No314でシーケンス366461を受信しています。受け損ねたと思われるNo311のシーケンスは360621です。(366461-360621)/1460=4とちょうど割り切れるため、サーバー側はTCP1460バイトを連続で送っていたものとみられます。No311で318バイトの残り1142バイトをロストし、次のシーケンス363541も1460バイト全体をロストしたのでしょう。

この後、クライアントは、あくまで自身が欲しいパケットのシーケンスは欠損した360621なのでDup ACKを送出しこれを要求しますが、要求している間にもどんどん次のトラフィックが送信されてきます。最終的には、360621の再送要求がサーバーに届き、サーバーは優先度を上げて360621を再送しますが、それまでに結構なタイムロスがあります。

iperf3など同一LAN内であれば、再送によるレイテンシも小さく済みますが、相手サーバーがInternet経由だとレイテンシが数ミリ秒〜数十ミリ秒あります。このためハイトラフィックテストや大きなファイルのダウンロードは更に落ち込む事になります。私の環境では200Mbpsが精一杯でした。

要約すると以下の通りです。

  • SFP＋スイッチの2.5GbEサポート状況はメーカー次第
  • SFP＋ 10GBase-Tモジュールのいくつかは2.5GbEをサポートするが、対応状況は不明瞭
  • スイッチが2.5GbEに対応しない場合、10GBase-Tモジュールで2.5GbEを認識する場合があるが、片側の速度が1Gbps未満に落ち込むモジュールが大半
  • 2.5GbE接続であっても10GbEチップを使えば発熱量は増える

WireShark
https://www.wireshark.org

FS社のAquantiaチップ特注モジュール

FS社では特にホームページで記載されていないものの、実はAquantiaチップを使ったRJ45 10GbEモジュールを特注で提供してくれます。Aquantiaチップのモジュールは、数年前よりSupermicro社が提供するRJ45モジュールで唯一の2.5GbE/5GbE対応のものと言われていましたが、$200と高価なものでした。

（ラベルは至って普通。でも特注です）

SFP+スイッチでこのモジュールを10GbEオートネゴで使い、上記の2.5Gbpsのテストをやってみたところ、十分な速度が出ました。今回はリトライもありません。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Connecting to host 192.168.x.181, port 5201
Reverse mode, remote host 192.168.x.181 is sending
[  4] local 192.168.x.164 port 54413 connected to 192.168.x.181 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   279 MBytes  2.34 Gbits/sec
[  4]   1.00-2.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   2.00-3.00   sec   283 MBytes  2.38 Gbits/sec
[  4]   3.00-4.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   4.00-5.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   5.00-6.00   sec   283 MBytes  2.38 Gbits/sec
[  4]   6.00-7.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   7.00-8.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   8.00-9.00   sec   283 MBytes  2.37 Gbits/sec
[  4]   9.00-10.00  sec   283 MBytes  2.37 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec    0             sender
[  4]   0.00-10.00  sec  2.76 GBytes  2.37 Gbits/sec                  receiver

iperf Done.

Aquantiaチップの特性でデータロストから耐えられたように見えます。
スループットを見てみましょう。

茶色の実線のスループットは最初の1秒で2Gbpsまで順調に伸びています。1460バイトのTCPデータが連続して受信されている事が青色の実線でわかります。制御のためのデータ送受信もあり、全てが1460バイトにはなりませんが、中途半端なレングスのパケットが点在していません。iperf3の結果だけ見るとすこぶる結果は良好ですが、実際のグラフにしてみるとそれなりに速度の変動は発生しています。

次にRound tripです。

iperf3の開始直後は5msを超える遅延（青いドット）がいくつか発生しています。断続的に1msに近いレイテンシは10秒間の全体を通して発生しています。見た目だけですと最初の「ASF-10G-T」よりも悪くなっているように見えますが、遅延が0に近い場所の青い線の厚みがあることで「ASF-10G-T」よりは遅延の数が少ないと想定されます。何よりスループットは十分な速度が出ていますので許容範囲と考えるべきでしょう。10Gbpsと2.5Gbpsという速度差から発生するギャップがあり、TCP通信の初期段階で通信速度の差をある程度調整することになりますが、一定の数の調整を無くすことはできません。

スイッチのフローコントロール

2.5GbEに対応していないSFP+スイッチであっても、Aquantiaモジュール側の2.5Gbpsの自動認識および速度調整によって上手くいくことが確認できました。それはスイッチのフロー制御によっても支えられています。「フローコントロール」を無効にしてみます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ iperf3 -c 192.168.x.1 -R
Connecting to host 192.168.x.2, port 5201
Reverse mode, remote host 192.168.x.2 is sending
[  5] local 192.168.x.1 port 49780 connected to 192.168.x.2 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   176 MBytes  1.47 Gbits/sec
[  5]   1.00-2.00   sec   172 MBytes  1.45 Gbits/sec
[  5]   2.00-3.00   sec   159 MBytes  1.34 Gbits/sec
[  5]   3.00-4.00   sec   163 MBytes  1.37 Gbits/sec
[  5]   4.00-5.00   sec   170 MBytes  1.42 Gbits/sec
[  5]   5.00-6.00   sec   183 MBytes  1.54 Gbits/sec
[  5]   6.00-7.00   sec   176 MBytes  1.47 Gbits/sec
[  5]   7.00-8.00   sec   183 MBytes  1.53 Gbits/sec
[  5]   8.00-9.00   sec   194 MBytes  1.63 Gbits/sec
[  5]   9.00-10.00  sec   183 MBytes  1.53 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.73 GBytes  1.48 Gbits/sec  13430             sender
[  5]   0.00-10.00  sec  1.72 GBytes  1.48 Gbits/sec                  receiver

iperf Done.

汎用モジュールの「ASF-10G-T」ほど数字は落ち込みませんが、AquantiaチップのSFP＋モジュールでも2.5Gbpsのレートは出ません。こちらはRetrの数字が大きいことから、スイッチのフロー制御が無いまま、TCPの世界でリトライが多発しているように見えます。これはスイッチによっても差がでます。

スイッチのフローコントロールは、送信側にPauseフレームをマルチキャスト送信し、送信側を一時停止させます。システムの速度差が問題を引き起こすため、何らかの理由でスイッチのバッファが溢れそうになる時にはスイッチのフローコントロールによってネットワーク全体が安定的に動作します。ここまでの検証で、Aquantiaチップは十分なバッファを持っていることである程度は大量のトラフィックに耐えますが、バッファが溢れそうになった段階でスイッチに限界を通知し、スイッチにPauseフレーム送信を促すことにより通信が安定するものとみられます。

FSでのAquantia　10GbE SFP＋モジュール（RJ45）の指定方法

これはFS社から教わりましたが、注文時に備考欄に Aquantia方案と記載して欲しいとのこと。この指定が無ければMarvellチップのモジュールになります。受注生産とのことで納品まで1か月程度掛かりますが、これはホームユーザーにとって強い味方になると思われます。

2.5GbE SFP＋モジュール（RJ45）

スイッチが2.5GbEに対応しているなら、日本ではあまり見かけない2.5Gbase-Tモジュールが利用できる可能性があります。これはスイッチの対応状況に依存するため、事前にモジュールメーカーへ問い合わせが必須となります。スイッチのパフォーマンスを最大限活かせること、10GbEのチップほど温度が上がらないメリットがあります。モジュール自体の価格も10GBase-Tのものよりは安価です。

モジュールの温度

モジュールの温度に関して具体的な数値の記録は以下の通りです。

前回記事「10GネットワークとSFP+」と同様にモジュールの表面に金属センサーを接触させ計測しています。

  • ファンレススイッチでオートネゴによる10Gbpsと2.5Gbpsでのリンクアップの違い
10GBase-Tモジュール 速度 温度
ASF-10G-T 2.5Gbps 46℃
Aquantia10Gモジュール 2.5Gbps 45℃
ASF-10G-T 10Gbps 49.4℃
Aquantia10Gモジュール 10Gbps 49.5℃
（室温29℃）

Marvell、Aquantiaのモジュールは温度に関して違いは見られません。そういえば、Aquantiaは3年前にMarvellに買収されましたね。今となってはMarvell、Aquantiaという名前で比較するにはふさわしく無いのかもしれません。

  • ファン付きスイッチで2.5GbEチップと10GbEチップ（2.5Gbpsオートネゴ接続）との比較
モジュール(2.5Gbpsで接続) 温度
Cisco SFP-10G-T-80互換 37.7℃
Aquantia 10Gモジュール 38℃
Marvell 2.5Gモジュール 35.8℃
（室温31℃）

Cisco SFP-10G-T-80互換のBroadcomチップは低発熱で使いやすいモジュールですが、やはり2.5Gbps専用チップに軍配が上がります。

補足

2.5Gbps対応スイッチとオートネゴのASF-10G-Tとの遅延を比較したグラフのスケールを拡大して比較したものを載せておきます。上記ではレイテンシの幅について「帯」という表現をしましたが、拡大してみるとレイテンシの状況にはかなりの違いが見られます。

左：2.5Gbpsモジュール（フローコントロール無し）
右：ASF-10G-T（2.5GbEオートネゴシエーション）

0.5秒前後を切り取っただけであり、どちらのモジュールも1msを超える大きな遅延はあります。順調なケースと問題を抱えているケースとしての比較です。左はかなり良い状態を切り取っています。どのモジュールでも数百μsの遅延は定期的に発生します。しかし帯と表現した右側のグラフでは、300μsを超えるレイテンシが継続して発生しており、何らかの問題を抱えていることがわかります。
遅延だけでなく、スループットを併せて見ることで遅延は無いが送る量が少ないケースも見極める必要があります。

iperf3の出力結果だけでもある程度の状況は把握できますが、WireSharkで厳密にスループットのグラフや往復遅延時間を確認し、スイッチやモジュールの能力を見極められます。