請教
問什麼從CPU拉出來的PCIe是原生
從北橋拉就不是?

北橋拉的是原生，只是不是CPU原生而是晶片組原生，傳輸時要多經過一層PCH到CPU之間的傳輸，因此會產生遞延延遲．

如果是從CPU拉出來的PCIe，資料的走向會是HDD→SATA控制卡/控制晶片→PCIe→CPU

如果是走PCH的話，資料的走向會是HDD→SATA控制卡/控制晶片→PCIe→DMI(就是PCH跟CPU的傳輸介面)→CPU

多一個DMI，而DMI傳輸頻寬有限，同時要負擔其他東西，像SATA 6G USB3.0等等

就好比春節的高速公路交通一樣，路就這麼大條，車又這麼多，不作點匝道管制怎麼行

我知道跑測試的圖看來真的很奇怪，我自己都覺得被截成一條線很怪，哪怕我自己都覺得這應該是合理的

原來是這樣
一個是CPU原生
一個北橋原生
差別在有沒有多繞路
感謝樓上兩位

快別這麼說 推巫佚大 常看到你的熱心測試分享 數據都整理得很詳細

希望能持續分享
:like:

有沒有過DMI影響應該有限吧,DMI的throughput是1GB/sec起跳的(又不像HUB link只有266MB/sec:stupefy: ),除非測試時還有其它I/O一起搶DMI,不然被卡在16xMB/sec是蠻怪異的,不過問題出在卡或M/B就得再研究了:ase:ase....

請別忘了遞延延遲,不是只有頻寬會受限...。

這個的確蠻難測試的,不過要是把卡/HD拿到其它M/B非直通CPU的PCI-E上也不會被卡在16xMB/sec上時,問題出在哪應該就有點參考價值了吧:ase:ase....

其實光測試結果就看得出來問題是在遞延延遲了．（畢竟該卡只是x1裝置，裝在x1/x4/x8/x16根本都一樣）

現在就等原PO跟媒體一樣拿SSD測試就完成足以澄清情況的close loop驗證了．

如果是latency的狀況那為何sequential read不會卡在16xMBps,而sequential write會啊(暫且忽略read/write底層I/O的差異:ase:ase)....