10Gbps契約なのに約2.5Gbps。GBE10R-PCIE（RTL8127）で9Gbps台を確認するまで

2026年7月14日 00:44

10Gbpsのインターネット回線を契約しているのに、PCの速度測定は約2.5Gbps。5GbEカードを調整しても期待ほど伸びず、10GbEカードへ交換したあとも、測定サイトによっては数Gbpsにとどまりました。

そこで、リンク速度だけで判断せず、PCIe接続、ドライバー、NICの詳細設定、WindowsのTCP設定、BIOS、メモリー、測定サーバー、監視ツールの影響まで順番に切り分けました。この記事は2026年7月5日から13日に、この1台で行った検証記録です。同じ設定がすべての環境で最適になるとは限りませんが、原因を混同せずに調べる手順は共有できると思います。

先に結論

PCとホームゲートウェイ間は10Gbpsで正常にリンクし、PCIeもGen4 x1で接続されていました。高並列の受信試験では、NICカウンター上のピーク9.05Gbpsを受信破棄0で確認しています。別の試行では9.98Gbpsまで到達しましたが、この試行だけは受信破棄21,758が発生しました。直後の再試行は8.38Gbps、受信破棄0、物理エラー0でした。

したがって、「10GbEとして動いていない」「20mケーブルが2.5Gbpsで頭打ちにしている」という状態ではありません。一方で、破棄なしの安定実測として言えるのは約8～9Gbps台です。9.98Gbpsを常時維持できた、という結果ではありません。

遅さの原因は1つではありませんでした。

・交換前の5GbEカードは、当然ながら5Gbpsが物理上限だった

・Windowsの高負荷時スロットリングと、NICの受信バッファ・RSS設定に改善余地があった

・測定サーバー、経路、時間帯、接続数で結果が大きく変わった

・RTL8127は線速付近で受信処理が詰まり、単一論理コアやDPC負荷が上がる場面があった

・Packet Monitorを有効にした測定自体が、結果を大きく遅くしていた

ドライバーや設定の調整で改善はできましたが、インターネットに対して常時9～10Gbpsを保証することはできません。回線契約の10Gbps、Ethernetのリンク速度、アプリが受け取るTCPペイロードは別の数字です。

図1：NICの瞬間値とSpeedtestのアプリ実測を分けて整理した主な結果

検証環境

・回線：10Gbps契約

・ホームゲートウェイ：MR1812

・LANケーブル：LEKVKM CAT8、20m

・マザーボード：ASUS TUF GAMING B660M-PLUS D4

・CPU：Intel Core i5-12400F（6コア12スレッド）

・メモリー：Corsair CMK32GX4M2E3200C16、32GB

・交換前NIC：Realtek RTL8126、5GbEリンク

・交換後NIC：玄人志向 GBE10R-PCIE、Realtek RTL8127 REV07

・PCIe接続：Gen4 x1、16.0GT/s

・OS：Windows 11

IPアドレスやMACアドレスは原因判定に不要で、公開記事に載せる必要もないため省略します。

調査の時系列

1．5GbEカードで約2.5Gbps

最初のRTL8126は5Gbpsでリンクしていました。RSSは8キューで、EEEやGreen Ethernetなどの省電力機能も確認しました。しかし、速度測定は約2.5Gbps前後でした。

ここで注意したいのは、「5GbEカードだから2.5Gbpsだった」とは断定できないことです。5GbEカードが5Gbpsの上限を作るのは事実ですが、測定値がその半分になった理由までは説明しません。測定先の性能、単一接続の上限、インターネット経路、WindowsとNICの処理も別に切り分ける必要があります。

それでも10Gbps契約の上限を検証するには5GbEカードでは足りないため、RTL8127搭載のGBE10R-PCIEへ交換しました。

2．GBE10R-PCIEへ交換し、まず物理層を確認

交換後はWindows上で送受信とも10Gbpsリンクになりました。PCIeもカード仕様どおりGen4 x1で接続され、デバイスエラーはありませんでした。玄人志向の製品ページにも、PCIe 4.0 x1対応で、PCIe 3.0以下では帯域が不足する場合があると記載されています。

ただし、Windowsの「10/10Gbps」はPCとホームゲートウェイのリンク速度です。インターネット上の測定サーバーまで10Gbps出る保証ではありません。

