我剛剛將 LAN 升級到千兆位元。這就是 netperf 所說的。
前：
marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1)
port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.02 94.13
後：
marcus@lt:~$ netperf -H 192.168.1.1
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.1.1 (192.168.1.1) port 0 AF_INET : demo
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.01 339.15
只有 340 Mbps？那是怎麼回事？
背景資訊：我透過千兆位元交換器連接到 sheevaplug。我的牆上有 Cat5e 佈線，距離可能為 30 英尺。如果你不熟悉 netperf，它往往會給出非常穩定的結果並且從不說謊。
答案1
查看這個線程。其中一位貢獻者（Frenzy）很好地概述了這一點。我將引用：
千兆位元乙太網路的「真實」速度是...
1Gbps。
也就是說，它將以每秒10億位元的速率傳輸位元。
您獲得的數據吞吐量與多種因素有關：
NIC 與系統的連接（PCI、PCIe、北橋等）。
硬碟吞吐量。
總線爭用。
第 3/4 層協定和相關開銷。
應用程式效率（FTP 與 SMB/CIFS 等）
框架尺寸。
資料包大小分佈（與總吞吐量效率相關）
壓縮（硬體和軟體）。
緩衝區爭用、視窗化等。
網路基礎設施容量和架構（連接埠數量、背板容量、爭用等）
簡而言之，在測試之前您不會真正知道。 NetCPS 和許多其他工具一樣，都是很好的工具。
這個，稍後在線程中（我的重點）：
別再這樣想了。快停下來。你們所有人。
儘管您想計算出每秒傳輸的千字節或兆字節，但事實上，即使網路速度保持恆定，它也是可變的。網路「速度」（每秒位數）是絕對的。網路吞吐量（每秒實際有效負載資料）則不然。
致OP：一般來說，當從 100Mbps 切換到 1000Mbps 時，您會看到更快的資料傳輸嗎？幾乎可以肯定。它會接近理論最大值嗎？不。值得嗎？這由你決定。
如果你想談論網路速度，就談談網路速度。如果要談資料吞吐量，就談資料吞吐量。兩者並非以 1-1 的方式捆綁在一起。
答案2
「理論最大值」這個術語已經被廣泛使用，但它確實在乙太網路技術中具有實際應用。在像乙太網路這樣的 CSMA/CD 系統上，您只能發送線路所容納流量的大約一半頻寬，通常會少一些。原因是因為一旦您嘗試超過該“最大值”，收發器將開始檢測衝突，而不是傳輸資料包。然後指數退避開始發揮作用，資料包傳輸效能進一步下降。令牌環解決了這個問題，但我相信它有很多自己的問題，並且不再被真正使用。乙太網路/IP 成為事實上的標準。
上行鏈路技術（如 T3）使用非同步對，允許每條線路上的全部吞吐量，但它也不是基於乙太網路的協定。
當您使用基本的標準乙太網路設備時，總是會存在「理論最大值」。
答案3
在 GbE 背景下談論 CSMA/CD 完全是假的。千兆位元乙太網路或任何「全雙工」乙太網路不使用 CSMA/CD。雖然 GbE 仍然保持半雙工操作的理論上的可能性，但我完全不確定是否有任何實際生產的 GbE 套件可以進行半雙工。
至於為什麼 OP 在 1000 Gbit/s 鏈路上僅達到 300 多 Mbit/s，我建議在每次 netperf 運行之前和之後收集 TCP 的 netstat 統計信息，並包括 -c 和 -C 全局命令行選項查看兩端的CPU 使用率是多少。也許有什麼東西正在丟包，或者一側或另一側的 CPU 正在變得飽和。如果任一端的系統都是多核心的，請務必使用外部工具或透過 netperf 偵錯輸出來檢查每個核心的利用率。
其他 netperf 問題可能最好留給 netperf.org 郵件清單中的 netperf-talk。