另請參閱我們的試駕方式
Testbed3：審計 IPEAK SPTSR 新的第三代測試台的基石是英特爾的 IPEAK SPT，該程序為無與倫比的硬盤性能評估開闢了道路。 IPEAK 工具提供的結果有點令人吃驚； 事實上，許多讀者拒絕接受這些結果，因為它們與長期以來的觀念不一致。 更具體地說，人們習慣於這樣的想法，即 SCSI 硬盤驅動器雖然針對隨機、非本地化、多用戶情況進行了高度優化，但與 ATA 驅動器相比，即使在台式機和單用戶情況下也始終表現出卓越的性能。 因此，當 Western Digital 等製造商突破極限並在具有 8 兆緩衝區的 ATA 驅動器中提供類似 SCSI 的性能時，IPEAK 結果將其列為台式機性能的頂級 SCSI 驅動器，在發燒友社區中受到歡迎，表面上看，這樣一個單位的目標市場是混合的。 雖然許多人認識到 WD 的最新驅動器確實很特別，但其他人暗示此顯示“證明”基準永遠不會真正準確。 是時候讓這些誤解消失了！ 這樣的論證從預設的結論中迴避前提，這是不合理的。 |
StorageReview.com 的桌面磁碟機標記包含使用 IPEAK 的 WinTrace32 記錄的追蹤檔案。這些檔案隨後可以使用 AnalyzeTrace 進行分析，並透過 RankDisk 進行精確回放。 WinTrace32 與 RankDisk 的錄製-回放組合使我們能夠在多個測試磁碟機上重現任何系統活動產生的磁碟存取。 WinTrace32 攔截所有發送到控制器驅動程式的請求，而 RankDisk 則在驅動程式層級開始回放這些請求。因此，CPU、RAM、作業系統、快取以及所有其他輔助硬體和軟體對回放的影響僅發生一次，從而實現對高階變數的完美重現。請觀察以下磁碟讀取或寫入鏈：
|
WinTrace32 和 RankDisk 提供的完美、無重疊系統在理論上提供了受控試驗和相關訪問模式之間的最佳組合。 價值百萬美元的問題：我們確定 WinTrace32 和 RankDisk 確實如他們所說的那樣工作嗎？
WinTrace32WinTrace32 是一個後台常駐程序，它攔截發送到主機適配器驅動程序的所有請求。 對於每個給定的攔截請求，都會附加一個起始時間戳、起始扇區#、扇區中請求的長度以及相關的 OP 代碼（讀取、寫入、完成）。 時間戳允許 RankDisk 保留請求之間的到達間隔時間，從而可以感受到驅動程序或設備（例如標記隊列）的任何優勢。 |
WinTrace32 是否準確記錄磁盤請求？
Intel 的另一個程序 IOMeter 允許用戶通過塊大小、讀取與寫入、順序訪問與隨機訪問等設置來定義訪問模式。因此，如果我們採用已知設置的給定訪問模式並運行它在使用 WinTrace32 記錄訪問時，AnalyzeTrace 然後應該能夠檢查文件並註意 IOMeter 聲稱要發送到驅動器的內容與 WinTrace32 聲稱要查看到驅動器的內容之間的異同。
讓我們仔細看看文件服務器訪問模式，它包含在與 IOMeter 捆綁在一起的默認 wrkloads.icf 文件中：
大小、訪問百分比、讀取百分比和隨機百分比是最重要的設置。 % Access 確定總模式中有多少將由其他三個設置組成。 換句話說，對於第一個條目，訪問模式的 10%（% 訪問）將由 512 字節請求（大小）組成，其中 80% 為讀取，20% 為寫入（% 讀取）。 這些請求中的 100% 將是隨機的。 同樣的解釋適用於後面的所有條目。
通過這些設置，英特爾試圖綜合再現典型文件服務器的磁盤訪問。 一個重要的設置，即未完成的 I/O 數（隊列深度），是在另一個屏幕上設置的：
我們隨後在 ATA 硬碟（西部資料的 Caviar WD1200BB）上運行了此模式 10 分鐘，並在背景執行 WinTrace32 來擷取存取資料。 WinTrace32 的功能需要手動啟動和停止。我們嘗試在開始錄製後立即啟動 IOMeter 的存取記錄，並在 IOMeter 完成 10 分鐘測試後立即停止錄製。讓我們看看 IOMeter 的輸入變數和 WinTrace32 擷取的資料有何差異：
在此 AnalyzeTrace 屏幕截圖中跳出的第一件事是 8 扇區（每個扇區 512 字節，因此 4 KB）訪問的優勢 - 60%。 果然，文件服務器訪問模式規範要求 60% 的訪問長度為 4 KB。 10% 的訪問應該是一個扇區（512 字節）的長度。 同樣，這正是 AnalyzeTrace 報告的內容。 該練習完美地驗證：此跟踪文件中報告的所有傳輸大小與 IOMeter 請求的完全匹配。
在整個 IOMeter 運行過程中，隊列深度一直保持在 4。不出所料，這正是 AnalyzeTrace 報告的內容。
根據 IOMeter 文件服務器設置，所有請求中的 80% 應該是讀取，而 20% 應該是寫入。 AnalyzeTrace 報告說，在 48605 個總請求中，有 39043 個被讀取……或 80.3%。 其餘 9562 個請求 (19.7%) 是寫入。
由於文件服務器訪問模式要求 100% 隨機訪問，因此應該沒有 0 扇區之外的請求（如果有的話，那純屬巧合！）。 正如預期的那樣，AnalyzeTrace 報告沒有背靠背請求。 有趣的是，在這張圖表的比例尺上，尋道距離在距離上一次訪問至少 256 MB 之前甚至都不會引人注意……而且只有很少一部分達到最小值！ 與我們捕獲的桌面訪問模式形成鮮明對比，其中一半的搜索發生在彼此相距 8 KB 以內。 這個缺乏本地化的問題困擾著我們現在已經不存在的工作站訪問模式，並導致它在評估桌面性能時沒有達到目標。
IOMeter 的 csv 輸出文件列出了 WD1200BB 在此試驗中的平均響應時間為 49.48 毫秒。 從上面顯示的跟踪服務時間圖表中得出的平均值是 49.66 毫秒，所有意圖和目的都是相同的。
最後，我們快速看一下本次試驗期間的造訪次數隨時間變化的圖表，該圖表繪製在硬碟容量上。如預期的那樣，AnalyzeTrace 顯示造訪次數呈現均勻隨機分佈。順便一提，將此圖表與StorageReview.com Office DriveMark 2002（由本人實際使用電腦記錄的軌跡）的圖表進行對比，可以發現單一使用者存取的集中分佈。
從上面可以清楚地看出 WinTrace32 提供了它的交易結束 - 它簡潔而準確地捕獲了發送給它的確切內容。 與 AnalyzeTrace 相結合，WinTrace32 為我們提供了一個很好的視圖，可以讓我們清楚地了解在任何給定的任意系統使用中究竟發生了什麼樣的磁盤訪問。 但是 RankDisk 呢？ 它會重播它應該重播的內容嗎？ 讓我們來看看另一半吧！
排名盤RankDisk 是否準確地回放跟踪文件中的所有訪問？ 有一種非常簡單的方法可以測試 RankDisk 準確回放發送給它的內容的能力：記錄 RankDisk 的回放跟踪文件並將生成的第二代跟踪與原始跟踪進行比較。 為了測試 RankDisk 精確重放 WinTrace32 捕獲的能力，我們在使用 WinTrace32 捕獲回放時回放了上面概述的文件服務器捕獲。 因此，我們最終得到了第二代捕獲，然後可以將其與原始跟踪文件進行對比。 |
也許最能說明問題的是 AnalyzeTrace 對這兩個文件的總結：
| 文件服務器捕獲，原始 | 第二代捕獲 |
|---|---|
|
 |
