登 大遊@筑波大学大学院コンピュータサイエンス専攻の SoftEther VPN 日記 このページをアンテナに追加 RSSフィード

Daiyuu Nobori's SoftEther VPN Diary since 2004

登の Web サイト: http://dnobori.cs.tsukuba.ac.jp/

mixi : http://mixi.jp/show_friend.pl?id=672294
Twitter : http://twitter.com/dnobori/
Facebook: http://www.facebook.com/dnobori

日記などへのリンク集
IKeJI さん | Cedar さん | Mayaqua さん | thisjun さん
bakueikozo さん | mugen さん | 分散計算の神林君 | 榮樂先生 (hdk) | 吉田戦車 (ceekz) | 高木先生 | ron さん
AC の古澤さん | AC の TAKAO 君 | AC の NIES 君 | AC の古橋君 | AC な wakatono さん | AC のいのひろ君
AC な三戸君 | AC な柴田君 | AC の小野君 | AC すぎる松本君 | AC な小西君 | AC な google の及川さん | AC な tomocha さん
まつもとゆきひろ氏 | 板野先生の blog | 新城先生の最近の fj への投稿 | つくばあさひなあんてな | hatena 筑波大学 AC リング

日記でよく出てくる「AC」(もともとは筑波大学用語) について詳しくは ここここ をお読みください。

 | 

2008年10月16日 (木)

実験! L2 スイッチは実用上、何個までカスケード接続可能か?  実験! L2 スイッチは実用上、何個までカスケード接続可能か?を含むブックマーク  実験! L2 スイッチは実用上、何個までカスケード接続可能か?のブックマークコメント

スイッチング HUB ではない従来の HUB (いわゆるダム HUB) は、100Base-TX では 2 段までしかカスケード接続できないという制約があるのは有名だと思います。


最近ダム HUB を使うことはほとんど無くなってきています。100Base-TX でも通常はスイッチング HUB が安価ですのでそれを使いますし (100Base-TX 用のダム HUB は見かけなくなってしまいました)、1000Base-T では規格上は CSMA/CD は残っていますが、事実上ダム HUB の実装はなく (たぶん)、ほぼ例外なく L2 スイッチを使用して LAN を組むと思います。

さて、それではいわゆる「スイッチング HUB」 (L2 スイッチ) は何段までカスケード接続することができるのでしょうか?

これについて、「何段カスケード接続すれば通信できなくなるのか?」という意味での回答は、「無制限」が正解かと思います。ダム HUB やリピータと違い、スイッチング HUB は原理上無限に多段カスケード接続することができます。

しかし、実際には、色々な解説書には「スイッチング HUB も数個カスケード接続をすることにより遅延が生じてしまうので、実用上は、カスケード接続は数段程度が上限」 などといったことが書かれている場合もあります。


確かに、LAN 内で遅延が数 msec 〜数十 msec も発生してしまうと、色々な LAN 上のアプリケーションの動作がもたつくなど、支障が出たりする可能性もあります。そういうことを避ける意味で、いくつかの解説書には、「スイッチング HUB を多段にカスケードすると遅延が発生し実用的でない」という解説がされているのかと思います。


それでは実際に何個くらいの L2 スイッチング HUB をカスケード接続すれば、何 msec 程度の遅延が発生するのでしょうか?

そういう実験は、昔からやってみたいと思っていましたが、わざわざたくさんの L2 スイッチを用意してカスケード接続して試してみるのは手間がかかります。また機種やメーカーによって結果が異なるかも知れません。数十個の L2 スイッチング HUB をカスケード接続すれば、何 msec 程度の遅延が発生するのか? という疑問は、高校生のころから持っていた疑問でした。L2 スイッチの仕様を調べて計算することはできるかも知れませんが、それは正確でないかも知れません。いつか実際に実験してみたいと思っていました。


そこで本日思い立って実験してみることにしました。 インテリジェント L2 スイッチとして、Catalyst 2970 を 1 台、Catalyst 3550 を 2 台、Summit 5i を 1 台、Summit 7i を 2 台、BS-G2016MR を 3 台、用意しました。また、普通の L2 スイッチ (ノンインテリジェントのもの) を 2 台用意しました。

