390 likes | 512 Views
10Gbit Ethernet の 性能評価に関する論文調査. 九州大学 システム情報科学府 情報知能工学専攻 岡村研究室 修士1年 林 健太朗. 目次. 背景 発表者の研究 準備 データの分割 Window Size 文献1の紹介 文献2の紹介 文献3の紹介 発表者の今後の研究. 背景. LAN :イーサネット ( コストが安い、扱いやすい、信頼性は低い ) WAN : SONET/SDH, ATM ( コストが高い、扱いにくい、信頼性は高い ). 以前. LAN :イーサネット (100Mbps,1Gbps)
E N D
10Gbit Ethernetの性能評価に関する論文調査 九州大学 システム情報科学府 情報知能工学専攻 岡村研究室 修士1年 林 健太朗
目次 • 背景 • 発表者の研究 • 準備 • データの分割 • Window Size • 文献1の紹介 • 文献2の紹介 • 文献3の紹介 • 発表者の今後の研究
背景 LAN:イーサネット (コストが安い、扱いやすい、信頼性は低い) WAN:SONET/SDH, ATM(コストが高い、扱いにくい、信頼性は高い) 以前 LAN:イーサネット(100Mbps,1Gbps) WAN:SONET/SDH, イーサネット(10Gbps, 1Gbps) 現在 この移行により、今までのネットワークでは経験しなかったような未知の問題の発生が考えられる 10GbEthernet(10GbE)の登場によりワイドエリアネットワーク(WAN)においても、イーサネットが用いられるようになってきた。
発表者の研究 発表者はフューチャーインターネットに関する研究を行っている 大容量のデータを、いままでに存在しなかった高速な通信路で送信した場合、どのような問題が起こるのか、それをどのように解決できるか、ということを研究している 将来の高速な通信路のひとつとして10Gbit Ethernetの性能評価に関する文献を3つ紹介する
準備:データの分割 データ TCPによりMSSごとに分割 TCPヘッダ20byte付加 MSS MSS TCP20 MSS TCP20 MSS 下位層のイーサネットに合わせて1480byteごとに分割 IPヘッダ20byte付加 1480 1480 1480 1480 1480 1480 IP20 1480 IP20 1480 IP20 1480 eth14 1500 eth4 eth14 1500 eth4 イーサネットヘッダ14byte、フッター4byte付加 大きなデータを送信するときそのデータは各プロトコルにより分割される
準備:データの分割 データ MSS MSS TCP20 MSS IP20 15980 eth14 16000 eth4 • Maximum Transmission Unit (MTU) • データリンク層の最大ペイロードサイズ • イーサネット標準:1500byte • 拡張ジャンボフレーム:8000~16000byteで可変 • 拡張ジャンボフレーム • イーサネットを拡張し、より大きなデータを格納できるようにしたもの。通信路上のすべての機器が対応していなければならない。
準備:Window Size • TCP通信では複数のパケットを同時に送信する。その総データサイズをWindow Sizeとよぶ。 1パケットの最大容量はMTU Round Trip Time (RTT) Segment 1度に送信するデータサイズをWindow Sizeとよぶ。 (MTU×1度に送信するパケット数) ACK
準備:Window Size • 送信したデータは再送などの処理のために保持しておく必要がある。そのためのバッファをウィンドウバッファと呼ぶ。 理論上Window Sizeの最大値はRTT×帯域であるためウィンドウバッファもそれだけ必要となる Segment 受信側でも同じサイズのバッファが必要 ACK
文献1の紹介 タイトル:“Performance evaluation of TCP/IP in pseudo network environment” 著者:Makoto Nakamura, Junji Tamatsukuri, Yutaka Sugawara, Mary Inaba, Kei Hiraki, 概要:疑似ネットワーク環境上で、3種類の10GbEネットワークアダプタについてTCP/IP通信の性能評価実験を行い、それぞれの環境で10GbEの性能を最大限引き出す方法を求めた論文
10Gbpsの通信における未知の問題 • CPU処理の増加 • 1秒間に80万パケットを送受信(MTU 1500byte) • 受信割り込みが1秒間に80万回発生し、CPUを占有してしまう恐れがある • メモリ領域の占有 • 500msの遅延があり帯域が10Gbpsの場合 • 理論上 0.5s*10Gbps/8bit = 625Mbyte のウィンドウバッファが必要になる
CPU処理の軽減技術 アイドル時 受信時 カーネル カーネル ①定期的に監視 ②たまったデータを受信処理 ②受信処理 ①受信割り込み 受信割り込み ネットワークアダプタ ネットワークアダプタ • NAPI(New API) • アイドル時は通常通り受信割り込み許可 • 受信を開始すると受信割り込みを禁止し、ポーリングによる受信に切り替える • ポーリング:一定時間間隔ごとにデータがないか確認する方法 • アダプタのバッファに受信データがなくなると受信割り込みを許可しアイドル状態に戻る
CPU処理の軽減技術 • 本来CPUが行う処理を、ハードウェア上で行う機能をもつネットワークアダプタが市販されている • TSO(TCP Segment Offloading)機能 • TCPパケットの分割処理やヘッダ付加などの一部の処理をアダプタ上で行う機能 • TOE(TCP Offloading Engine)機能 • TCP/IP層のすべての処理をアダプタ上で行う機能
目的 10GbEでは頻繁な割り込み処理のため、送受信処理がままならないと考えられる。そのため高いスループットを得られないのではないか。 疑似ネットワーク環境におけるTCP/IPの通信実験により、CPU処理削減機能の効果や、10GbEの性能を最大限引き出す方法を明確にする。
実験の構成 • 3種類のネットワークアダプタ • Chelsio製 T110 Protocol Engine • TOE機能を持ったアダプタ。TOEを使用しない場合も実験した。 • Chelsio製 N110Server Adapter • TCP/IPを支援するようなハードウェアを持たない • Intel製 PRO/10GbE SR Server Adapter • TSO機能とNAPI機能を持つ。 • 実験は遅延発生装置を介した、同システムのホストによる1:1通信で行う
結果:TOE使用時 図1:TOE使用時の転送速度 (MTU1500byte, RTT 400ms) • Window Size • RTT 0ms – 1Mbyte • RTT 100ms – 94Mbyte • RTT 200ms – 190Mbyte • RTT 300ms – 285Mbyte • RTT 400ms – 375Mbyte • 開始から20秒までの間、スループットが得られていない。アダプタが処理中で受信できないという振る舞いをしているため、TOE機能のACKパケットの受信動作に問題があると考えられる
結果:ソフトウェアに取る場合 表1: Intel PRO/10GbEはChelsioのアダプタよりも低いスループットであった。TSOの使用は如何は結果に影響しなかったので、アダプタ自体にボトルネックがあると考えられる。
結果:ソフトウェアによる場合 図2:ピークバンド幅(RTT 400ms) Chelsio製の2つのアダプタは似た振る舞いをし、MTU1500byteでは安定して動作しなかった ジャンボフレームでは高いスループットを得られた デバイスドライバにより1秒間の割り込み回数を指定できる(最大2万回)機能を持つ
性能評価 ウィンドウサイズは理論値の少なくとも2.5倍以上必要であった 遅延の大小により割り込み回数の変化はなかった 受信割り込み軽減技術により、割り込みによる通信性能への影響はなかった 実験の結果、適切なウィンドウサイズ、ユーザバッファを用いて通信することで最大7.2Gbpsの通信をすることが可能であると分かった
文献2の紹介 タイトル:“End-to-End Performance of 10-Gigabit Ethernet on Commodity Systems” 著者:Justin (Gus) Hurwitz, Wu-chun Feng, 概要:遅延が小さい環境において、コンピュータアーキテクチャーの観点からTCP/IP通信の性能評価を行った論文
背景と目的 WANにおいて10GbEの移行が進んでいるが、今後遅延が小さいようなLANにおいても普及することが考えられる。 この論文では何も手を加えていない環境から少しずつ最適化を行い、システムに依存しない最適化方法を考えていく。 遅延が小さい場合での、どのような環境でも10GbEの性能を引き出せる事を示す
テスト環境 図3:ネットワーク図 • Dell PowerEdge 2650 (PE2650) • CPU: Xeon 2.2GHz 400MHz-FSB • メモリ:1Gbyte • 133MHz-PCI-Xバス • CPU帯域幅25.6Gbps、メモリ帯域幅25.6Gbps、ネットワーク帯域幅8.5Gbps
結果:基準 これ以降、この結果を基準に最適化を進める 6272byteー7436byteー8948byteにおいて山谷がある 次に、カーネルをSMP(Symmetric MultiProcessor)非対応のものに変更する
結果:最適化1 どちらのMTUサイズにおいてもおよそ20%のスループット向上がみられる 次に、Window Sizeを64kbyteから256に変更する
結果:最適化2 山谷が消え平均スループットは1500byteのMTUでは7%、9000byteのMTUでは31%向上している 最後にMTUサイズを8160byteと16000byteに変更する
結果:最適化3 Linuxではメモリのブロックサイズを2倍ごとに確保する(ex:32, 64 ・・・8192, 16384byte) 9000byteのデータは16384byteの領域に書き込まれるため、メモリの読み書き時、余計に処理をかけてしまう 8160byteのMTUでは8192byteの領域に書き込まれるため効率がよい
さらなる最適化 • これまでの最適化手法はすべてのシステムにおいて適用可能な方法である • さらなる最適化はシステムによって異なる。システムが変わればスループットは当然変わってくる • 2.0GHz AMD Opteron 246の場合 • MTU-9000byte 6.0Gbps • MTU-16000byte 7.3Gbps • 手を加えていないIntel Itanium2 • MTU-9000byte 5.14Gbps • MTU-16000byte 6.0Gbps
スループットの考察 図4:受信時の振る舞い • ボトルネックの候補は図4よりネットワークアダプタ、PCI-Xバス、メモリバス、FSB、CPUの五つ • 考察の結果、特定の箇所の問題ではなく、パケット受信時の非効率なメモリ読み込み手順こそが原因であると結論づけている。 初めの実験で、スループットのピークが4.11Gbpsであった原因の考察
SFNについての考察 • Short Fat Network(SFN) • 遅延が小さく帯域が広い • Long Fat Network(LFN) • 遅延が大きく帯域が広い、研究が盛ん • SFN固有の問題というものも存在する • 本論文ではSFNにおいて大きなMTUと小さなWindowSizeを使ったとき問題が起きることを示し、その解決法も示した。 • 今後SFNはさらに小さな遅延、さらに大きな帯域、さらに大きなMTUになるであろう
文献3の紹介 タイトル:“Native 10 Gigabit Ethernet experiments over long distances” 著者:Catalin Meirosu, Piotr Golonka, Andreas Hirstius, Stefan Stancu, Bob Dobinson, Erik Radius, Antony Antony, Freek Dijkstra, 概要:10GbEをWANに用いることができるか、実環境で実験を行いその評価を行った論文である
背景と目的 10GbEはLANに向けてだけではなくWANにも用いられるように開発された 現在WANにおいての普及が進んでいるが、10GbEのWANへの適用は本当に有効なのだろうか 実環境で実験を行うことにより、10GbEをWANに用いる有効性を明らかにする
10Gbit Ethernet • 10GbEはLAN向けの規格とWAN向けの規格に分かれている • LAN PHY 10.3125Gbps • WAN PHY 9.95328Gbps • WAN PHY は SONET/SDH のOC-192に直接接続できる • WANPHYの帯域がやや小さいのはSONET/SDHとの接続性のためである • SONET/SDH OC-192 9.95328Gbps
実験項目 • DWDM機器との接続性のテスト • DWDM(Dense Wavelength Division Multiplexing) • 波長の異なる光は互いに干渉しないという性質を利用することで、光ファイバーを多重利用する方式 • OC-192との接続性のテスト • スループットの測定
実験の構成 DWDMとの接続性テスト環境 OC-192との接続性テスト環境 スループット測定のための環境
結果:シングルTCPストリーム 図5:シングルTCPストリームのスループット MTUとWindow Sizeを様々に変えて実験を行った 通信性能を引き出すには、ジャンボフレームを用いる必要があることが分かる
結果:マルチTCPストリーム 図6:マルチTCPストリームのスループット ストリームの数はスループットに影響しない つまり1ストリームあたりのオーバーヘッドが小さいと言える
まとめ 実環境のWAN上において10GbEの接続性、およびTCP通信の評価実験を行った。 DWDMとの接続性、OC-192との接続性を確認できた TCP通信において5.4Gbps以上のスループットを得られた マルチストリームの実験によりストリームの数はスループットに影響しないことが分かった。
発表者の今後の研究 今回の論文調査により10GbEを用いるときは、適切なWindow Size・ユーザバッファの設定、またはカーネル・ネットワークアダプタなどを考慮しなければ、10GbEが持つ性能を引き出せないことが分かった。 今後の研究のなかで、10GbEに限らず、帯域の測定実験を行うときや、ネットワークの評価を行う際などには参考にしたい