當涉及到請求數量和傳輸的數據量時，這兩個跟踪文件具有相同數量的讀取和寫入。 在“捕獲的捕獲”中，既沒有不在原始文件中的雜散訪問，也沒有在重放中隨後沒有發生的原始文件中的訪問。
讓我們簡要地逐一看一下其他一些相關的 AnalyzeTrace 屏幕：
| 傳輸大小的分佈 | |
|---|---|
| 文件服務器捕獲，原始 | 第二代捕獲 |
 |
 |
| 平均值 = 22.0845 個扇區 | 平均值 = 22.0845 個扇區 |
兩個捕獲都反映了 IOMeter 在文件服務器訪問模式中設置參數的精確再現。
| 隊列長度分佈 | |
|---|---|
| 文件服務器捕獲，原始 | 第二代捕獲 |
 |
 |
在最初的試驗中，IOMeter 盡力將隊列深度保持在 4。左邊的圖表證明 WinTrace32 可以記錄這個恆定的隊列深度。 右圖證明RankDisk可以完美回放。
| 尋道距離分佈 | |
|---|---|
| 文件服務器捕獲，原始 | 第二代捕獲 |
 |
 |
這裡沒有驚喜。 由於原始軌跡和原始軌蹟的軌跡都具有完全相同的扇區訪問，因此兩個尋道距離圖是相同的。
| 服務時間分佈 | |
|---|---|
| 文件服務器捕獲，原始 | 第二代捕獲 |
 |
 |
| 平均值 = 49.6615 毫秒 | 平均值 = 49.6423 毫秒 |
期望給定的物理執行器在完成邏輯上相同的訪問所需的時間上會有微小的變化並不是不合理的。 一個原因可能是熱量：盤片（或執行器）可能會稍微膨脹、收縮等。即便如此，“從頭到尾”（即從給定請求開始到它的請求之間經過的時間量）第一代和第二代捕獲的完成）服務時間仍然非常接近 IOMeter 最初報告的 49.48 毫秒分數。
| 磁盤訪問順序 | |
|---|---|
| 文件服務器捕獲，原始 | 第二代捕獲 |
 |
 |