20mケーブルについても、CAT8という表示だけで良否を決めませんでした。10Gbpsリンクが安定し、破棄なしの試行では物理エラーが0だったことから、この環境ではケーブルやポートを主原因とは判断していません。

3．2種類の公式ドライバーを実機比較

玄人志向はWindows 11向けにRealtek NetAdapterCx版を案内しています。一方、Realtekには従来のNDIS版もあります。推奨表記だけで決めず、両方を実機で確認しました。

・NDIS版：パッケージ10.80.50、実ドライバー10.80.50.407、WHQL署名済み

・NetAdapterCx版：パッケージ11.030.50、実ドライバー1127.30.50.508、WHQL署名済み

NetAdapterCx版は2026年7月10日に導入しましたが、このPCではWindows上でRSS非対応となりました。約5分の確認後、RSS 8キューと各オフロードが正常に使えるNDIS版へ戻しました。これは「NetAdapterCx版は常に遅い」という意味ではなく、この個体、Windowsビルド、ドライバーの組み合わせでの判断です。

NDIS版では、受信・送信バッファを4096、RSSを8キューにし、WindowsのNetworkThrottlingIndexを既定の10から0xFFFFFFFFへ変更しました。その後も1項目ずつ戻せるよう、変更前の値を保存してA/B比較しました。

4．思い込みではなくA/B試験で決める

同じ測定先と接続数を使い、変更順の偏りを減らすためABBA順で比較しました。主な結果は次のとおりです。

・TCP輻輳制御：GSL Seoulの下り平均はCTCP 6.102Gbps、CUBIC 5.580Gbps。CTCPが約9.3%高かった

・メモリー：DDR4-3200のNIC中央値平均6.56Gbps、DDR4-2133は6.38Gbps。XMPで約2.9%向上した

・Realtek Optimize Threshold：500は中央値平均6.56Gbps、1000は6.14Gbps。1000は約6%低下した

・IPv4 MTU：1500のNIC p95平均8.00Gbps、1454は7.85Gbps。1454へ下げる利点はなかった

・TCP受信ウィンドウ：ExperimentalはNormalに対する再現性のある優位がなかった

・電源プラン：高パフォーマンスはバランスより速くならなかった

図2：条件をそろえた試験内だけで比較したA/B結果

ここで重要なのは、図の行どうしを比較しないことです。測定先、時間、接続数、指標が異なるため、比較できるのは各行の左右2条件だけです。

5．BIOS・Intel ME・XMPを更新

ネットワークのA/B試験後、Intel MEファームウェア16.1.40.2765とMEIドライバー2552.8.10.0を適用し、続いて古かったBIOS 1620をASUS公式4003へ更新しました。ASUSの案内では、BIOS 4003にも同じME 16.1.40.2765への更新が含まれます。目的は「BIOS更新だけで回線を速くする」ことではなく、既知の修正を取り込み、PCIeやメモリーを含む土台を最新状態にして、古いファームウェアという不確定要素を除くことでした。

更新前にはBitLocker回復キーのバックアップと保護状態の確認が必要です。このPCは作業前から完全復号済みで保護オフだったため、そのまま進められました。公開記事では個別の警告画面を図として残すより、この注意点を本文で伝える方が有用だと判断しました。BitLockerが有効なPCでは、Microsoftとメーカーの案内に従って回復キーを確保し、必要に応じて保護を一時停止してください。

BIOS更新後はXMP Iを有効にし、DDR4-3200、16-20-20-38、1.35Vへ変更しました。8GBを2パターンで照合した短時間試験は不一致0、追加WHEA 0でした。ただし、これは約2.25秒の短い整合性確認で、長時間のメモリーストレステストの代わりにはなりません。長期安定性は継続監視が必要です。

6．Packet Monitorが測定結果を遅くしていた

原因を詳しく見るためWindows Packet Monitorを有効にしたところ、192接続の実ペイロードは3.28Gbps、別条件では2.29Gbpsまで低下し、それぞれ1接続が失敗しました。OSのNIC破棄・エラーは0だったため、通常通信の故障ではなく、高負荷な監視を同時に行ったことによる測定アーティファクトと判断しました。

