参见 我们如何试驾
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 驱动器上运行此模式（WD 的鱼子酱 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