2018年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      

最近のトラックバック

ダメ人間友の会

無料ブログはココログ

« EFiXの開発元のArt Studio Entertainment Media、EFiX USA LLCとの取引を停止 | トップページ | EFiXの購入先と価格について(1/24時点まとめ) »

2009年1月23日 (金)

WindowsとMacOS XでのGigabit環境におけるsmbファイル転送速度差について(その2)

EFiXなPCでは、Windows VistaとMacOS X Leopardとのデュアルブート環境であるため、同一のハードウェア環境で、ファイル転送速度の差を測定できると言うことで、NASからEFiXなPCへのファイル転送速度を測定した話しの続きその2です。

その1で、3つのテストパターンで、それぞれ、Windows VistaとMacOS X Leopardで、同一のファイルを受信する際に掛かる時間を測定した結果を見てましたが、単純な受信に掛かった時間の数字以外について、気になったことなど。

いくつか、特筆すべき事項としては、MacOS X LeopardでのMTU値の設定は、どちらかと言うと、"Jumboフレーム設定"項目と言うより"帯域制御設定"の項目のような振る舞いをします。これは、EFiXなMacOS X Leopardでのファイル転送中、アクティビティモニタでネットワークのスループットを監視していましたが、その監視結果から導き出した感想です。

MacOS X Leopardでは、Ethernet設定の項目が自動の場合、この場合、システムプロファイラのネットワーク環境では、MTU値1500、フロー制御なしに見えますが、ネットワークの波形が、酷くギザギザで受信しているパケットの落差が大きく、1秒間に、最大瞬間風速で17MB程度の受信時もあれば、100KB程度の受信時もあります。

Jumboframe07MTUを"Jumbo(9000)"を選択すると、この場合、システムプロファイラのネットワーク環境では、MTU値6126に見えますが、ネットワークの波形が、一定の線を描き、ファイルの受信が開始されてから完了するまで、ほぼ、MTUの設定値通り、1秒間に6MB弱の受信サイズ数をずーっと推移します。

Jumboframe08んで、"全二重(フロー制御)"を選択したら、むしろ帯域を制御してくれる思ったら、こちらの項目の効果は、このテストではあまり発揮されませんでした。フロー制御の効果としては、スイッチングHUBや各送受信機器で、パケットを転送する際に利用するバッファの空き容量等を見ながら、送信するパケット量を制御するのですが、"全二重(フロー制御)"を設定してみたものの、アクティビティモニタで見たネットワークの波形は、ギザギザのままでした。・゚・(ノ∀`)・゚・。

それから、MacOS X LeopardでMTUの設定をカスタム設定する際、MTUの設定値を直接入力(72~9000の間の数字)するか、プルダウンから"Jumbo(9000)"を選択することができるんだけど、何度やっても、最終的にネットワーク設定の変更を適用すると、常にMTUの数値が6126になります。これは、ネットワークのEthernetの項目上でもそうだし、システムプロファイラ上でも同じ数値となります。

なぜ、システムプロファイラと画面上の項目で、両方を見るかと言うと、MacBook Airを購入した際に、無線LANのスループットがかなり悪いのを解消しようと、MTUをいじってみようと思ったら、/Library/Preferences/SystemConfiguration/preferences.plistを直接いじらないと変更できなかった経緯があるため、両方でチェックしています・・・あとは、ターミナル上からifconfig等でも確認すればいいかな?

ひとまず、NASからのWindows VistaないしMacOS X Leopardへのファイル転送速度の差は、それぞれのOS上で動作しているLANドライバーの差、また、ファイルシステムがWindows VistaとMacOS X Leopardで、当然違うため、それらのファイルシステム上で書き込みを行う際のオーバーヘッドがそれぞれ違うあたりでしょうか。

Jumboframe09結局のところ、smb接続では、Windows Vistaのほうが、断然早かったと言う結果になりました(もちろん「うちのLAN環境で」の話しですが)。MacOS X同士のafp、Bonjour同士で、やはり同じファイルサイズで試して見る等のテストパターンは、今回のテストパターンと同じハードウェア構成を作れないことから比較が難しそうなんで、行っていませんが、もしかすると結果が結構変わってきそうですねぇ。

あと、今回のテストでは、MTUのサイズをデフォルトか、最大か、の両極端でしか行っていないのと、RWINもいじっていません。実際、MTUやRWINの設定値は、もう少し調整をすることで、もっとスループットが伸びる可能性もあります。

この辺は、送信側、受信側、また、それを中継するスイッチングHUB等のメモリバッファの量や、それぞれのパケット処理において利用されるCPU等の性能よって、変わってくるハズです。

また、小さなサイズのファイルを大量に送信した場合等は、また、今回のテスト結果とは、変わる可能性もあるので、そのへんは、まだまだ色々試してみないと分かりませんが、少なくともGigabit環境において、WindowsとMac共に、ネットワーク周りの設定をデフォルトのままで、利用するより、少しいじってみることで、若干のスループットの向上を見込むことができるという結論になりました(´∀`)

あぁ、もちろん、設定次第によっては、スループットが劇的に落ちることもあるってコトですよ?・・・(;´∀`)






おすすめ平均:
もうすぐマイナーアップデート
powerd by Amazon360

« EFiXの開発元のArt Studio Entertainment Media、EFiX USA LLCとの取引を停止 | トップページ | EFiXの購入先と価格について(1/24時点まとめ) »

EFiX」カテゴリの記事

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

« EFiXの開発元のArt Studio Entertainment Media、EFiX USA LLCとの取引を停止 | トップページ | EFiXの購入先と価格について(1/24時点まとめ) »

Advertisement


  • カスタム検索

Analyze

  • blogram投票ボタン