さらに、pktmon stopだけではドライバーがロードされたままになる場合がありました。stopに加えてunloadまで行った対照試験では、192/192接続成功、中央値6.37Gbps、p95 7.08Gbps、ピーク7.25Gbps、破棄・エラー0へ戻りました。

「原因を調べるための計測器が結果を変えていないか」は、10Gbps級では必ず確認した方がよいです。

実測から分かったこと

高並列のCloudflare受信試験では、次の結果を確認しました。

・IPv4・IPv6合計192接続：NICピーク9.05Gbps、受信破棄0

・128接続：NICピーク9.98Gbps、受信破棄21,758

・直後の128接続再試行：NICピーク8.38Gbps、受信破棄0、物理エラー0

・上り：NICピーク6.21Gbps、送信破棄0

9.98Gbpsは「この経路が瞬間的に線速近くまで運べる」証拠ですが、同時に「その負荷ではRTL8127の受信処理に余裕がなかった」証拠でもあります。数字だけを切り取らず、破棄カウンターとセットで読む必要があります。

Ookla SpeedtestのGSL Seoulでは、同じCTCP設定でも朝の2回平均が6.102Gbps、夜の2回平均が約5.15Gbpsでした。4試行ともパケット損失は0%です。単一Cloudflare接続は約1.5Gbpsなのに、多接続では8～9Gbps台まで伸びました。これはNICの固定上限より、サーバー、経路、時間帯、並列数の影響が大きいことを示します。

なお、NICカウンターのピークとSpeedtestの下り速度は同じ指標ではありません。前者は短い区間のインターフェース転送量、後者はアプリケーションが測った実効スループットです。図1で色を分けたのは、この2つを混同しないためです。

原因をどう判断したか

今回の約2.5Gbpsを、1つの故障だけで説明することはできませんでした。切り分けた結果は次のとおりです。

・物理リンク：新NICでは10Gbps、PCIe Gen4 x1、物理エラー0。主原因ではない

・旧NIC：5Gbpsリンクのため10Gbps検証の上限要因。ただし約2.5Gbpsの直接原因とまでは言えない

・PC側設定：NetworkThrottlingIndex、RSS、バッファ、Optimize Thresholdの調整で改善余地があった

・インターネット側：測定先、経路、時間帯、接続数による変動が大きい

・残るPC側上限：線速付近では単一論理コア100%、DPC約70%となる場面があり、RTL8127の受信処理が制約になった

・測定方法：Packet Monitor併用は結果を大きく悪化させた

つまり、LANカードを10GbEへ替えるだけでも、レジストリを1つ変えるだけでも完結しません。リンク、エラー、PC内部、測定先を別々に確認する必要がありました。

ドライバーを書き換えれば常時9～10Gbpsになるか

結論から言うと、現実的ではありません。

Intel X550用ドライバーをRTL8127用に書き換える案も検討しましたが、NICごとにレジスター、DMA記述子、割り込み、オフロード、ファームウェアとのやり取りが異なります。デバイスIDを書き換えるだけでは動かず、誤ったカーネルドライバーは通信障害だけでなく、OSクラッシュやデータ破損の原因になります。

RealtekドライバーのINFを改変して項目を表示させても、既存ドライバー内部に実装されていない機能は追加できません。署名も失われ、Windowsのセキュリティと更新経路を壊します。RTL8127をリバースエンジニアリングして新しいWindowsドライバーを作ることは理論上可能でも、仕様書、実機検証、署名、保守を含む大規模な開発です。家庭回線を数%速くする手段としては費用と危険が釣り合いません。

現実的なのは、Realtekの署名済み公式ドライバーを比較し、公開されているオフロードを正しく使い、必要なら別の10GbE NICをローカルLAN試験で比較することです。それでもインターネット側の混雑やサーバー上限は消せません。

最終的に残した設定

・ドライバー：Realtek NDIS 10.80.50.407、WHQL署名済み

・リンク：自動ネゴシエーション、10Gbps Full Duplex

・RSS：有効、8キュー、CPU割り当てはドライバー既定

・Receive Buffers / Transmit Buffers：4096 / 4096

・Interrupt Moderation：有効

・Flow Control：Rx / Tx有効

・Tx / Rx Optimize Threshold：500

・LSOとTCP・UDPチェックサムオフロード：IPv4 / IPv6有効

・Jumbo Frame：無効、標準MTUを使用