訪問模式中所有請求的位置圖本質上在兩條軌跡中是相同的。 說夠了。
RankDisk 本身，在完成軌跡回放後，會得出記錄的平均服務時間……儘管不是以“從頭到尾”的方式。 相反，RankDisk 的輸出是“頭對頭”的，即從一個請求開始到下一個請求開始之間測量的平均時間。
在從中捕獲跟踪的同一驅動器（WD1200BB）上重播，此文件服務器模式產生了 12.37 毫秒的 RankDisk 分數。 就 IOMeter 而言，它不會提供以毫秒為單位的“面對面”響應時間。 但是，它會報告每秒的 I/O 操作數。 查看 IOMeter 輸出文件可以發現 WD1200BB 在最初的試驗中平均每秒完成 80.83501 次 I/O。 當然，一秒內有 1000 毫秒。 然後可以從 RankDisk 的輸出中推斷出每秒 I/O 數以產生可比較的分數（實際上，這是在 SR DriveMarks 中完成的……結果以 IO/s 秒而不是 RankDisk 的每個請求的本機平均毫秒數報告）。 結果？ RankDisk 報告說，在文件服務器訪問模式中，在 4 個 I/O 的隊列深度下，WD1200BB 每秒執行 (1000/12.37) 80.84 個 I/O…每秒執行 80.83 次 I/O！ 非常精彩！
RankDisk 提供。 它以令人難以置信的精度和可靠性回放任何給定的捕獲跟踪文件。
結語WinTrace32 僅將對操作系統主機適配器驅動程序的訪問記錄到捕獲文件中。 RankDisk 完美回放在捕獲文件中找到的每個請求。 這些工具一起允許系統、精確和準確地回放任何給定的工作負載。 精確到什麼程度？ 看看這三個相互比較的數字： |
| WD1200BB – IOMeter 的文件服務器訪問模式，4 個出色的 I/O | ||
|---|---|---|
| IOMeter 平均響應時間 | 平均服務時間 IOMeter 試驗的跟踪文件 |
平均服務時間 IOMeter 試用版跟踪文件的跟踪文件 |
| 49.48毫秒 | 49.66毫秒 | 49.64毫秒 |
很明顯，由 IOMeter（一個允許我們逐字定義將發生何種訪問的程序）生成的原始磁盤訪問的所有屬性都保留在跟踪文件的記錄和回放中。 可以合理地假設，如果 IPEAK 可以完美地再現給定程序 (IOMeter) 的磁盤訪問，那麼它可以再現由任何其他程序或程序集生成的磁盤訪問。 StorageReview.com Desktop DriveMarks 就是典型桌面使用的精確 WinTrace32 捕獲的精確 RankDisk 回放。
其後果可能令人吃驚，但它們是無可爭辯的：對於台式機使用，ATA 驅動器（如 Western Digital 的 Caviar WD1000BB-SE）提供的性能可與當今的 10,000 RPM SCSI 驅動器相媲美甚至超過。 因此，如果您打算為您的非服務器機器購買驅動器，而您只是因為“它是 10 RPM”或“它是 SCSI”而選擇了 10,000k SCSI 驅動器，那麼您就是在欺騙自己大量的容量，大量的性能，和/或大量節省的資金！
我們最近進行了以下民意調查：
|
大多數人的普遍主題是世界已經在 Testbed3 之前進行了性能比較，但從未有過可靠性數據。 雖然我們也對可靠性數據庫感到非常自豪，而且所使用的專有過濾和分析方法使其比批評者意識到的更可靠，但不應忽視 Testbed3 的桌面性能評估改進。
社區可能已經從 SR 和許多其他站點獲得了硬盤驅動器的基準測試結果，但我們認為這些結果從未接近 IPEAK 和 Testbed3 提供的準確性。 過去，反對者能夠（合法地或以其他方式）丟棄他們不喜歡的基準測試結果，因為它們不適用於“現實世界”的性能。 如何？ 他們會提出這樣的問題：
我們不知道哪個基準最相關。
我們不知道磁盤使用情況。
我們不知道基準測試到底在做什麼。
等等…
使用 Testbed3：
我們知道！
總而言之，IPEAK SPT 的精確度和準確度是無可爭議的。 如果要對 SR Desktop DriveMarks 提出質疑，則必須以選擇用於記錄的應用程序使用情況不能代表大多數用戶為由，這完全是另一個話題。 然而，我們敢打賭，大多數拒絕接受 ATA 驅動器在世界上佔有一席之地的頑固分子，即使不考慮成本因素，也很難捕捉到將 SCSI 驅動器作為ATA 驅動器之上的頭部和肩部，因為他們願意相信情況就是如此。
Amazon