インテリジェントスイッチは、ポート 1 とポート 2 を VLAN 1、ポート 3 とポート 4 を VLAN 2、…… というように設定し、次にポート 2 とポート 3、ポート 4 と ポート 5、…… を LAN ケーブルですべて物理的に接続することにより、1 台のンテリジェントスイッチで直列に多数回、1000Base-T のパケット受信・スイッチング・送信動作が発生するようにしました。

これにより、合計で 74 台分のスイッチング HUB を直列にカスケードした場合とほぼ同等の環境 を作ることができました。一応、記念写真を撮っておきました。大量の LAN ケーブル (75 本) が溢れるように乱雑に刺さっており、今にも抜けそうな具合ですが、実験であるためまあ大丈夫かと思います。


f:id:softether:20081017022346j:image f:id:softether:20081017022345j:image


そして実際に、ある程度精密 (0.01msec 単位の精度) で、74 台分のポートを直列に超える形で遅延を測定してみたところ、おおよそ 0.55msec 程度でした。

すなわち、1 台のスイッチング HUB を多段カスケード接続することにより、約 0.008msec 程度の遅延 が発生するようです。

なお、もちろん上記環境でスループット計測したところ、0.97Gbps 程出ていました。


n 台のスイッチング HUB を多段カスケード接続する場合の遅延 = n × 0.008msec 程度

というのがだいたい成り立つということでしょうか。試しに上記の実験セットの途中部分で遅延を測ってみたりしましたが、どの機種でもほとんど同等程度の遅延時間のようでしたので、上記の式はおおよそ正しいのではないかと思います。


結論として、たとえば RTT (往復時間) が 1.0msec 以下である必要がある場合、ポート数の少ない安物の L2 スイッチで多段カスケード接続する場合のスイッチの直列合計台数は 60 台程度が妥当で、60 台程度を超えると 1.0msec 以上の RTT が生じてしまうということになります。ということは、通常は 60 台も L2 スイッチ をカスケード接続する事態は考えられない訳ですので、だいたい通常の範囲であれば、安物の L2 スイッチをたくさんカスケード接続して端末数を増やすという場合、それにより発生する遅延は問題にならないと考えることができるのではないかと思います。(もちろんできれば端末数が多い場合は、故障率の低下や、局所的にトラフィックが集中した場合におけるボトルネックのできにくさ等の要因から、ポート数が多い高級な L2 スイッチ等を使用するほうが良いと言えると思います。)


以上、ネットワークをやっている人であれば恐らく誰でも思いつくような、あまり役に立たないかも知れない疑問を、実際に実験してみて確かめた結果でした。

arisaarisa 2008/10/17 10:46 1000MHzのクロックで動作していると仮定すると、8clockのレイテンシか・・・

ヒャマモトヒャマモト 2008/10/17 14:56 >写真
http://gigazine.net/index.php?/news/comments/20080819_crazy_wiring/
これを想起させる・・・w

 2008/10/19 13:14 いつもお世話になってます
ところで公式落ちてないですか?繋がらないのでよかったら確認お願いします

yachyach 2008/10/20 23:31 フレーム長を短くすれば、もう少し遅延が短くなると思います。

mmasudammasuda 2008/10/21 21:50 昔はねスイッチといってもワイヤースピードが出ないものがあってね(遠い目。

 2008/11/12 00:14 8000クロックだと思います。

とおりすがりとおりすがり 2012/04/19 16:15 物理的なASICの通過とTCAMの参照が75段おこなわれているわけではないので,正確な実験とは言えないですね.もっとレイテンシは高くなることが予想できます.

定年退職間近のおばちゃん定年退職間近のおばちゃん 2013/07/12 09:42 いや〜、参考になりました。ありがたい。
そしてもし自分が同じ環境にいたら、ぜったい実験してみただろうなあと思いました。こういうの大好き。ミーハーな意見でごめんなさいね。

 | 

<< 2008/10 >>
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




※ この Web サイトのコンテンツは 登 大遊 が個人的に運営しているものであり、ソフトイーサ株式会社や筑波大学内での立場として公式なコメントを掲載しているものではありません。一応コメントは投稿できるようにしていますが、個人的に運営している日記のため、自分が不快に思ったコメントは前触れ無く削除しております。ご了承ください。同様に会社に関するコメントなどについても、削除される可能性があります。コメント書き込み機能については、匿名の掲示板のような状態になることを予防するため、はてなユーザーからのみ受け付けるように設定することもあります。