新しいネットワークのデバッグ中に、10ギガビットイーサネットが300メガビットで動作する

新しいネットワークのデバッグ中に、10ギガビットイーサネットが300メガビットで動作する August 27, 2026 この投稿にコメント [2] Musings に投稿 スポンサー提供 ホームラボの近代化の一環として、ホームストレージをUniFi UNAS Pro 8に移行しています。私のメインのIRONHEART（数年前の究極のPC）デスクトップには、Intel E610-XT2 10GbEカードが搭載されており、NASは10GbEに接続され、同じネットワーク上にはMinisforum MS-01ミニPCがあり、ImmichやPortainerなどを実行する10GbE SFP+接続を備えています。すべてが10ギガビットと表示されています。Windowsは10ギガビットと表示されています。UniFiは10ギガビットと表示されています。SMBコピーは正しいNICを使用していますが、ファイルコピーは毎秒100〜200メガビット程度でしか実行されておらず、これは残念なことです。 当然、NASと、その中の回転するディスクを疑いました。UNASには6つの16TBの回転ディスクがRAID 6で構成され、2つのNVMe SSDがキャッシュとして使用されています。また、MS-01でImmichを実行しており、その写真ライブラリはUNAS上にありますが、多数のサムネイル、メタデータ読み取り、および小さなバックグラウンド書き込みが発生しています。これらすべてが合理的な容疑者に見えます。 UNASのSSDキャッシュを読み書きから読み取り専用に変更しました。意味のある違いはありませんでした。Immichを完全に停止しました。違いはありませんでした。iostatを確認しましたが、ディスクは飽和していませんでした。SMB署名とWindows Defenderのネットワークスキャンを確認しました。それでも遅いです。 その後、NASのテストを中止し、WindowsデスクトップとMS-01の間で直接iperf3を実行しました。 iperf3 -c 192.168.1.222 -P 4 133 Mbit/sec 逆方向のテストは改善しましたが、それでも間違っていました。 iperf3 -c 192.168.1.222 -P 4 -R 1.33 Gbit/sec これは奇妙です。これで、ディスク、SMB、Immich、RAID、そしてNAS自体が完全に除外されました。これはWindows/NICの問題であり、奇妙に非対称的です。 Intelアダプターの統計情報を見ると... Get-NetAdapterStatistics -Name "Ethernet - 10 Gig Intel" 受信破棄パケットが100万件近くありました。10秒間のiperf3テスト中に、カウンターはさらに268増加しました。なぜでしょうか？ E610のドライバーは、最大4096をサポートしていましたが、受信バッファはデフォルトの512でした。それらを増やしました。私はバッファの増加が大好きです。 Set-NetAdapterAdvancedProperty ` -Name "Ethernet - 10 Gig Intel" ` -DisplayName "Receive Buffers" ` -DisplayValue "4096" 次のテスト中の破棄パケット数は268からゼロになり、受信スループットは1.33 Gbit/secから5.15 Gbit/secに跳ね上がりました。送信方向はまだひどく、基本的に313 Mbit/secでした。 次の実験は、IPv4用のLarge Send Offload (LSO) V2を無効にすることでした。 Set-NetAdapterAdvancedProperty ` -Name "Ethernet - 10 Gig Intel" ` -DisplayName "Large Send Offload V2 (IPv4)" ` -DisplayValue "Disabled" そして、同じiperf3テストを再度実行しました。 7.03 Gbit/sec これはタイプミスではありません。1つのNIC設定を変更することで、313 Mbit/secから7.03 Gbit/secになりました。素晴らしい！ LSOは良い理由のために存在します。WindowsはNICに大きなTCPバッファを渡し、アダプター/ドライバーがそれをネットワークサイズのパケットにセグメント化できるようにし、CPUの作業を削減します。しかし、Microsoftは、セグメンテーションオフロードが一部のネットワークアダプター/構成で最大持続スループットを低下させる可能性があることを明示的に指摘しています。LSOは通常有用ですが、このケースではそうではありませんでした。WindowsとIntel E610-XT2の私の特定の組み合わせでは、IPv4 LSOパスの何かが非常に、非常に悲惨でした。これがIntelドライバーのバグなのか、ファームウェアの問題なのか、Windowsとの相互作用なのか、あるいはこのマシン固有のものなのかはまだわかりません。そのため、これをランダムなテックブロガーのアドバイスとして、誰もがLSOを無効にすべきだとは言いません。まず測定し、次に切断します。いや、二度。常に注意を払いましょう。 最後に、すべてを開始したテストに戻り、同じ大きなファイルをUNASにコピーしたところ、Robocopyは次のように報告しました。 Speed : 350,201,354 Bytes/sec. Speed : 20,038.682 MegaBytes/min. 毎秒約350MB、または6ディスクRAID 6 NASへの持続的な実世界のSMB書き込みで2.8 Gbit/secです。それははるかにましな速度です。 有用な教訓は「LSOを無効にする」ということではありません。それは、ストレージが不可解に遅い場合、最終的にはストレージのテストをやめなければならないということです。iperf3は、NAS、ファイルシステム、RAID、キャッシュ、SMB、およびディスクを一度に実験から除外しました。生のネットワークも遅くなった後、問題は劇的に小さくなりました。そして、時には「Large Send Offload」というラベルの付いた小さなチェックボックスが、2004年のように10ギガビットカードを実行させる能力を持っていることがあります。 TL;DR - IPv4用のLSO V2が有効な場合、WindowsからLinuxへのiperf3は毎秒約313メガビットを達成しました。その単一のオフロードを無効にしたところ、全く同じテストで毎秒7.03ギガビットになりました。私はこのマシンについて意図的に言及しています。なぜなら、LSOは通常有用であり、これはどこでも無効にすべきという一般的なアドバイスではないからです。 Scottについて Scott Hanselmanは、元教授、元金融分野のチーフアーキテクト、現在はスピーカー、コンサルタント、父親、糖尿病患者、そしてMicrosoftの従業員です。彼はスタンドアップコメディアンとしては失敗し、コーンロウを編み、作家でもあります。 ニュースレターについて ホスティング提供： この投稿にコメント [2] BlueSkyでシェアするか、パーマリンクを使用してどこでも投稿してください！ August 28, 2026 7:28 これは、Windows 2003 Service Pack 2（記憶が正しければ）でTCP Chimneyが導入された頃のことを思い出させました。SP2にはその機能が有効になっていますが、特定のNICがそれをサポートしていなかったため、追跡に時間がかかる断続的なネットワーク問題が発生しました。解決策はそれを完全に無効にすることでした。そして、すべてが元通りになりました。 Redzuan Redza August 28, 2026 7:57 失礼ですが、代替OSが役立つこともあります。 kitmanson 名前 メールアドレス（グラバターアイコンが表示されます） ホームページ（オプション） 5+1=? コメント（一部のHTMLが許可されます：a@href@title, b, blockquote@cite, em, i, li, ol, pre, strike, strong, sub, super, u, ul）ここで@は「属性」を意味します。例えば、<a href="" title="">や<blockquote cite="Scott">を使用できます。 ライブコメントプレビュー