none
Windows7でネットワーク経由でファイル転送すると、時間がかかります。 RRS feed

  • 質問

  • はじめまして。タイトルの通りですが、ファイルをコピーするのに時間がかかり、解決方法が見つからないため、質問します。

    【機器構成】
    メインPC--->Windows7 Professional 32bit/Core 2 quad 2.66GHz/8GB RAM/1Gbit LAN NVIDAドライバ
    サーバーPC--->Windows7 Professional 64bit/Core 2 quad 2.66GHz/8GB RAM/1Gbit LAN Microsoftドライバ
    ノートPC--->WindowsXP Professional 32bit/AtomN270 1.6GHz/2GB RAM/300Mbit WLAN Coregaドライバ


    【具体的手順】

    メインPCからサーバーPCへ複数ファイルをコピーする際、1個目をコピーしてから、次のファイルをコピーするまでに、20~30秒ほどかかります。これはファイルの転送が終わり(ハブのアクセスランプの点滅が終わってから)次のファイルの転送が始まるまでの時間です。1個のファイル転送にこれだけの時間がかかるため、100個程度ファイルを転送するのに30 分~1時間はかかってしまいます。ノートPCからサーバーPCへ転送する際は、ここまで時間はかからず、すいすい転送は進みます(単純にLANの速度分の時間がかかる)。転送が止まっている間、ネットワークに対してのアクセスに障害があり、ネットワークドライブへアクセス(プロパティ表示やフォルダ表示など)ができなかったり、インターネットができなくなったりします。なお、メインPCのドライバをMicrosoft版にして実験すると、総転送量がおおむね2GBを超えたあたりから、この現象が発生することがわかりました(送信が約2GB、受信は200MB程度でした。NVIDIA版は試してません)。

    サーバーPCのドライバがNVIDIA版でないのは、どう言ったわけか、NVIDIA版だと1Gbitで接続ができず、100Mbit以下になってしまうためです。

    何か良い改善方法はないでしょうか?よろしくお願いします。

     

    2010年12月12日 13:32

すべての返信

  • NICのTCP オフロード機能の相性問題で、よく似た状況になったことがあります。
    #NVIDIAさんのNICではありませんでしたが……

    もったいない気もしますが、無効化して状況が変わるかどうかを確認するのはいかがでしょうか。
    TCPオフロードとかTCP Chimneyなどで検索するとどんな内容かが出てきます。

    「TCP/IPタスクオフロード機能-NVIDIA Gigabit Ethernet The Performance Leader(英語)」
    http://www.nvidia.co.jp/object/IO_8451.html

    2010年12月13日 3:05
  • Chukiさん、返信ありがとうございます。

     

    早速試してみましたが、状況は全く変わりませんでした。その他、設定できる項目の有効/無効も切り替えてみましたが、結局の所、いくつかファイルを転送すると、途中で待機時間が発生しました。場合によっては約20MB転送したところで、止まってしまい、困った状況が発生します。

     

    2010年12月14日 13:34
  • 念のためのご確認ですが、設定を変えると状況が悪化する場合もあるということですので、やはりドライバがらみではないかと愚考いたします。
    各ドライバは最新のものでしょうか?

    あとは、途中経路(スイッチとかルータなど)の相性問題くらいしか思い浮かびません><

    お役に立てなくて申し訳ございませんでしたm(_ _)m

     

     

    2010年12月15日 14:05
  • Chukiさん、返信ありがとうございます。

    メインパソコンのハードウェア構成はWindowsXP時代とは全く変わらず、OSのみの変更です。ドライバーはNVIDIAのホームページで公開されている最新版とWindows7に収録されているもののどちらかを利用しています。ハードの構成が変わっていないので、私もドライバー関係の相性かな?ともおもいますが。確認ですが、コマンドは『netsh int tcp set global chimney=disabled 』で良いかと思いますが、いかがでしょうか?なお、ドライバーの設定ですが、変更をしても特に動作が変わることはないようです。

     

    2010年12月15日 14:51
  • >『netsh int tcp set global chimney=disabled 』

    OS側の設定はその通りです^^

    >その他、設定できる項目の有効/無効も切り替えてみましたが

    これは、XP時代に「ネットワーク接続」のコントロールパネルから見られた各接続のプロパティの「詳細設定」からドライバの設定を変えたということでしょうか。
    私がよく似た障害にぶつかったときは、念のためOS側とドライバ側の両方の支援機能をかたっぱしから止めました。(例:オフロードと名乗るような機能)

    2010年12月16日 1:53
  • 返信、ありがとうございます。

    ドライバーの設定変更ですが、XP時代はジャンボフレームの設定以外は全く変更していません。Windows7にしてから、ネットワークの状況がおかしいことに気づき、色々変更してみました。特にこのフォーラムに書き込みを行ってから、それこそ『オフロードと名乗るような機能』を私も片っ端から無効にしてみましたが、状況に変化は生じませんでした。

    2010年12月16日 13:21
  • 通りすがりですが。。。

    ジャンボフレームの環境で、WindowsのTCP/IPの「遅延ACKタイマー設定」が原因で同様の現象に至ったケースを知っています。

    http://support.microsoft.com/kb/328890/ja

    本来、パケットを効率的に送信するための仕様らしいのですが、何らかの理由により通信相手とACKの受け渡しタイミングがずれてしまうと、この設定のせいで無駄な待ち時間が発生してしまい、通信が遅くなるとのことです。

    このMicrosoftのKBはXP/2003が対象ですが、私が見たケースはクライアントPC側がVista、サーバーがLinuxベースのNASでした。
    LANの設定をジャンボフレームにしてから発生し始め、別のサーバーに対しては問題ないが、このLinuxベースのNASとの大きなファイル通信だけが異常に遅延する、というものでした。

    このKB328890にしたがって、クライアントPCのレジストリ値を修正したところ、問題が解消しています。
    もしお試しになる場合には、KBにもありますが、レジストリを編集しますので、バックアップを取って慎重に操作してください。

    2011年1月6日 7:01
  • Tsukimiさん、返信ありがとうございます。

    ネットで調べてみると、同様の設定はWindows7にも存在するという記述を見つけました。とりあえず設定を変更してみました。結果は、途中で止まってしまうときもありますが、設定がないときに比べるとスムーズに通信ができるようになりました。とりあえず、少し様子を見てみることにします。

     

    2011年1月8日 10:46
  • 全くの的外れかもしれませんが、こちらの環境では若干ですが改善されました。

    netsh interface tcp set global autotuninglevel=disabled

    http://support.microsoft.com/kb/932170/ja#

     

     

    2011年1月20日 0:25
  • tarochan844さん

    こんにちは。Tsukimiです。

    私が見たケースは片側はLinuxのNASでしたが、もしかすると本ケースではサーバーもWindowsですので、サーバー側でも同じ問題が発生しているかもしれません。

    次の切り分けとしては、サーバー側のレジストリ設定も変えてみる(クライアントと同じ設定にしてみる)というステップもあるかと思います。

    根本的にはNICドライバの出来がよくないだけなのかもしれませんが。。。

    2011年1月21日 8:19