・EEE、Advanced EEE、Green Ethernet、Gigabit Lite、Power Saving：無効

・Priority / VLAN：無効

・Windows NetworkThrottlingIndex：0xFFFFFFFF

・TCP受信ウィンドウ自動調整：Normal

・TCP輻輳制御：CTCP

・MTU：IPv4 1500、IPv6 1454

・電源プラン：バランス

・メモリー：XMP I、DDR4-3200、16-20-20-38、1.35V

この一覧は今回の個体での最終値です。設定を変更する前に現在値を保存し、1項目ずつ検証して、悪化したら戻せるようにしてください。

同じ症状を調べる手順

1．Windowsの表示だけでなく、NICのリンク速度、全二重、ドライバー、PCIe世代とレーン数を確認する。

2．測定前後の受信・送信破棄、エラー、再送、CPU・DPC負荷を記録する。

3．単一接続と多接続、IPv4とIPv6、複数の測定先、異なる時間帯で比較する。

4．設定は1項目ずつ、できればABBA順で比較する。ピーク1回ではなく中央値やp95も見る。

5．Packet Monitor、Wiresharkなどの監視を止めた対照試験を必ず行う。

6．可能なら、別の10GbE対応PCまたはサーバーとLAN内iperf3を行い、PC・LANとインターネット経路を分離する。

7．改善しなかった設定は元に戻し、最終状態を記録する。

今回、2台目の10GbE機器を使ったLAN内iperf3は実施できませんでした。インターネット試験だけでも10GbE動作と破棄なし9.05Gbpsは確認できましたが、NIC単体の持続上限をさらに厳密に測るなら、これが次の検証です。

不採用にした設定

・NetAdapterCx版：この環境ではRSS非対応になったためNDIS版へ復元

・TCP Experimental：Normalに対する再現性のある優位なし

・IPv4 MTU 1454：1500より速くならなかった

・Optimize Threshold 1000：約6%低下し、1回は191/192接続に悪化

・Interrupt Moderation無効：受信破棄が増えた

・RSSのMaxProcessorsを8に固定：受信破棄6,043、DPC 98%へ悪化

・高パフォーマンス電源プラン：バランスより改善なし

・PCIe ASPM無効：改善せず、受信破棄が増えた

・Jumbo Frame：ホームゲートウェイからインターネット測定先までの対応を保証できないため不使用

「高速化設定」としてよく挙がる項目でも、この環境では悪化したものが複数ありました。設定名の印象ではなく、同条件の実測で採否を決めるべきです。

まとめ

GBE10R-PCIEへ交換したことで5GbEの物理上限はなくなり、PCとホームゲートウェイは10Gbpsで正常にリンクしました。WindowsとNICを調整した結果、受信破棄なしで9.05Gbps、別の再試行で8.38Gbpsを確認できました。一方、9.98Gbpsの試行は受信破棄を伴い、一般的なSpeedtestは約5～6Gbpsで時間帯によって変動しました。

今回の最大の教訓は、「リンク速度」「NICの瞬間値」「アプリの実効速度」「回線契約」を同じ数字として扱わないことです。10Gbpsリンクが成立していても、常時9～10Gbpsになるとは限りません。エラーカウンターを見ながら、PC側とインターネット側を分け、同条件のA/B試験で判断すると原因が見えやすくなります。

参考資料

・玄人志向 GBE10R-PCIE 製品・ドライバー案内：https://www.kuroutoshikou.com/product/detail/gbe10r-pcie.html

・Realtek公式ドライバー：https://www.realtek.com/Download/List?cate_id=584

・Microsoft ネットワークアダプター性能調整：https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/network-subsystem/net-sub-performance-tuning-nics

・Microsoft NIC選定とRSC：https://learn.microsoft.com/ja-jp/windows-server/networking/technologies/network-subsystem/net-sub-choose-nic

・ASUS TUF GAMING B660M-PLUS D4 BIOSサポート：https://www.asus.com/supportonly/tuf gaming b660m-plus d4/helpdesk_bios/

・BBIQ MR1812マニュアル：https://support.bbiq.jp/uploads/pdf/MR1812_Web.pdf

※ 数値は2026年7月のこのPC、この回線、この測定条件で得たものです。ドライバーや回線状況の更新により結果は変わる可能性があります。