目录：
1. 概述
2. 常见误区
3. 测试方法
4. 测试过程
5. 结果统计
6. 结论
概述：
自从很多年前开始做SSD方面的测试以来，我就和某些行业工作者产生了同感：存储性能测试基本是所有计算机硬件测试里最复杂困难的一项。存储系统的性能受到整个机器其他硬件甚至软件方面的影响：按ssd本身来说，在不同负载（线程数，队列深度，块大小，随机度等）环境下一块盘发挥出的性能大有区别，设置成不同扇区大小性能会不同，在相同情况下测试一段时间盘的性能还会发生FOB-transition-steadystate的转变；按软件环境来说，不同系统、文件系统以及软件本身的访问模式都能造成性能差别；另外其他硬件比如CPU和控制器、阵列卡等也可能影响SSD的性能。因此在测试方法上的研究层出不穷，甚至有行业组织给出测试建议（如SNIA的Solid State Storage Performance Test Specification）。
intro.png (102.62 KB, 下载次数: 0)
也正是因为这种复杂性，各种不做SSD的人，比如操作系统、数据库、磁盘控制器（HBA和阵列卡）甚至CPU/FPGA制造商都在为存储性能贡献力量。近几年各种诸如基于GPU、FPGA数据中心以及NDP（近数据处理）的新方案也层出不穷。
本文主要测试的就是这些“SSD本身性能以外”的部分，通过在不同软硬件环境下对多块SSD进行测试，看看系统的硬件平台、操作系统和文件系统对SSD性能的影响，同时对目前几个存储测试工具进行评测，以验证它们的测试方法和生成的结果的可靠性。
Disks-all.jpg (412.83 KB, 下载次数: 0)
常见误区：
在开始测试之前，我们先纠正一些认识上的误区。
1. 操作系统、文件系统（分区格式化）对SSD性能影响很小甚至与其无关
其实曾经有个阿里的技术员就是因为忽视这个关系导致犯了很大错误被开除，甚至业界曾经因为这个问题出过一场风波。简单的看，你使用软件在读写磁盘数据时，系统会先下指令，文件系统会找到对应的LBA（逻辑地址），经过协议、驱动层到SSD主控，主控又会通过映射表将LBA转换成PBA（物理地址），从而对SSD颗粒上的数据进行读写。具体过程网上和书本里很多这方面介绍，这里就不赘述了。我们要知道的是，这其中每一环都会产生延迟损耗。
在十几年前，我们可以说这种损耗相对于普通的碟片存储和早期SSD来说基本可以忽略不计。但是随着硬件的发展，存储设备的性能上升了几个数量级，于是这些软件的部分越来越不可以忽略，甚至开始争夺性能的主导影响因素。一个比较极端的例子就是，傲腾内存Optane DCPM在内存模式下延迟在200-300ns之间，但是在块设备模式下驱动成磁盘的话，延迟就是微秒级了。下图就是一个大概的影响因素的统计，应该是linux下，因为后文测试中win下影响更大。这也是人们不断开发引入更高效的新文件系统的原因之一。
[2017]accelerating-your-nvme-driave-spdk-fig-1.jpg (44.45 KB, 下载次数: 0)
但是事情真的只是一个固定overhead这么简单么？事实并不是这样。实际上初始化格式化以后，SSD甚至整个存储系统的性能特性可能会发生很大的变化，不同文件系统下的磁盘性能也有很大差别。这就是上面阿里当年引进的SM843T彻底翻车的原因。还有过别人买了很多片840pro进行测试，结果如下图。通过个人测过的几十片SSD的经验来看，实际上CPU占用、CPU内存延迟、SSD的内部调度等方面都能影响硬盘的实际性能。要彻底弄清基本不可能，因为涉及到各家闭源的固件策略，所以我们只能而且必须要在测试时注意。
840pro-1.png (56.38 KB, 下载次数: 0)
840pro-2.png (55.22 KB, 下载次数: 0)
2. 裸盘（RAW）不格式化直接测试出的性能=存储设备的真实性能
这个观点有2个问题：
① 文件系统和操作系统对性能可能有很大影响，上面已经详细说明不再赘述。对于一般人，一块硬盘给你，你不格式化又怎么使用呢？格式化写入文件的测试方式和裸盘直接跑，哪个更能反映实际使用的方式和过程，哪个对于大部分用户更真实，一目了然。
当然经过调查也发现部分数据库软件也有支持裸盘操作，但是因为管理繁琐，安全性未知，甚至有手册建议不要用裸盘存重要数据。而且一般同样要建立一个raw分区，而且要实现日志之类功能仍然是殊途同归。再加上现在的文件系统很多都支持directIO操作可以绕过缓存策略等影响因素，所以裸磁盘的应用面限制很大。
② 测SSD的一个大忌就是不进行preconditioning，也就是测试前不先写入好被测试数据就进行测试。这不只是有些影响因素没测到的问题了，整个测试都可能掉进SSD的“行为陷阱”里。前几天和一个测试软件的开发者讨论了这个事情，基本把这个错误做法可能产生的问题整个列举了一遍。详细讨论过程在此：https://github.com/microsoft/diskspd/issues/131。
大概总结一下，如果你不做preconditioning的话，直接拿来测或者测了没有写入到的地方，SSD的FTL可能仍然没有把颗粒上的这块空间标记为写入过，结果就是测试根本没有落盘（即没有读写到存储介质本身），硬盘闭着眼反馈00或者FF，直接在主控里解决了。甚至如果preconditioning做的不好的话，SSD仍然可能找出规律使得测试结果出错。目前已知有2个人因为这个问题测出了远高于SSD性能标称的数值，另一个在这：https://github.com/microsoft/diskspd/issues/129
对于不能访问github的人，引用一下上述讨论的重点：
同时作为验证，使用指令建立一个空的20GB文件而不进行数据写入（即不进行preconditioning）：
fsutil file createnew E:\iobw2.tst 21474836480复制代码这时使用diskspd和iometer直接测试这个文件，就会得出一个100多万IOPS（约4GB/s）的结果。这个结果远远超过了pcie 3.0x4 SSD的随机带宽，甚至大幅高于理论顺序带宽。显然这个结果是错误的。当使用下面指令将数据写入这个文件也就是正常进行precondition以后，测试结果就会回归正常。
fio --thread --filename=iobw2.tst --rw=write --size=20G --name=writeonce --bs=1M --end_fsync=1复制代码
D700-noprecondition.PNG (547.51 KB, 下载次数: 0)
当然你也可以不格式化直接不断写入来做preconditioning，SNIA的SSSPTS建议是全盘写入2遍。但是这样写2遍下来以后，SSD正在进行垃圾回收（GC），而且你并不知道它什么时候会停，有时候通电放置几小时以后测出来的性能仍然不正常。你也可以指定测试区域然后对这个区域进行preconditioning，但是这样的测试会非常复杂，SSD不确定会不会认为写入的数据是有效数据，而且有意避开系统环境这个影响因素一般也没什么实际意义。
所以个人建议测试SSD首先创建写入了full random或者pseudo random的随机数据文件，排除一切潜在威胁，然后进行测试。当然此次测试也会包含RAW的情况作为对比。
3. 只要CPU内外各总线（比如PCIe、IF、Mesh）带宽充足，PCI-e SSD就能发挥出最大性能
这个很好证伪。我们把CPU关成4核，此时CPU内外各个总线带宽仍然远大于区区一块PCI-e 3.0x4 SSD，但是这块SSD的随机性能已经下降到应有的一半，即便硬盘是裸盘没有分区。测试工具的选择会在后文提到。
4c-scr.jpg (273.39 KB, 下载次数: 0)
其实访问存储设备远远不是数据传输过去就行那么简单，其涉及到各种校验及元数据处理等操作，可能还有多次传输的情况。不是什么问题都能极度简化的。
测试方法：
测试硬件：
为此次测试专门搞了一颗EPYC2 7R32。这是一颗48核CPU，在测试中保持在3.3GHz附近，BIOS 为2.0b版本（agesa 1.0.0.4）。Intel平台采用铂金8275CL，微码5000024。测试平台系统进行了众多优化，比如关闭节能、超线程（win），手动设置p状态和determinism，内存频率，PL1、PL2时间，关闭日志等。
CPUs.jpg (442.89 KB, 下载次数: 0)
参测SSD主要为Memblaze Pblaze5 D700 4TB和三星PM1725a 3.2TB。最后将会有傲腾内存Optane DCPM露脸。Windows下测试采用现成的binary，Linux下则自己build了3.18版本FIO。
Disks.jpg (433.08 KB, 下载次数: 0)
测试平台：
CPU：Xeon Platinum 8275CL/EPYC2 7R32（IF频率3200MHz）/EPYC2 7702（IF频率2666MHz）
内存：Samsung DDR4-3200 2Rx4 RECC x6（@2933）/x8（@3200）
硬盘：Pblaze5，PM1725a，Optane DCPM 512GB（Apache Pass）
操作系统：Windows 10 1909，CentOS 8.1.1911
文件系统：RAW，NTFS，EXT4，XFS
测试软件：IOmeter，FIO，Diskspd
测试项目：
根据以往测试，其他软硬件对系统存储性能的影响集中体现在高并发高吞吐量的环境中，而这个方面往往是高性能数据中心关注的首要重点之一。依此设计测试4KB QD16x16T 随机direct-IO读取。文件系统下测试的部分，先创建20GB的测试文件并写入pseudo random随机数据，然后进行测试。
FIO的jobfile如下：
[QD16x16TRR]
filename=iobw.tst
ioengine=windowsaio
direct=1
thread=1
iodepth=16
rw=randread
bs=4k
size=20g
numjobs=16
runtime=39
time_based
group_reporting 复制代码
Diskspd命令如下：
diskspd.exe -b4K -t16 -r4K -o16 -d39 -Sh E:\iobw.tst复制代码
测试过程：
首先简单说一下带宽单位IOPS和常说的MB/s、GB/s怎么换算。其实很简单，如果是4K测试的话，直接拿那个IOPS乘以4K（4096）就是以B/s为单位的带宽，比如40万IOPS 4K测试就是400000x4096=1638400000B/s，也就是1.6384GB/s；80万IOPS就是3.2768GB/s。
如果要换算成GiB/s的话最后一步除以3次1024。
Pblaze5 D700：
首先是intel平台的测试。裸磁盘状态下SSD原始性能大概85万IOPS，和硬盘的标称性能基本一致。
8275CL_D700_raw.JPG (153.54 KB, 下载次数: 0)
在windows+NTFS下iometer和FIO差不多，比diskspd测出的数值更高。SSD的性能发挥程度很高。
8275CL_D700_windows.JPG (321.22 KB, 下载次数: 0)
linux下，在XFS和EXT4文件系统上两个测试双双摸到84万IOPS，性能相对裸磁盘没有什么损失。而NTFS文件系统下得出的成绩很低，可能是因为FIO关闭文件系统缓存的指令没有生效。
8275CL_D700_linux.png (443.5 KB, 下载次数: 0)
然后是AMD EPYC2 7R32平台。裸盘测试的性能和intel基本一致，也为约85万IOPS。
7R32_D700_raw.JPG (149.03 KB, 下载次数: 0)
windows+NTFS下，FIO和iometer仍然比较统一，但是性能损失比较大，而且每次测试成绩不太稳定，在42-50万IOPS徘徊。此时diskspd的成绩反而高一些。由于波动性的存在，统计的时候将同时统计最小和最大值。
7R32_D700_windows.JPG (314.22 KB, 下载次数: 0)
在linux下性能不稳定的现象明显减弱，相对于裸磁盘状态的性能下降也有不少缓解。这里我们可以看出不同文件系统下磁盘性能的差距。另外NTFS一样出现了bug。
7R32_D700_linux.png (446.95 KB, 下载次数: 0)
PM1725a：
接下来测试三星PM1725a。首先还是intel平台裸磁盘性能，约81万IOPS，仍然符合标称性能。
8275CL_PM1725a_raw.JPG (154.64 KB, 下载次数: 0)
在windows下格式化成NTFS测试，性能基本没有变化。
8275CL_windows_HoffPoffCoff.JPG (321.74 KB, 下载次数: 0)
在linux下性能反而有一点点损失，平均接近78万IOPS。
8275CL_linux_3.png (451.24 KB, 下载次数: 0)
然后是AMD 7R32 CPU下的测试。裸磁盘情况下和intel平台差不多。
7R32_PM1725a_raw.JPG (148.97 KB, 下载次数: 0)
windows下格式化以后，带宽仍然在44-50万iops波动，总体成绩和上面使用Pblaze5 D700时差不多。
7R32_windows.jpg (319.41 KB, 下载次数: 0)
linux下，规律也和之前D700差不多，只是EXT4下性能下降更加明显。
7R32_linux.png (466.78 KB, 下载次数: 0)
另外通过发SSD给朋友然后远程借用的方式测试了一下EPYC2 7702+PM1725a在windows下的表现。规律和7R32差不多，不过绝对的性能数值弱一些，IOmeter和FIO在39-44万IOPS附近徘徊。
7702_windows_6x.png (366.54 KB, 下载次数: 0)
结果统计：
我们对上述测试的平均带宽（IOPS）和平均延迟进行统计。首先是Pblaze5 D700在各个平台、操作系统和文件系统下的结果（箭头代表越大还是越小越好）：
PB5-iops.png (41.8 KB, 下载次数: 0)
PB5-lat.png (35.38 KB, 下载次数: 0)
然后是PM1725a的结果：
PM1725-iops.png (46.62 KB, 下载次数: 0)
PM1725-lat.png (39.25 KB, 下载次数: 0)
另外，尝试使用Primo RAMdisk建立一个内存盘进行测试作为参考，结果如下。不过内存盘的性能主要受制于软件模拟驱动而不是使用的内存本身，这就是为什么内存能跑到100GB/s以上、100ns以下时内存盘仍然只能测出这个成绩。RAMdisk的特性有时候比较奇怪，仅供参考。
ramd-iops.png (26.9 KB, 下载次数: 0)
ramd-lat.png (26.74 KB, 下载次数: 0)
另外我对于测试软件本身进行了验证。在win下FIO内置的队列深度统计数据不太准，我们可以无视它。直接通过WPA抓取测试时磁盘实时的队列深度，我们可以发现3个软件在负载本身上大体都是可靠的。
QDrecording.png (93.26 KB, 下载次数: 0)
结论：
1. 业界普遍的“windows下使用IOmeter，linux下使用FIO”的说法是正确的。不论从可以跑到的带宽和延迟的最好值、测试成绩还是负载而言，它们得出的数据都很可靠。在windows下，IOmeter的成绩比FIO稍好，bug很少，overhead很低包括CPU占用低，preconditioning以及设置负载模型方便的多，而且按成绩看默认就是直接IO模式；而在linux下，FIO可以发挥出SSD的全部性能，而且可设置的功能非常多。一般用户如果要验证结果的话，甚至Crystal Disk Info得出的数值都不差，这类爆发跑分软件不符合实际之处主要在测试项目的安排和一些bug，而不是实际测出的数值上。如果要做一个严谨的测试，那还是使用经过时间验证、行业普遍采用的工具比较好。
对于微软的diskspd，开发人员声称其使用了“windows下更加原生的IO路径”所以测出的成绩高一点。目前实际测试中，diskspd在intel平台结果比fio和iometer略低，但是在amd平台偏高不少。个人和其他专业人员探讨这个区别可能是时钟源问题导致的，但是目前我这里diskspd的高级时钟功能仍然因为bug无法正常打开。加之其功能仍然不全（比如没有x%随机读+y%顺序写这种设置），建议一般测试者等它更新几个版本稳定好用再说。
一款工具好不好，是看它好不好用，而不是看谁更新、谁有一些你用不到的功能。看看周遭世界，几百年几千年没有更新但是仍然好用的工具大把。
bug.PNG (28.44 KB, 下载次数: 0)
2. 不同盘在不同操作系统、文件系统的上的性能发挥是有区别的。每个盘都有自己的特性。不建议在ubuntu上进行SSD性能测试，因为AMD平台性能波动非常大，有时候会超过硬盘裸盘性能，有时候多测几次性能减半；另外group_reporting功能有时会失效。
3. AMD平台的存储性能影响因素比intel平台复杂，和CPU核心数、频率和IF总线频率包括测试分配到哪个核心都有关系。如果你使用的是EPYC2 7R32这种IF和核心频率高CPU的话磁盘性能会有不少提升，但是如果你使用的是EPYC2 7452这种低IF低频或者R7 3700x这种少核心CPU加上一块普通闪存SSD的话，也许你在windows下只能享受到40万iops左右（大概相当于PM1725的一半）的性能。
另外AMD平台对于低延迟优化的SSD性能上限略有增加，比如我在测试SZ983的时候得到过60多万IOPS的性能，但是这些盘主推的低延迟优势会很难发挥。
4. AMD平台本地SSD的随机性能带宽和延迟都弱于Intel。根据上面的测试，虽然两者裸盘性能差不多，但是SSD分区格式化以后，AMD平台在windows下性能劣势较大，稳定性较差，linux下劣势相对较小；另外存储I/O对CPU核心的占用也更大。再加上AMD在数据库软件和硬件方面的生态非常不足，以及可扩展性较低，所以大家可以从几个侧面看到，为什么AMD卖出的EPYC一般都是用于云租赁而不是高I/O性能数据中心之流，以及为什么即使各个厂商大力推广，业内仍然有很多人不愿意做基于AMD平台的存储系统方案。
同时，我们不应当认为做服务器方案的都是墨守成规的老顽固，更不要随便产生自己比一群专家更懂的错觉。
5. 第4条结论不代表AMD在其他方面的性能差，更不代表AMD的CPU整体差。请对某些误导性言论进行仔细鉴别。
6. 对于intel，一颗6-8核心家用CPU基本足够跑满单盘，如果要测试性能一致性（consistency）建议使用8核以上CPU。对于单路intel Xeon的SSD性能总和的上限，我使用2条Optane DCPM 512GB傲腾内存加测试中的两块SSD，跑出了接近400万IOPS（16GB/s）的4K随机性能。此时所有SSD的性能基本是线性叠加，仍然没有达到CPU极限。
所以说，机器的存储性能标不高，怪不得工具、系统也怪不得盘。
2xDCPM 2xNVMe.JPG (208.96 KB, 下载次数: 0)
7. 参考文献：
唐僧 huangliang - 性能修正：Intel Optane DC持久化内存更多测试
Steven B., Thai Le - Accelerate Your NVMe Drives with SPDK
neeyuese - 三星840 Pro新固件在Linux下严重掉速
Micron - P320h/P420m SSD Performance Optimization and Testing Introduction
Intel - Intel® Solid State Drive 750 Series Evaluation Guide
Intel - Intel® Optane Memory Evaluation Guide
SNIA - Solid State Storage (SSS) Performance Test Specification (PTS) Version 2.0.1
8. 测试各种原始结果的网盘。
链接：https://pan.baidu.com/s/1u7tq82XlTHw7tML7Bsow9g
提取码：pc9k
另外一提，把7R32在1909下测了一遍，相对于1809根本没有什么卵提升，没有需求的用户可以不升。目前所有有质疑的结论均已全部完成验证。
评论
前排围观
评论
好长，直接看的结论
评论
群内帮顶
评论
理所当然
IF的带宽和延迟就那样，并且红队内存性能也差一点，存储性能肯定是有差距的
反而这次测试XFS下差距只有10%倒是出乎意料，我还以为能差20%，看来家用和工作站都足够了
评论
LZ做的测试 应该说证实了一些观点
AMD的IO弱于Intel 包括锐龙！AMD的老传统了这是
家庭用户基本可以无视这条 但是高IO数据中心并不可以。。。
另外 跑盘 尤其跑4K 是会大量占用CPU的！你的磁盘跑分没别人那么高可能是你的U不够好
其实我觉得家庭用户关心这么多干嘛 知道哪个盘好然后就用就是了
评论
大佬的测试提醒了我要继续攒钱
评论
好帖，真的是好帖
评论
前排膜拜大佬！
评论
这话说得太好了。我指出你的测试的不客观之处可能你不太能接受，那我们看一下行业内基于AMD的存储方案性能如何。
镁光作为目前存储方案领头羊之一，为他们最新锐的旗舰SSD 9300MAX提供了两套Ceph存储公版方案：
一套是基于Intel的（未注明）：
C8E71A4B-B9FF-4AF9-8C6B-C9C3F8A798C8.jpeg (128.29 KB, 下载次数: 0)
一套则是基于Rome：
13E3AF68-A17B-4A00-B0E2-A9F17F739D43.jpeg (157.69 KB, 下载次数: 0)
这两套方案的存储node都是4个，每个存储Node都包含10个12.8TB的9300MAX。Intel使用双路8168，AMD使用双路7742：
69D607C6-A3B2-45C4-8D63-FF5AFDD4FDDA.jpeg (249.13 KB, 下载次数: 0)
1E3A6BE3-DCA1-4674-A39A-877A33AF5B57.jpeg (248.79 KB, 下载次数: 0)
那么性能结果如何呢？
8FE01A9F-DD80-4CA7-B3B8-3205CCB89A86.jpeg (217.18 KB, 下载次数: 0)
EAA81FEB-2D02-4390-BFA4-4D339BF1E094.jpeg (266.65 KB, 下载次数: 0)
AMD方案的随机IO和延迟无论读写还是混合，都优于Intel方案，而Intel方案的优势则是4MiB的连续读写
回到主题，你武断地认为基于AMD的存储方案IO一定更弱是不准确的，甚至可以说是错误的。
评论
这个盘不错，我一直想搞一套来测测，因为镁光有mongodb的spdk实现。
评论
我有个疑问啊，存储服务器一般不都是卖解决方案的吗？那他们还上epyc岂不是傻逼？
而且买那些玩意的人会刷论坛来影响决策吗？
哦我懂了，又要有大船靠岸了…
堆论文这种玩法咱年轻时候也玩过，当时就不理解为啥导师们都是这个态度，现在我懂了
而且瞎JB下结论这个毛病被狠批了一次后就改了，哪有一次一次再犯了，脸皮也太厚了
评论
说的好 简单明了
评论
某人可能觉得自己比储存厂商更权威吧
评论
我不想看你解释，你能不能给我搞点工包ssd
评论
毕竟是胶水总线。。
家用根本达不到这种瓶颈
评论
等其他大神验证
评论
某人虽然民科权威，但可比某个整天转帖瞎BB带节奏的人好得多。顺便，某人你5GHz呢？
评论
腥风血雨又要开始了
评论
老大，上次你给我的话我只能还给你了。你这10个盘才跑到200-300万iops左右，我2个盘intel平台就160-170万了。这测试基本就相当于我这边两三个盘的数。所以这真的是纯磁盘性能么？我觉得你应该仔细看看这2个测试是不是有其他方面的瓶颈，比如其他硬件、网络和软件。
另外我发现本坛其他几个人整天就在找机会杠找别人每个字的错，给别人下定义的时候却丝毫不顾及口口声声说的“严谨”。STH的Patrick Kennedy如果来这个论坛估计早就被喷成狗了，因为他曾经还预测过epyc2靠PCIe做双路互联。没关系，他也是民科，本坛已经上天的某些文也是民科，我们大家全是民科。（不是针对你）
edit.找到了3个华点。测试环境甚至测试本身都不一样，怎么比：
1. 美光两个测试系统、驱动、软件环境都不太一样，别的条件也不太一样，fio client数也不太一样。可比性不太好。建议看原文。另外提醒你一下，RHEL更新换代很慢，7.6和7.7版本差了接近1年。
https://www.micron.com/-/media/c ... ce_architecture.pdf
https://www.micron.com/-/media/c ... cuments/9300_ceph_3,-d-,3_amd_epyc_reference_architecture.pdf?la=en
system.PNG (90.79 KB, 下载次数: 0)
2. 楼上第一帖指出的应该是网络环境下的测试。非本地测试本身不一定有错，但是建议你看一下第十四页的测试说明：
intel：
amd：
多开数量都不一样怎么能比？这是很基础的问题吧。这种条件上的差别这两个文件各种地方区别挺多的，可能因为这两个测试间隔时间比较长方案有改动吧。所以说建议仔细看，不要踩雷。
3. 还有这个测试，看随机读和写。这个介绍有点迷，不过看每个测试延迟对应的带宽比我的测试还猛。
为什么这么看，是因为同样的设备下带宽和延迟是正相关的。我记得storagereview就经常用带宽-延迟曲线做统计
micron_fio.PNG (393.41 KB, 下载次数: 0)
还有我为什么这么设计实验，实验为什么可以反映平台的强弱，请看第三页76L的回复。说实在我以为很多人能理解，结果很多人不理解，但是请不要随口就下定义别人都是错误的别人不能反映实际只有自己能好不好，把测试仔细看完再下结论好不好，尤其可变因素那么多的情况下。
评论
是的，家用那些娱乐盘很多本身就不到40万iops。。。
评论
楼主再次尝试冒犯CHH熟人圈的固有思维和秩序，理所当然的还是会遭到各种抵制
评论
我不用找其他的所谓瓶颈。不要跨环境比较，这是生产环境的“真实性能”，你的合成环境和生产环境差距太远，因此你跑的这几个分和这里测试的数据没有任何可比性。这两套系统并不是为了衡量所谓“绝对性能”组出来的，而是为了真正投入使用的时候能有多少性能。换句话说你觉得测Raw Disk Performance没有意义，那我一样可以用这种数据认为你的合成测试没有意义。
如果你不认同镁光的测试方法和结论，那你可以尝试照着他做一套Ceph系统跑个分，看看你的结果和他的结果有何不同。或者你也可以告诉我 你的环境 比镁光公版环境 更加符合生产环境的“真实性能”，那确实镁光没你懂。
现在我们主要矛盾是什么？你认为包含了文件系统在内软件overhead的东西叫"纯磁盘性能"，但是我认为raw perforamance才是"纯磁盘性能"
你的论据是"有文件系统才能用"，那我一样可以说"文件系统的overhead可以算进去，别的软件就不能吗？毕竟磁盘性能也不能脱离工作负载存在呀！"
评论
他这个平均4K读延迟都到1.3-1.5，平均写延迟6.4-6.7，按经验看最大延迟可能都到几十了。多和业内人士交流一下就知道，这种延迟在某些实际使用场景都能算事故。人家美光也说了这是个“参照系统”。这根本不是谁懂不懂的问题。
另外不进行preconditioning直接测裸盘是原则性、概念性错误，不是方法的问题。别的软件当然可以算进去，但是请保证环境和版本以及其他硬件绝对一致。
评论
是啊，以后不敢了，应该多像j叔学习，大家吹什么我就吹什么
评论
那我就有必要稍微展开讲一下服务器上这种IO是怎么测试的了。
目标是高并发环境那测试的时候模拟的就是高并发环境，因此我们持续开FIO Client直到CPU使用率开始无法承受为止。
你看起来异常高的延迟和异常低的io就是这么来的，这和你的测试方法有本质不同。
8AA60C4C-BA5E-45F8-823E-1EA40561469A.jpeg (159.15 KB, 下载次数: 0)
6077CACB-C99B-4901-83C4-9423B2C8A42A.jpeg (245.31 KB, 下载次数: 0)
评论
麻烦请指出一下，是CPU的大船呢？还是SSD的大船呢？
评论
测试意图不同。这就是不断的提高numjobs，把系统性能测试出来。
看了下楼主的numjobs一直都是16。
一个测试的是系统整体的io性能（10块9300MAX可以提供一个相对很高的ssd io上限），一个测试的ssd的io性能。
评论
数值已经和其他几个认识的行业人士比对过。文章已经被行业文库SSDFANS审核接稿，估计这几天刊登。至于坛友验证嘛，混这个坛的应该都知道不应该和谁提不同意见，所以别指望了吧。我也是2年没怎么来这个坛吹水所以之前才敢发之前那贴，以后不敢了。。。
评论
老哥 这和熟人圈没关系，我觉得这就是实事求是的讨论。电源那会儿我可是和你站一边的，我认为楼主的方法和结论都过于片面（至少不能反映真实情况），所以我才认为有问题。实际上AMD和Intel在这方面是各有优势的，楼主试图用他的测试来说明AMD在存储方案上就是弱，那就不对了。我从不否认Intel在楼主的测试环境中的优势，但是我必须指出的是楼主的测试环境不反应全部生产环境，在高并发场合AMD凭借核心多内存通道多的优势就是能较Intel提供更强的性能。同样在极度注重延迟但是不那么看重并发的场合（比如楼主试图模拟的环境）Intel就是有得天独厚的优势，这本身是一个全看用途而决定的东西，非要说成是一个比另一个强，我觉得就没有意思。
不要挑战熟人圈的所谓“共识”，吃力不讨好，这一点本人在去年8月抛出“千瓦战未来是伪科普”的观点后就深有体会
只是半年多过去了，Intel貌似要制定全新的ATX电源规范了，新规范很有可能在物理层面就不兼容现行规范。当时“千瓦战未来”的坚决拥护者们，现在脸疼不疼？
评论
嘛，没说你，我说的是w开头的某人，半年前追着我的帖子减分，给抵制我观点的人加分；现在依然在追着楼主的帖子减分，给抵制楼主观点的人加分
评论
说实在我一直也是说各有优势。就是个别非要攻击每一个说AMD存在劣势方面的观点。存储方面我认为intel有优势体现在3点：
1. 单盘或者少盘情况下性能发挥强。
2. cpu占用低一些，导致单cpu同样核心数带盘量会高一些，也能留更多资源给软件。测试里CPU占用率intel24核和amd 48核差不多。结果就是两家差不多一颗u和一颗u cpu占用率基本对等。
3. 可拓展性强，intel可以4路、8路，双路四路1hop延迟130-139ns，AMD官方标最多双路，而且对于numa aware做的不是非常好的应用，双路效率就很低了。
评论
其实并没有所谓的裸盘，只要裸盘可以进行fio测试，其实也是有文件系统的，只是这个文件系统不支持posix，不被任何操作系统识别罢了，它只能够由其提供的api操纵，绕开了os，但下面仍然是在自己组织写入lba（假设写入的是lba ssd）。
这个应该多是企业级应用会用到。家用当然需要支持posix。
评论
那你大可以直接把这些写进主楼，现在你主楼里写的是什么？
你第四点里说的这几条 可能也就文件系统和软件生态的结论是相对准确的，IO对CPU的占用率和IO/延迟相关的描述并不能准确反映Rome平台在高并发时的表现。而单CPU带盘量这点，其实也需要分开看，因为并不是所有硬盘都是旗舰级别SSD，rome单CPU有近Intel一倍多的PCIe通道，使用更廉价（更慢）的SSD，EPYC可以轻松组出比Intel廉价的多的存储系统，（因为SSD本身上限较低也没有太大性能担忧）在以容量密度而不是IO为主要目的的时候这个成本优势是Intel很难抗衡的。同样可扩展性我觉得还是见仁见智，因为Rome有着更多的PCIe通道和更快的通道（意味着可以使用更快速的网卡）。
评论
实际上现代文件系统也有直接使用DMA对磁盘进行操作来大幅降低CPU Overhead的功能，比如XFS就有Direct-IO（不过楼主测试中似乎没有使用）
评论
看楼主的参考文献里面有spdk的引用，但没看到哪处是用了spdk测试啊。其实我对这个真的很刚需的感兴趣。
评论
这一段我完全是按照测试数据总结写的，而且的确是只包括磁盘和使用磁盘的必须环境下的总结。网络应该算存和储系统独立的部分了，至少你不能说过个网卡不同ssd不同平台测出来性能的优劣区别就发生很大变化。
另外现在不像以前只有PM1725是百万级iops，目前2代nvme基本普及了。平台成本也得根据市场实际情况定，MSRP基本就是个笑话，据我所知中科大都不会按官网标价采购硬件。
没有直接这么写是因为怕说了没仔细分析的东西再被杠。之前那个预告也是只说了结论几个人就开始杠上而且升到立场层面，结果验证测试过以后除了一个低级错误以外都大差不离。
评论
粗浅地理解，用10块9300max是测整个系统的IO性能，这是对一个整体的评价，所以上了这么多盘来“榨干”epyc的性能。而你的测试限定条件像是在研究“单位”下的IO能力。 有点类似 “多核性能单核性能的感觉”？？？不知道理解的对不对。
评论
个人一般都是做win下测试。FIO里打开direct-io不够么？
评论
这么说也没问题。一般测试里不初始化不格式化就说是裸盘了。
spdk是这篇，我只是引用了一个overhead的图而已。
https://software.intel.com/en-us ... me-drives-with-spdk
评论
也不是，我的是本地磁盘测试，美光是整套带网络系统的测试，另外两个测试系统驱动之类软件环境不太一样。
评论
漏了这一楼，回复一下，这个测试不是比我的结果差不少么？qd16x16T已经能基本跑满了，你用QD32结果也是差不多的，还有job太多性能还可能下降，这个全都试过。
评论
群友来也
评论
顶顶顶
评论
之前我婊科赋，他也在我帖子里头加分减分
减分对我来说真是够侮辱的
评论
妳是不是对服务器市场有误解，没有哪个企业会这样部署的，投资回报率理解吧，建议看下Gartner的Storage方面报告，这不能称为存储系统这个应该叫做家用电脑上挂一块硬盘测速。
如果说自己有的都是优点，自己没有的都是没用的，这样测半天和开鲁大师测SSD有什么区别呢。
1. 首先存储系统怎么就单盘或者少盘了呢，更不用说8275CL主频更高。
2. 先不说准确性误导性，Intel现有的Xeon顶级产品效能和TCO都不如AMD EPYC，何来的单CPU同样核心的情况，另外内存、PCIe通道、功耗，有能领先的产品吗？
3. 可拓展性强不可避免就要谈内存、PCIe通道，如果4S的产品还不如对手2S这也能称为可拓展性强吗，我想请问下Xeon Platinum 9282最多能几路，更不用说这几年都用GPGPU了就没人会用4S、8S，妳可以查查比例，可能DOE/NNSA没有坛友懂拓展性，提存储系统就要提HCI、SDS、Scale-Out，PCIe 3.0上RDMA NVMe-oF性能比4.0的更强吗，这种情况Intel Xeon又有什么样的优势。
如果EPYC 1S就能满足那么我为什么不买1S呢。
Use Single-Socket Servers to Reduce Costs in the Data Center
"By 2021, dedicated x86 single-socket servers will be able to address 80% of the workloads in use in enterprise data centers, up from 20% in 2018”. The common cause is the limitations on memory and input/output (I/O) capacity of individual CPUs. To ensure applications run effectively, businesses are forced to over purchase processing capacity. On older CPU generations, it often requires two CPUs to meet the core counts and the memory requirements."
什么才能称为“高I/O性能数据中心“，什么才能称为“数据中心“，我觉得妳当前并不了解存储系统就出来提了存储系统，美光并不是什么”整套带网络系统的测试“好吗。
Mellanox Ethernet and InfiniBand Solutions Deliver Breakthrough Performance for AMD EPYC™ 7002 Processor Based Data Centers
VMware.JPG (193.79 KB, 下载次数: 0)
如果说妳是专门为了推销Xeon写一个帖子，那根本没有继续讨论的意义了。
评论
兰总说的不少都是事实啊，然而下结论太过草率
本来坛子里很多人就只看结果，兰总列举的一堆火星文对于绝大多数坛友来说要么看不懂要么就提出质疑。
提出质疑吧兰总又开始顾左右而言他，不听解释，只能就演变成站队了。
反正一刀切就完事了
另外有些实话可能是个人的一厢情愿咯
所以说的到底是客观事实还是自我YY呢
在你第一个号被BAN之前应该知道是为什么吧。
评论
糟点不少。。。
1. ？？？存储系统没有少盘的？？？
2. 8275主频高0.3，6139主频低0.2，7702和7R32都是3.3
3. 其他的东西有关么？我这里只讨论存储性能，per watt性能自己可以算，哪家强管我什么事？另外TCO请以实际价格为准。
4. 你确定没有人用4s？人是因为不需要那么多核心所以不上上多路，还是单路真的比多路性价比高？
5. 如果你完全就是在否定某个产品的话，的确也没什么讨论意义。我只能告诉你，现在我认识的渠道EPYC2的利润比xeon高得多，按某些人的理论我应该吹amd
6. 我本来想直接写数据中心的，因为考虑到很多数据中心I/O负载都不高，根据用途而定，所以这么说。
评论
知乎都玩了好几年的玩法了，长篇轰炸显得很专业
我支持楼主的这种码字的精神，不过不认可他草率的结论，尤其是在上一篇EPYC的文章脸都被打烂的情况下
一加一减 算了还是不加分了 你们讨论，我吃瓜就好
评论
1. 那是文章么？那是预告，里面只有阶段性结论，基本没有推导过程亲。所以谈谈经验都不行了？
2. 现在质疑的观点已全部得到验证，Cinebench有效性方面是质疑者没有从硬件角度看问题，质疑者已经回复肯定；SSD质疑者测试方法的原则性问题已经分析证明并实盘重演；系统和BIOS版本的影响已再次组平台测试证明几乎不存在。唯一的一个独立的数据处理上的失误还是我自己找到的。哪里的脸被打烂呢？
评论
请你先弄懂别人说的是啥好不，别再“顾左右而言他”了，也别再造谣了。上次你发的那段话，真的没有一个字是真的。
评论
差距比想象中小，类似于单核性能吧。不是很懂你们这种类似于bbsf102的老阴阳师了，要斗和装机壕去斗啊，掺和这儿干嘛捏？好好说话要死啊。
评论
我也感觉某些人把一些品牌看得比命还重，完全容不得一点质疑。以后还是向j叔学习，光晒不评测比较好。。。
评论
上次我发啥了？
你讨论的东西可高端着呢 我都看不懂的
“顾左右而言他”可不是我讲的
我就看戏哈
评论
所以说到最后你还是没懂镁光的测试是什么意思。衡量生产环境下的性能并不是把跑分软件的参数改到“跑分尽可能高”，而是“尽可能接近生产环境”。生产环境中需要这么多jobs，并且生产环境下并不关心你某块硬盘的速度是多少，而是整套系统能输出多少速度。
这也是我为什么一再强调跨环境测试没有对比性。测试的目的不同测试的方法也会不同。你不认同镁光的数据你可以仿照镁光搭建一个ceph服务器去测一下你的ceph系统是什么io，体会一下“理论值”和“实际性能”的巨大落差。 合成测试只能模拟一种工作负载，而不同工作负载性能表现天差地别。我反对的是（我觉得）你试图用你的测试参数去“以偏概全”，那当然就可以用一个截然不同的测试参数和去得出截然不同的测试结果。你声称你的参数能代表“cpu能发挥多少ssd性能”，或者用你的话说“真实性能”，那我自然可以用这种模拟实际工作负载的参数来表示“真实性能”其实可以是另一回事。你可能是因为你的参数跑出来的ssd分最好看所以采用这种参数，但是衡量实际工作负载（“真实性能”）的时候参数必须模拟真实环境而不是人为挑一个好看的。这又回到了我一开始说的“环境不同测试目的不同测试数据没有可比性”
我并没有全盘否定你的测试试图模拟的环境的意义。不太给面子的其他水友已经从数据中心角度彻底否定你的测试数据的意义了。
我依然希望你澄清的问题：你希望测试的是“SSD自己的性能”还是“SSD一套系统中的性能”
如果是前者，那你应当明白ssd本身的理论性能是最接近raw disk的，你也承认了性能波动是软件造成的。
如果是后者，我希望你能明白一套系统中ssd的表现和工作负载有直接关系，而直接往块状文件系统中按照一个设定好的特定负载写入数据（你主要的测试目标）只是工作负载的一种，而工作负载正好是最容易发挥ssd性能的情况（你选择的参数）则更为罕见。你如果直接就在你数据得出的结论处打住也行，但是你非要引申到存储系统乃至服务器上去，那味就不一样了。因为基于amd的存储系统方案在实际环境中并不弱，例子我也举了，你也可以认为实际环境的其他因素“不算”，但是我认为比脱离生产环境虚空造测试的参数还是能更“算”的。
你的测试中可以得出什么结论呢？
1. 你测试的ssd的性能没有虚标
2. 现代文件系统的效率非常高，几乎没有性能损失
3. Windows文件系统的amd优化比Linux差很多
4. Linux的NTFS驱动依然不行
5. Intel Xeon在你的测试环境下更接近硬盘理论值
但是以上五条并不是“存储系统不高兴用AMD方案”的原因，因为存储系统并不适用于你的测试环境。姑且不论“存储系统不高兴用AMD方案”究竟是不是事实。
评论
我要测的是“SSD一套系统中的性能”。但是我测的本质还是SSD自己的性能，尽量排除其他变量干扰。测出来的只是一个基础一个独立的模块，这个模块内部不好分割，外部有其他因素比如网络组件影响的话单独讨论其他因素就行了，不需要纠结是不是和这个内部磁盘性能还会关联。我的负载目的是把差别体现出来更好分析问题，往里面加顺序访问或者混合读写之类东西就变成测盘子自己了。
美光的那两个测试问题是无关变量太多了，不太好直接对比。暂时没找到我这样1对1的测试，要有我也会引用。裸盘的问题是不太好确定你跑的出数据是不是真的，而且既然文件系统会逐一测试，刻意忽略它也没什么意义。而且裸盘特性和有文件系统可能完全不一样，这是个比较严重的问题。
结论不止这些。两家在完全相同的软件环境下随机访问带宽和延迟有区别，这就是我的原始结论。
说实在我也考虑过用手上web服务器的profile测试，但是预设再各软件之间转换很麻烦，diskspd方面还有些功能不支持。另外我手上只有2个10G网卡。而且就算我这么做我感觉还是有人会杠。当然我也没说做存储方案的人不愿意用AMD平台的唯一原因，但是据我认识的阿里的人、各种运维和aws之类把它们部署在什么地方来看，这个说法没问题。
评论
额 不知道是不是说的同一个人 他倒没扣我分啥的 就是以前某个帖子有了争论，我觉得明明是仁者见仁智者见智的事 他非高高在上的一副不屑的姿态 感觉内心真的很杠
不过，你当时说的电源的事 我其实并不一定同意 因为就我个人而言 确实因为电源掉过数据 换了明显超出够用的电源 确实数据安全上去了 但我也不是专家 自我统计学，身边统计学都是要不得的 agree to disagree吧
评论
你认为无关变量多，但是这是最接近实际使用的测试了。毕竟镁光设计全套方案的时候并不在意9300max到底多快（他们早就测了一万遍了），只在意他们的方案最终能达到什么水平。如果光靠软件版本就能提高7742相对8180近1/3性能的提升，那镁光一定会更新文档和宣传材料（基本的marketing）。你认为不能直接对比，但是客观来讲这就是一个公司对潜在客户提供的两套用途完全一致的解决方案。
你的这个“基础的独立模块”在衡量实际性能中的意义很小（甚至可能完全没有），这是我反对你用这个结论引申到更大的比如存储系统中来解释方案采用率的主要原因。
至于“ 两家在完全相同的软件环境下随机访问带宽和延迟有区别”，那这只能是个“正确的废话”。我不觉得能作为定型结论。
而“ 裸盘的问题是不太好确定你跑的出数据是不是真的，而且既然文件系统会逐一测试，刻意忽略它也没什么意义。而且裸盘特性和有文件系统可能完全不一样，这是个比较严重的问题。” 这个我觉得你多虑了，厂商标理论值几乎都是照着裸盘标的，因为文件系统和文件系统是真的完全不一样，你说厂商又应该以什么系统上的什么文件系统为基准呢？A文件系统太慢了我们可以用B，那标A的厂商不就比标B的厂商吃亏了？结果到最后还不如标裸盘有参考价值。
所以我现在是明白了，你测试的是对你而言最有意义的测试数据，你希望知道在你的系统里单硬盘的上限在哪里你，希望知道你需要什么系统来更好发挥你的硬盘，那我觉得这就很OK了，没必要非要往大了去说，你越往大了去说越容易招致争议，尤其是你还想用你的比较局限的结论去解释一个现象。你说的现象基于你的观测，所以我不讨论你观测到的现象是否正确，因为我们谁都不知道谁观测到的更全面，我只说你尝试解释这个现象的理论不正确，因为你测试中的性能差异不能代表生产环境的性能差异。
评论
仔细看了一下你那个文，感觉还是比较在理的。一般电源内部功率元器件都会大幅超额提供，比如30a的负载一般会给45-60a甚至更大的管子。标称功率限制主要在工作温度方面，这是一个功率对时间的积分，瞬态功率持续时间很短根本积不出来，所以和电源持续功率没什么关系。。。
瞬时高功率我觉得还是应该看瞬态响应（transient response）测试，会不会产生高纹波长时间不恢复，甚至环路不稳定。这方面国外几个评测站做的比国内好多了。
不过还是建议不要过于针对个人吧。虽然从心理学上说直接对人不对事在撕逼中的优势很大，尤其对于不明真相的吃瓜群众。
看懂了~~~
暖和吗？
评论
实际使用也分很多种，区别很大。我之前也说了，美光这个延迟在某些应用中问题很大。我的目的是测量磁盘在不同平台的差距，怎么测呢？当然需要在正确的环境下采用最能表现出差别的测试方法。我的结论最后也没直接说他性能具体一定差多少，而且也写成“从侧面看出”没有说绝对只是因为这个因素。掺入其他负载性能差距可能变小，但是我做的只是提出这个需要注意的问题，不可能代替每个运维去跑他们的负载，更不可能去玩网卡。
厂商标称对于已经precondition过的raw测试结果一般都会留一点余量。比如1725a只标了800k，d700只标了835k，实际测试810k、850k。我觉得他们也考虑了系统损耗之类因素让客户到手能跑到他们标的数。而且如果他们是用intel平台验证的话，各个比较新的FS OS下出来的数值基本都是统一的。
另外不同版本系统软件之间是能差很多。个人遇到过PM1725在更新AIR3Q固件以后4K扇区下稳态写性能直接翻番，以及几年前老版ubuntu跑出来根本不能看。RHEL 7.6已经是前年的东西了。美光文件不更新也比较常见吧，他家的ssd测试指南从P420m以后就没更新过。这种和别的厂商合作的测试还有窗口的问题，后来更新不一定容易。
我加几个定语算了，不过看完的人应该也都知道我是在测本地随机性能。实际上我顺便把我以前存的各种profile都在IOmeter下跑过一遍了，所以我觉得那两个文件差距是第三方影响因素导致。
另外发现了这个，开头那个表反而好像没说怎么得到的。这个的介绍有点迷，不过可以看看每一项测试延迟带宽对应关系。
micron_fio.PNG (393.41 KB, 下载次数: 0)
评论
我倒觉得实际应用下面农企方案的劣势在于如果非系统集成商或者野鸡系统集成商自己整一套系统的话翻车几率会更大，而不是什么单盘峰值性能之类的，单路128根PCI-E通道它不香么，存储密度和TCO都太强了
翻车的名场面包括什么金士顿特大号企业级U盘被农企EPYC SoC SATA控制器戴绿帽子啦（农企临时工承诺Naples下一个AGESA修复），翻车现场https://www.chiphell.com/forum.php?mod=viewthread&tid=2182428
还有什么华为ES3000系列早期型号土垃圾SSD AGESA1003ABBA不翻车，AGESA1004翻车啦（然而农企临时工被剥夺了华为产品的背锅权，咖喱给给），这个是道听途说的
TIM截图20200311050319.png (17.62 KB, 下载次数: 0)
（震惊！农企临时工居然会说西班牙语）
然而正经搭建的话肯定不会这么瓜菜代的，甚至SSD会干脆上定制的固件，所以上面的问题根本不算什么问题
评论
128通道一般主板都只会做一部分吧，位置不够。另外测试的时候epyc2内存不插满或者混插就变成双通道带宽；xgmi带宽是16-18-25G的说法都有，还都是官方的；每次开机自检和插了阵列卡一样。这些我都不敢发主贴里。
还有我说的不只是单盘而是每个盘，最后包括了一个多盘叠加的简单测试。
说实在我不太喜欢杠，要杠的话哪里都能找到问题。包括本坛某些人奉为天书的39x评测，举个例子说intel没有MOP绝对不妥，延迟测试软件测出来比intel官方软件高一倍（虽然我知道他想说什么）；包括STH对epyc2双路互联和内存优化模式的说明很多地方没有官方根据；甚至包括AMD官方资料IFOP只写了32B/c和事实不符。
评论
对，我那文章也并不是身边统计学，只是基础的逻辑辨析。我自己也在硬件升级的过程中淘汰过两三个旧电源，那种功率明明够，但用着就是有问题的电源。
但这些经历其实更加说明“千瓦战未来”是伪科普，因为随着硬件的升级，电源标准也在升级，淘汰你电源的除了瓦数不够，还有电源标准落后。
在旧有的标准下，仅仅是多留出一些瓦数，就能算“战未来”了吗？Intel这次对ATX电源标准的升级，已经回答了这一点：不算。在新标准下，现有旧标准电源很有可能在物理层面就不兼容，连未来的方向都没搞清，仅在眼下的方向上多迈出几步，谈何战未来？
“千瓦战未来”的论调，颇像那些固守“大舰巨炮”思想的旧日本海军昭和遗毒，各种“460mm口径战未来”、“508mm口径战未来”的想法，已经被航母时代无情的碾碎了。方向错了，走多远都不是未来。
评论
来来来，有问题正面刚。你说说mop在哪？你说说你intel官方软件那个buffer在缓存范围内，一动延迟就跟着动的合理性在哪？和我软件可比性在哪？
评论
说起电源 我个人是不认为千瓦战未来的。。。就像你说的那样 都是单卡单U 一个瞬态表现好的550W电源没问题 一个毫无瞬态承载力的1000W电源却会重启
个人看法 当年的老电源550W战单卡单U 现在的话只要不是双超的太狠仍然可以用
买新电源战单卡单U建议650W 双卡建议1000W 说起来那个NZXT H1机箱自带的电源不也是650W 人家是ITX 最多单卡单U
至于瞬态不行 这不是电源瓦数能罩得住的事情 还是别买那些很可疑的大功率电源吧
评论
个人看法，买当下最新标准的、额定输出功率和峰值输出功率hold的电源即可，可以留些余量应对一些小升级，比如加挂硬盘。
指望无脑买大电源去“战未来”，不科学，不理智，不合逻辑。
评论
我觉得跟非公显卡功耗配置比较奔放也有关系
Fenghuang的机器也就配了个275W电源，跟傻多戴的商用核显台式机一个水平
评论
我16年末买了1000W白金 主要是设计平台的时候留下双显卡的余量 不过一直到现在我也没有上双显卡。。。
我这还算好的 明知道自己没双显卡需求然后盲目上大电源的才是屑
评论
做电源，做SSD，做洋垃圾服务器，道理都是一样的，归根到底就是生意，角度不同，看到的东西也就不同。完完全全可以做到：
1、测试高大上，数据伟光正
2、得出结论前先过一遍屁股
虽然论坛人人都可以发帖，然鹅，如果不劳资天下第一搞个结论，就没人看你帖子，回复只能一个觉厉，楼主可能不懂某些人，某些人可能也不懂楼主，虽然我觉得楼主是懂的
也许这就是苏神吧，装逼贼有风险，也贼有收益
参考下面贴的datasheet，我认为楼主做的是抽象理论测试，而不是一个商用系统测试。得出的结论是用于自己玩的，测得挺好，但没用？没用就没用呗，没用的事儿还少么。
评论
1. 代码dirty hack，测试平台矮小挫
2. 得出结论前先迫害一遍臭鼬
评论
看了下，想法还是好的，但测试过于繁杂，会淹没很多关注点，同时带来一些硬伤。如果后期主打SSDFANS这种专业自媒体，没必要加入windows。这些数据中心级盘，放到windows上主要是娱乐为主，就算是指标高一点（很有可能），但其实还是看个乐呵。
我建议强化（专业化）一下Linux下的测试。本人也比较关心Rome在Linux下的表现。如果强化测试，我有如下建议：
1. 提供更详细的测试平台信息。Linux发行版及kernel的版本，尽量使用轻量发行版，甚至kernel也有优化空间；主板系统，最好采用Rome原生主板，Naples这代主板升级来的就比较low。
2. 提供fio下linux下的详细参数（我看你提供的是windows下的fio参数？）。至少对比几个引擎：psync, aio, io_uring。io_uring需最近几个发行版，但最近几个发行版都在大幅改进，所以最好是5.5或5.6的kernel。
3. 尽量提供最强性能的对比。建议，fio线程数至少匹配cpu的core核心数。（建议从core数测到硬件线程数）（不一定是最优，但也是近优。原因：很多盘，其实本身还是有缺陷的。比如Intel的p4800x，其性能明显被主控拖累。）当线程数比较大时，可适当减小iodepth参数，但应该影响不大。只在一个参数下的性能有差距是很正常的。这并不能得出rome弱于cascadelake xeon（或amd平台弱于intel平台）的结论。如果换一个参数，我rome就可能超过了你，最多算是半斤八两。相反，Linux下裸盘IOPS性能相当，说明两块U的本底IO性能基本无差异。
4. IO延迟的测量应该更谨慎。延迟对测试系统要求非常高。同时，在IO并发比较高的情况下（你的16x16T）测试系统的延迟因该不是关注点。最后，如果在epyc这样的架构上，延迟高一点也还正常，关键是intel你能低多少？300多us差个20us，远不如我高通道数有意义。
如果对上面的问题还有兴趣，我可以提供一些帮助。
评论
抱歉昨天比较忙木有回。既然要看datasheet，建议看得仔细一些，因为这两个文件里的地雷不少，建议不要踩到。
目前已经发现的华点：
1. 系统驱动之类软件不一样，这个不用多说了吧。另外提醒你一下，RHEL更新换代很慢，7.6和7.7版本差了接近1年。
system.PNG (90.79 KB, 下载次数: 0)
2. 楼上第一帖指出的应该是网络环境下的测试。非本地测试本身不一定是问题，但是建议你看一下第十四页的测试说明：
intel：
amd：
多开数量都不一样怎么能比？这种条件上的差别这两个文件各种地方区别挺多的，可能因为这两个测试间隔时间比较长方案有改动吧。所以说建议仔细看，不要踩雷。
3. 他的测试里也有本地测试的结果。虽然条件说明比较谜，但是我们可以从延迟和对应的IOPS带宽的角度来看看，结果比我的还狠。
为什么这么看，是因为同样的设备下带宽和延迟是正相关的。我记得storagereview就经常用带宽-延迟曲线做统计。
micron_fio.PNG (393.41 KB, 下载次数: 0)
其实我一直不太明白为什么楼上总是非要把理论测试和实际测试分开。理论测试就一定要忽视已知的平台的重大影响因素做非常纯的硬盘测试？实际测试就必须针对某一种机型配置和某一种软件某一个特定负载环境？为什么不能结合两者优点做一个普适性强一点而且环境比较真实的测试？
另外为什么理论测试就一定和实际负载环境表现无关？那以后大家都不要做理论测试了，反正和实际没什么关系？我的测试设计思路就是扫清平台和硬盘方向的瓶颈而不是要掺杂其他东西，等会我详细说一下我的实验构建思路。就好比3990x玩单核游戏比i3弱，你就能以此否认3990x比i3强了？你最多只能说这个游戏下i3强吧。
上一贴我举数据库应用的例子说实际应用强他说我混淆概念，这回我按硬盘的性能说了他说我不真实。。。说实在我咋觉得只要结论里有某平台io性能相对比较差，他就开始挑毛病。。。
——————————————————————————————
另外我觉得你受到了某喜欢扣分的人影响。我只能提醒你，没有脑子是不能懂得屁股应该往哪放的。不要犯另一些与红有关的人的错误。
评论
我几年前就因为一篇长文进SSDFANS作者组了。这篇文你可以看看我16年的发帖记录。他们什么方向都可以投。
1. linux版本我已经标明了吧。主板是H11SSL新版，bios是原生支持rome的。我觉得反而是桌面级强行升级主板比较恶心，各家企业级基本都是直接升，最多换个bios芯片。rome是soc，和哪一代主板没什么关系吧。
2. linux忘了写了，我测的是libaio。
3. 实际上直接匹配那么多线程性能反而会降低。我在去年拿到7452的时候就做过测试，16T差不多性能最好，32T也差不多但是再加性能就下降了。对于QD来说16-32基本完全发挥，再加性能倒是不会降低，不过考虑和以前的数据匹配我还是用QD16了。
简单说一下为什么我要采取QD16x16T这种最大随机带宽的方式做这个对比。说实在我以为很多人都知道的，原因其实很简单，我之前iometer把以前SSD横测的那些profile都跑了一遍，发现CPU和平台引起的瓶颈，或者说平台对于存储性能的影响，主要就是在高IOPS的顺序4k和随机4k上，其他方面区别很小基本就是看盘子本身，这是个有些负载体现明显有些体现不明显的问题，而不是各有所长。顺序4k我觉得实际使用上意义不如随机4k那么大所以我就选了随机。
当然你也可以说你的软件或者网卡之类硬件瓶颈会导致跑不到那么高iops，但是这不代表这方面的差距不存在，或者说两个平台磁盘性能有差距是错的。说实在美光用的100g网卡现在已经算过时了吧。就像上面那个例子，你用不到那么多核心不代表3990x就和i3性能差不多甚至不如i3.
4. 所以我后面单独强调测consistency要用核心比较多的u。我总结延迟只是顺手而已，毕竟带宽延迟是两个性能的代表。通道数差别我觉得不要高估，因为主板一般不会给你做那么多上去，走线走不下。
另外p4800x我测的时候的确发现这种盘cpu占用比较大，所以牵制了T1下的性能。
pm我一下qq或者微信？
评论
1. 不仅存在macro-op而且存在pre-decode和macro-op-fusion。这里有比较详细的说明。另外我记得你的文只说了amd支持macrofusion没说intel也支持。
https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)#Instruction_Queue_.26_MOP-Fusion
这个macro-op的称呼现在intel自己的确不常用，intel现在一般称他为macro-instruction或者直接叫instruction。但是intel的确也是偶尔将这个概念叫成macro-op过的。另外谷歌翻第三方论文里也经常直接称他为macro-op，直接说intel不存在mop不妥吧。
macroop.jpg (106.68 KB, 下载次数: 0)
我说“我大概知道你是什么意思”就是说intel的mop的概念和amd差别比较大，基本就是x86 instruction。
2. mlc的默认buffer很大，200000KB，缓存装不下吧。刚测试了一下，只要window在L2容量范围内，buffer不要设置太小，结果基本是稳定的。另外这是intel官方认证的工具，至少测intel cpu没问题吧。
你那个测试软件记得你之前和我说是“核心到核心”的延迟所以比较高，但是高的优点太多了，相对c2c测试，ring和mesh基本就是翻倍（ring加20ns左右，mesh加40ns左右），你也没说原因。后来测大型北桥的时候结果也有问题然后你换了软件，可能其他方面比如snoop策略影响比较大不是纯的总线或者核心到核心延迟。
评论
两个完全不同的定义，你来混淆个锤子概念喃，另外我没说过intel有macro fusion？
QQ截图20200312085245.png (40.82 KB, 下载次数: 0)
QQ截图20200312085309.png (51.78 KB, 下载次数: 0)
我这写的啥？
mlc稳定，我问问你，我在你所谓的L2范围内我以2K为步进的windows测试了一遍，延迟从33到53都有，而且不是个别是连续一串，它稳不稳定？我问问你，我window设为2K的时候，互联延迟是怎么测出来只有2.2个时钟周期的，他的意义是什么？ 我问问你，我之前的软件算上nb频率之后能和amd的官方数据对上，你mlc的结果对的上吗？
评论
1. 我是说MOP这个概念是存在的，不仅别人用过官方也用过，就不能说他不存在。你应该说intel的mop概念上和原始的x86 instruction差不多。
后面一段没注意到是我的锅，不过篇幅上真的离这个概念说明非常远，而且你前面一段不仅直接说intel没有mop这一说而且说intel是直接解码成μop，真的很容易造成歧义。实际是概念上有mop而且是macro fusion以后再decode，最好改改这个表述。
2. 我这边mlc之前测试3990x和官方的标称也差不多。你说的问题我一个都没遇到过，建议检查一下软件版本。
另外stride size这个-l的参数是不支持c2c延迟的。
评论
没错，我就是这么说的，通过上下文很容易看出来我在说的macro ops是什么，你非要扯x86就是intel的macro ops，我除了认为你是杠精，我还能说什么？macro fusion我也详细说明了，macro fusion这段本来同时给两家写的，所以下文才会有intel特有的micro fusion这个说法，因为这是amd没有，你别给我说你macro fusion那一段你又没看见。
那我很抱歉了，我就是用的就是intel官方最新版，使用的你所谓的c2c测试测的，
你敢说你那个c2c测出来amd平台上ccx之间那五十几毫秒能和amd的数据中的本地延迟对的上？
来你给我解释解释这个结果的合理性和意义在哪？
bat文件内容：for /l %%i in (2,2,512) do mlc --c2c_latency -c0 -w2 -C%%i -b512 >> res.txt
测试使用的3950x
--c2c_latency -c0 -w2 -C2 -b512
Latency = 2.2 core clocks (0.6 ns)
--c2c_latency -c0 -w2 -C4 -b512
Latency = 11.9 core clocks (3.4 ns)
--c2c_latency -c0 -w2 -C6 -b512
Latency = 24.9 core clocks (7.1 ns)
--c2c_latency -c0 -w2 -C8 -b512
Latency = 32.3 core clocks (9.2 ns)
--c2c_latency -c0 -w2 -C10 -b512
Latency = 35.3 core clocks (10.1 ns)
--c2c_latency -c0 -w2 -C12 -b512
Latency = 37.4 core clocks (10.7 ns)
--c2c_latency -c0 -w2 -C14 -b512
Latency = 38.1 core clocks (10.9 ns)
--c2c_latency -c0 -w2 -C16 -b512
Latency = 40.7 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C18 -b512
Latency = 40.3 core clocks (11.5 ns)
--c2c_latency -c0 -w2 -C20 -b512
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C22 -b512
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C24 -b512
Latency = 44.8 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C26 -b512
Latency = 43.4 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C28 -b512
Latency = 45.6 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C30 -b512
Latency = 45.9 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C32 -b512
Latency = 46.5 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C34 -b512
Latency = 46.4 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C36 -b512
Latency = 44.4 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C38 -b512
Latency = 44.6 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C40 -b512
Latency = 44.0 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C42 -b512
Latency = 45.8 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C44 -b512
Latency = 45.8 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C46 -b512
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C48 -b512
Latency = 46.1 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C50 -b512
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C52 -b512
Latency = 45.3 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C54 -b512
Latency = 48.4 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C56 -b512
Latency = 50.1 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C58 -b512
Latency = 45.9 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C60 -b512
Latency = 46.5 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C62 -b512
Latency = 47.0 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C64 -b512
Latency = 49.3 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C66 -b512
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C68 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C70 -b512
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C72 -b512
Latency = 49.8 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C74 -b512
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C76 -b512
Latency = 46.8 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C78 -b512
Latency = 46.8 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C80 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C82 -b512
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C84 -b512
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C86 -b512
Latency = 42.9 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C88 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C90 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C92 -b512
Latency = 45.8 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C94 -b512
Latency = 48.4 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C96 -b512
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C98 -b512
Latency = 47.8 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C100 -b512
Latency = 47.7 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C102 -b512
Latency = 49.5 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C104 -b512
Latency = 43.6 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C106 -b512
Latency = 44.1 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C108 -b512
Latency = 45.4 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C110 -b512
Latency = 43.8 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C112 -b512
Latency = 45.7 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C114 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C116 -b512
Latency = 47.7 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C118 -b512
Latency = 48.0 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C120 -b512
Latency = 48.2 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C122 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C124 -b512
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C126 -b512
Latency = 48.3 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C128 -b512
Latency = 49.3 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C130 -b512
Latency = 41.9 core clocks (12.0 ns)
--c2c_latency -c0 -w2 -C132 -b512
Latency = 41.7 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C134 -b512
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C136 -b512
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C138 -b512
Latency = 43.4 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C140 -b512
Latency = 43.8 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C142 -b512
Latency = 44.1 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C144 -b512
Latency = 45.5 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C146 -b512
Latency = 45.5 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C148 -b512
Latency = 45.4 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C150 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C152 -b512
Latency = 44.9 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C154 -b512
Latency = 46.9 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C156 -b512
Latency = 48.2 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C158 -b512
Latency = 46.9 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C160 -b512
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C162 -b512
Latency = 48.7 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C164 -b512
Latency = 48.6 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C166 -b512
Latency = 49.7 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C168 -b512
Latency = 50.3 core clocks (14.4 ns)
--c2c_latency -c0 -w2 -C170 -b512
Latency = 50.0 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C172 -b512
Latency = 38.4 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C174 -b512
Latency = 41.0 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C176 -b512
Latency = 39.6 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C178 -b512
Latency = 39.6 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C180 -b512
Latency = 40.5 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C182 -b512
Latency = 41.3 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C184 -b512
Latency = 41.2 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C186 -b512
Latency = 41.5 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C188 -b512
Latency = 41.4 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C190 -b512
Latency = 42.4 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C192 -b512
Latency = 42.1 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C194 -b512
Latency = 41.1 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C196 -b512
Latency = 42.3 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C198 -b512
Latency = 43.7 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C200 -b512
Latency = 42.2 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C202 -b512
Latency = 42.9 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C204 -b512
Latency = 43.8 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C206 -b512
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C208 -b512
Latency = 44.3 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C210 -b512
Latency = 43.8 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C212 -b512
Latency = 45.6 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C214 -b512
Latency = 44.6 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C216 -b512
Latency = 44.4 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C218 -b512
Latency = 45.5 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C220 -b512
Latency = 45.4 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C222 -b512
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C224 -b512
Latency = 46.7 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C226 -b512
Latency = 47.8 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C228 -b512
Latency = 47.4 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C230 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C232 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C234 -b512
Latency = 46.6 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C236 -b512
Latency = 46.8 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C238 -b512
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C240 -b512
Latency = 49.4 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C242 -b512
Latency = 49.4 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C244 -b512
Latency = 50.1 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C246 -b512
Latency = 48.8 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C248 -b512
Latency = 49.8 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C250 -b512
Latency = 48.1 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C252 -b512
Latency = 49.4 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C254 -b512
Latency = 50.2 core clocks (14.4 ns)
--c2c_latency -c0 -w2 -C256 -b512
Latency = 49.0 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C258 -b512
Latency = 33.3 core clocks (9.5 ns)
--c2c_latency -c0 -w2 -C260 -b512
Latency = 33.9 core clocks (9.7 ns)
--c2c_latency -c0 -w2 -C262 -b512
Latency = 33.2 core clocks (9.5 ns)
--c2c_latency -c0 -w2 -C264 -b512
Latency = 33.2 core clocks (9.5 ns)
--c2c_latency -c0 -w2 -C266 -b512
Latency = 33.5 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C268 -b512
Latency = 33.4 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C270 -b512
Latency = 34.1 core clocks (9.8 ns)
--c2c_latency -c0 -w2 -C272 -b512
Latency = 34.1 core clocks (9.8 ns)
--c2c_latency -c0 -w2 -C274 -b512
Latency = 33.6 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C276 -b512
Latency = 34.7 core clocks (9.9 ns)
--c2c_latency -c0 -w2 -C278 -b512
Latency = 35.0 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C280 -b512
Latency = 34.8 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C282 -b512
Latency = 34.7 core clocks (9.9 ns)
--c2c_latency -c0 -w2 -C284 -b512
Latency = 35.5 core clocks (10.2 ns)
--c2c_latency -c0 -w2 -C286 -b512
Latency = 35.7 core clocks (10.2 ns)
--c2c_latency -c0 -w2 -C288 -b512
Latency = 35.4 core clocks (10.1 ns)
--c2c_latency -c0 -w2 -C290 -b512
Latency = 35.5 core clocks (10.1 ns)
--c2c_latency -c0 -w2 -C292 -b512
Latency = 35.1 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C294 -b512
Latency = 36.1 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C296 -b512
Latency = 36.0 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C298 -b512
Latency = 36.4 core clocks (10.4 ns)
--c2c_latency -c0 -w2 -C300 -b512
Latency = 37.2 core clocks (10.7 ns)
--c2c_latency -c0 -w2 -C302 -b512
Latency = 36.3 core clocks (10.4 ns)
--c2c_latency -c0 -w2 -C304 -b512
Latency = 37.6 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C306 -b512
Latency = 37.0 core clocks (10.6 ns)
--c2c_latency -c0 -w2 -C308 -b512
Latency = 36.6 core clocks (10.5 ns)
--c2c_latency -c0 -w2 -C310 -b512
Latency = 37.5 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C312 -b512
Latency = 36.8 core clocks (10.5 ns)
--c2c_latency -c0 -w2 -C314 -b512
Latency = 37.0 core clocks (10.6 ns)
--c2c_latency -c0 -w2 -C316 -b512
Latency = 37.9 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C318 -b512
Latency = 36.9 core clocks (10.6 ns)
--c2c_latency -c0 -w2 -C320 -b512
Latency = 38.8 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C322 -b512
Latency = 37.8 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C324 -b512
Latency = 37.3 core clocks (10.7 ns)
--c2c_latency -c0 -w2 -C326 -b512
Latency = 38.4 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C328 -b512
Latency = 37.9 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C330 -b512
Latency = 38.2 core clocks (10.9 ns)
--c2c_latency -c0 -w2 -C332 -b512
Latency = 38.8 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C334 -b512
Latency = 38.3 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C336 -b512
Latency = 37.9 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C338 -b512
Latency = 39.1 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C340 -b512
Latency = 38.9 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C342 -b512
Latency = 39.9 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C344 -b512
Latency = 39.3 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C346 -b512
Latency = 38.3 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C348 -b512
Latency = 39.1 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C350 -b512
Latency = 39.3 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C352 -b512
Latency = 40.5 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C354 -b512
Latency = 40.6 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C356 -b512
Latency = 39.8 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C358 -b512
Latency = 39.5 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C360 -b512
Latency = 40.3 core clocks (11.5 ns)
--c2c_latency -c0 -w2 -C362 -b512
Latency = 39.8 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C364 -b512
Latency = 41.0 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C366 -b512
Latency = 40.9 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C368 -b512
Latency = 40.7 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C370 -b512
Latency = 42.6 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C372 -b512
Latency = 41.1 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C374 -b512
Latency = 41.4 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C376 -b512
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C378 -b512
Latency = 41.7 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C380 -b512
Latency = 42.4 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C382 -b512
Latency = 41.4 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C384 -b512
Latency = 40.6 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C386 -b512
Latency = 42.1 core clocks (12.0 ns)
--c2c_latency -c0 -w2 -C388 -b512
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C390 -b512
Latency = 43.0 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C392 -b512
Latency = 43.2 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C394 -b512
Latency = 43.1 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C396 -b512
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C398 -b512
Latency = 43.7 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C400 -b512
Latency = 43.9 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C402 -b512
Latency = 42.5 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C404 -b512
Latency = 44.2 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C406 -b512
Latency = 44.2 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C408 -b512
Latency = 43.5 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C410 -b512
Latency = 43.8 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C412 -b512
Latency = 44.5 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C414 -b512
Latency = 44.2 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C416 -b512
Latency = 43.9 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C418 -b512
Latency = 44.6 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C420 -b512
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C422 -b512
Latency = 45.0 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C424 -b512
Latency = 45.3 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C426 -b512
Latency = 43.9 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C428 -b512
Latency = 44.2 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C430 -b512
Latency = 45.5 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C432 -b512
Latency = 45.6 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C434 -b512
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C436 -b512
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C438 -b512
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C440 -b512
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C442 -b512
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C444 -b512
Latency = 46.9 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C446 -b512
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C448 -b512
Latency = 46.4 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C450 -b512
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C452 -b512
Latency = 46.2 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C454 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C456 -b512
Latency = 48.7 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C458 -b512
Latency = 47.3 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C460 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C462 -b512
Latency = 48.1 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C464 -b512
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C466 -b512
Latency = 46.3 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C468 -b512
Latency = 47.8 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C470 -b512
Latency = 46.3 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C472 -b512
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C474 -b512
Latency = 47.7 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C476 -b512
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C478 -b512
Latency = 46.6 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C480 -b512
Latency = 47.7 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C482 -b512
Latency = 48.7 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C484 -b512
Latency = 48.0 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C486 -b512
Latency = 47.9 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C488 -b512
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C490 -b512
Latency = 48.1 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C492 -b512
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C494 -b512
Latency = 46.7 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C496 -b512
Latency = 47.7 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C498 -b512
Latency = 47.9 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C500 -b512
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C502 -b512
Latency = 50.0 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C504 -b512
Latency = 49.9 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C506 -b512
Latency = 49.3 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C508 -b512
Latency = 49.5 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C510 -b512
Latency = 49.0 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C512 -b512
Latency = 48.9 core clocks (14.0 ns)
评论
我有说过我不在杠定义上的毛病么？我有说过我喜欢这么干么？你找我的吧。。。
我刚简单跑了一下，我这边比较正常。还有ccx内我没有测出来50ns。具体看我单独发的讨论架构的文。
c2c.png (562.77 KB, 下载次数: 0)
mlc.PNG (25.49 KB, 下载次数: 0)
评论
杠不杠不是你自己说自己不杠就算的。
别扯有的没有的，你就说说我这结果是怎么回事吧，上周新装的系统干干净净，mlc最新版，你能解释出来，我就承认你mlc的结果有效，ccx内 L2范围内33周期到53周期，而ccx间测试结果是33纳秒到59纳秒。
我的软件有什么问题我也是明说的，老软件没有考虑snoop filter的存在，所以在桌面的ryzen没有snoop filter中可以得出准确而且非常稳定的结果。
评论
你hwprefetch关了没？没有的话加上-e -r。我这里重演不出来你的问题。
我说的是你的软件对intel平台，测试准确么？intel自己的工具，自己的u都测不准是不会发的。
我自己是不是在杠都不是我自己说了算？？？
评论
来嘛 新跑的 你说说稳不稳定？
--c2c_latency -c0 -w2 -C2 -b512 -e -r
Latency = 2.3 core clocks (0.6 ns)
--c2c_latency -c0 -w2 -C4 -b512 -e -r
Latency = 12.0 core clocks (3.4 ns)
--c2c_latency -c0 -w2 -C6 -b512 -e -r
Latency = 25.1 core clocks (7.2 ns)
--c2c_latency -c0 -w2 -C8 -b512 -e -r
Latency = 31.0 core clocks (8.9 ns)
--c2c_latency -c0 -w2 -C10 -b512 -e -r
Latency = 35.1 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C12 -b512 -e -r
Latency = 37.9 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C14 -b512 -e -r
Latency = 40.9 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C16 -b512 -e -r
Latency = 41.4 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C18 -b512 -e -r
Latency = 42.0 core clocks (12.0 ns)
--c2c_latency -c0 -w2 -C20 -b512 -e -r
Latency = 42.8 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C22 -b512 -e -r
Latency = 43.2 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C24 -b512 -e -r
Latency = 44.6 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C26 -b512 -e -r
Latency = 44.1 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C28 -b512 -e -r
Latency = 44.1 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C30 -b512 -e -r
Latency = 45.7 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C32 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C34 -b512 -e -r
Latency = 47.3 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C36 -b512 -e -r
Latency = 46.1 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C38 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C40 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C42 -b512 -e -r
Latency = 46.5 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C44 -b512 -e -r
Latency = 45.4 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C46 -b512 -e -r
Latency = 47.7 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C48 -b512 -e -r
Latency = 46.6 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C50 -b512 -e -r
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C52 -b512 -e -r
Latency = 45.2 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C54 -b512 -e -r
Latency = 46.4 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C56 -b512 -e -r
Latency = 47.7 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C58 -b512 -e -r
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C60 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C62 -b512 -e -r
Latency = 46.9 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C64 -b512 -e -r
Latency = 47.7 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C66 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C68 -b512 -e -r
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C70 -b512 -e -r
Latency = 48.4 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C72 -b512 -e -r
Latency = 48.3 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C74 -b512 -e -r
Latency = 44.4 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C76 -b512 -e -r
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C78 -b512 -e -r
Latency = 45.8 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C80 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C82 -b512 -e -r
Latency = 49.1 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C84 -b512 -e -r
Latency = 49.8 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C86 -b512 -e -r
Latency = 43.5 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C88 -b512 -e -r
Latency = 44.0 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C90 -b512 -e -r
Latency = 46.1 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C92 -b512 -e -r
Latency = 46.6 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C94 -b512 -e -r
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C96 -b512 -e -r
Latency = 47.8 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C98 -b512 -e -r
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C100 -b512 -e -r
Latency = 48.3 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C102 -b512 -e -r
Latency = 48.8 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C104 -b512 -e -r
Latency = 43.6 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C106 -b512 -e -r
Latency = 43.6 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C108 -b512 -e -r
Latency = 44.2 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C110 -b512 -e -r
Latency = 45.6 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C112 -b512 -e -r
Latency = 46.3 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C114 -b512 -e -r
Latency = 46.3 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C116 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C118 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C120 -b512 -e -r
Latency = 50.0 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C122 -b512 -e -r
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C124 -b512 -e -r
Latency = 48.7 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C126 -b512 -e -r
Latency = 48.0 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C128 -b512 -e -r
Latency = 49.7 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C130 -b512 -e -r
Latency = 42.3 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C132 -b512 -e -r
Latency = 42.1 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C134 -b512 -e -r
Latency = 43.7 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C136 -b512 -e -r
Latency = 44.2 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C138 -b512 -e -r
Latency = 43.4 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C140 -b512 -e -r
Latency = 43.7 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C142 -b512 -e -r
Latency = 44.9 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C144 -b512 -e -r
Latency = 44.7 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C146 -b512 -e -r
Latency = 45.8 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C148 -b512 -e -r
Latency = 45.9 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C150 -b512 -e -r
Latency = 45.6 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C152 -b512 -e -r
Latency = 46.6 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C154 -b512 -e -r
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C156 -b512 -e -r
Latency = 47.9 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C158 -b512 -e -r
Latency = 47.4 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C160 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C162 -b512 -e -r
Latency = 47.5 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C164 -b512 -e -r
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C166 -b512 -e -r
Latency = 49.6 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C168 -b512 -e -r
Latency = 50.9 core clocks (14.6 ns)
--c2c_latency -c0 -w2 -C170 -b512 -e -r
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C172 -b512 -e -r
Latency = 40.4 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C174 -b512 -e -r
Latency = 39.2 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C176 -b512 -e -r
Latency = 41.0 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C178 -b512 -e -r
Latency = 39.5 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C180 -b512 -e -r
Latency = 39.7 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C182 -b512 -e -r
Latency = 40.8 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C184 -b512 -e -r
Latency = 41.2 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C186 -b512 -e -r
Latency = 41.1 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C188 -b512 -e -r
Latency = 41.6 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C190 -b512 -e -r
Latency = 42.3 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C192 -b512 -e -r
Latency = 41.1 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C194 -b512 -e -r
Latency = 42.5 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C196 -b512 -e -r
Latency = 42.6 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C198 -b512 -e -r
Latency = 42.8 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C200 -b512 -e -r
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C202 -b512 -e -r
Latency = 42.9 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C204 -b512 -e -r
Latency = 44.5 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C206 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C208 -b512 -e -r
Latency = 43.5 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C210 -b512 -e -r
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C212 -b512 -e -r
Latency = 45.7 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C214 -b512 -e -r
Latency = 43.2 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C216 -b512 -e -r
Latency = 44.7 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C218 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C220 -b512 -e -r
Latency = 45.3 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C222 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C224 -b512 -e -r
Latency = 48.1 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C226 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C228 -b512 -e -r
Latency = 47.9 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C230 -b512 -e -r
Latency = 46.8 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C232 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C234 -b512 -e -r
Latency = 47.7 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C236 -b512 -e -r
Latency = 49.8 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C238 -b512 -e -r
Latency = 48.2 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C240 -b512 -e -r
Latency = 49.1 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C242 -b512 -e -r
Latency = 49.8 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C244 -b512 -e -r
Latency = 48.8 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C246 -b512 -e -r
Latency = 49.1 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C248 -b512 -e -r
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C250 -b512 -e -r
Latency = 49.2 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C252 -b512 -e -r
Latency = 50.3 core clocks (14.4 ns)
--c2c_latency -c0 -w2 -C254 -b512 -e -r
Latency = 49.4 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C256 -b512 -e -r
Latency = 50.0 core clocks (14.3 ns)
--c2c_latency -c0 -w2 -C258 -b512 -e -r
Latency = 32.0 core clocks (9.2 ns)
--c2c_latency -c0 -w2 -C260 -b512 -e -r
Latency = 33.4 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C262 -b512 -e -r
Latency = 33.6 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C264 -b512 -e -r
Latency = 33.6 core clocks (9.6 ns)
--c2c_latency -c0 -w2 -C266 -b512 -e -r
Latency = 34.0 core clocks (9.7 ns)
--c2c_latency -c0 -w2 -C268 -b512 -e -r
Latency = 33.9 core clocks (9.7 ns)
--c2c_latency -c0 -w2 -C270 -b512 -e -r
Latency = 34.6 core clocks (9.9 ns)
--c2c_latency -c0 -w2 -C272 -b512 -e -r
Latency = 34.8 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C274 -b512 -e -r
Latency = 34.2 core clocks (9.8 ns)
--c2c_latency -c0 -w2 -C276 -b512 -e -r
Latency = 34.8 core clocks (9.9 ns)
--c2c_latency -c0 -w2 -C278 -b512 -e -r
Latency = 34.4 core clocks (9.8 ns)
--c2c_latency -c0 -w2 -C280 -b512 -e -r
Latency = 35.7 core clocks (10.2 ns)
--c2c_latency -c0 -w2 -C282 -b512 -e -r
Latency = 35.6 core clocks (10.2 ns)
--c2c_latency -c0 -w2 -C284 -b512 -e -r
Latency = 35.1 core clocks (10.1 ns)
--c2c_latency -c0 -w2 -C286 -b512 -e -r
Latency = 34.7 core clocks (9.9 ns)
--c2c_latency -c0 -w2 -C288 -b512 -e -r
Latency = 35.9 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C290 -b512 -e -r
Latency = 35.4 core clocks (10.1 ns)
--c2c_latency -c0 -w2 -C292 -b512 -e -r
Latency = 36.0 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C294 -b512 -e -r
Latency = 34.8 core clocks (10.0 ns)
--c2c_latency -c0 -w2 -C296 -b512 -e -r
Latency = 35.7 core clocks (10.2 ns)
--c2c_latency -c0 -w2 -C298 -b512 -e -r
Latency = 36.1 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C300 -b512 -e -r
Latency = 36.3 core clocks (10.4 ns)
--c2c_latency -c0 -w2 -C302 -b512 -e -r
Latency = 36.6 core clocks (10.5 ns)
--c2c_latency -c0 -w2 -C304 -b512 -e -r
Latency = 36.0 core clocks (10.3 ns)
--c2c_latency -c0 -w2 -C306 -b512 -e -r
Latency = 36.8 core clocks (10.5 ns)
--c2c_latency -c0 -w2 -C308 -b512 -e -r
Latency = 37.4 core clocks (10.7 ns)
--c2c_latency -c0 -w2 -C310 -b512 -e -r
Latency = 36.9 core clocks (10.6 ns)
--c2c_latency -c0 -w2 -C312 -b512 -e -r
Latency = 37.9 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C314 -b512 -e -r
Latency = 36.7 core clocks (10.5 ns)
--c2c_latency -c0 -w2 -C316 -b512 -e -r
Latency = 37.0 core clocks (10.6 ns)
--c2c_latency -c0 -w2 -C318 -b512 -e -r
Latency = 37.9 core clocks (10.9 ns)
--c2c_latency -c0 -w2 -C320 -b512 -e -r
Latency = 37.8 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C322 -b512 -e -r
Latency = 38.1 core clocks (10.9 ns)
--c2c_latency -c0 -w2 -C324 -b512 -e -r
Latency = 37.8 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C326 -b512 -e -r
Latency = 37.6 core clocks (10.8 ns)
--c2c_latency -c0 -w2 -C328 -b512 -e -r
Latency = 39.5 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C330 -b512 -e -r
Latency = 38.4 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C332 -b512 -e -r
Latency = 38.7 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C334 -b512 -e -r
Latency = 37.9 core clocks (10.9 ns)
--c2c_latency -c0 -w2 -C336 -b512 -e -r
Latency = 39.2 core clocks (11.2 ns)
--c2c_latency -c0 -w2 -C338 -b512 -e -r
Latency = 39.5 core clocks (11.3 ns)
--c2c_latency -c0 -w2 -C340 -b512 -e -r
Latency = 38.7 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C342 -b512 -e -r
Latency = 38.4 core clocks (11.0 ns)
--c2c_latency -c0 -w2 -C344 -b512 -e -r
Latency = 39.9 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C346 -b512 -e -r
Latency = 38.9 core clocks (11.1 ns)
--c2c_latency -c0 -w2 -C348 -b512 -e -r
Latency = 42.4 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C350 -b512 -e -r
Latency = 40.9 core clocks (11.7 ns)
--c2c_latency -c0 -w2 -C352 -b512 -e -r
Latency = 40.7 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C354 -b512 -e -r
Latency = 39.8 core clocks (11.4 ns)
--c2c_latency -c0 -w2 -C356 -b512 -e -r
Latency = 41.9 core clocks (12.0 ns)
--c2c_latency -c0 -w2 -C358 -b512 -e -r
Latency = 40.5 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C360 -b512 -e -r
Latency = 41.4 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C362 -b512 -e -r
Latency = 40.5 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C364 -b512 -e -r
Latency = 41.5 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C366 -b512 -e -r
Latency = 40.5 core clocks (11.6 ns)
--c2c_latency -c0 -w2 -C368 -b512 -e -r
Latency = 42.1 core clocks (12.1 ns)
--c2c_latency -c0 -w2 -C370 -b512 -e -r
Latency = 41.4 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C372 -b512 -e -r
Latency = 41.4 core clocks (11.8 ns)
--c2c_latency -c0 -w2 -C374 -b512 -e -r
Latency = 41.6 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C376 -b512 -e -r
Latency = 41.6 core clocks (11.9 ns)
--c2c_latency -c0 -w2 -C378 -b512 -e -r
Latency = 41.8 core clocks (12.0 ns)
--c2c_latency -c0 -w2 -C380 -b512 -e -r
Latency = 40.3 core clocks (11.5 ns)
--c2c_latency -c0 -w2 -C382 -b512 -e -r
Latency = 43.5 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C384 -b512 -e -r
Latency = 42.7 core clocks (12.2 ns)
--c2c_latency -c0 -w2 -C386 -b512 -e -r
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C388 -b512 -e -r
Latency = 43.1 core clocks (12.3 ns)
--c2c_latency -c0 -w2 -C390 -b512 -e -r
Latency = 43.7 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C392 -b512 -e -r
Latency = 44.4 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C394 -b512 -e -r
Latency = 43.5 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C396 -b512 -e -r
Latency = 43.5 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C398 -b512 -e -r
Latency = 43.6 core clocks (12.5 ns)
--c2c_latency -c0 -w2 -C400 -b512 -e -r
Latency = 44.0 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C402 -b512 -e -r
Latency = 43.5 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C404 -b512 -e -r
Latency = 44.0 core clocks (12.6 ns)
--c2c_latency -c0 -w2 -C406 -b512 -e -r
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C408 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C410 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C412 -b512 -e -r
Latency = 45.0 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C414 -b512 -e -r
Latency = 45.5 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C416 -b512 -e -r
Latency = 44.7 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C418 -b512 -e -r
Latency = 46.0 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C420 -b512 -e -r
Latency = 45.1 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C422 -b512 -e -r
Latency = 43.3 core clocks (12.4 ns)
--c2c_latency -c0 -w2 -C424 -b512 -e -r
Latency = 44.6 core clocks (12.8 ns)
--c2c_latency -c0 -w2 -C426 -b512 -e -r
Latency = 45.3 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C428 -b512 -e -r
Latency = 44.4 core clocks (12.7 ns)
--c2c_latency -c0 -w2 -C430 -b512 -e -r
Latency = 45.2 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C432 -b512 -e -r
Latency = 44.9 core clocks (12.9 ns)
--c2c_latency -c0 -w2 -C434 -b512 -e -r
Latency = 46.1 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C436 -b512 -e -r
Latency = 46.5 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C438 -b512 -e -r
Latency = 47.4 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C440 -b512 -e -r
Latency = 46.0 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C442 -b512 -e -r
Latency = 45.3 core clocks (13.0 ns)
--c2c_latency -c0 -w2 -C444 -b512 -e -r
Latency = 46.2 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C446 -b512 -e -r
Latency = 46.7 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C448 -b512 -e -r
Latency = 45.9 core clocks (13.1 ns)
--c2c_latency -c0 -w2 -C450 -b512 -e -r
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C452 -b512 -e -r
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C454 -b512 -e -r
Latency = 46.3 core clocks (13.3 ns)
--c2c_latency -c0 -w2 -C456 -b512 -e -r
Latency = 47.0 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C458 -b512 -e -r
Latency = 47.1 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C460 -b512 -e -r
Latency = 49.2 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C462 -b512 -e -r
Latency = 46.9 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C464 -b512 -e -r
Latency = 46.8 core clocks (13.4 ns)
--c2c_latency -c0 -w2 -C466 -b512 -e -r
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C468 -b512 -e -r
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C470 -b512 -e -r
Latency = 48.3 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C472 -b512 -e -r
Latency = 47.3 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C474 -b512 -e -r
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C476 -b512 -e -r
Latency = 48.3 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C478 -b512 -e -r
Latency = 46.0 core clocks (13.2 ns)
--c2c_latency -c0 -w2 -C480 -b512 -e -r
Latency = 48.3 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C482 -b512 -e -r
Latency = 47.8 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C484 -b512 -e -r
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C486 -b512 -e -r
Latency = 49.1 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C488 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C490 -b512 -e -r
Latency = 47.6 core clocks (13.6 ns)
--c2c_latency -c0 -w2 -C492 -b512 -e -r
Latency = 47.2 core clocks (13.5 ns)
--c2c_latency -c0 -w2 -C494 -b512 -e -r
Latency = 48.5 core clocks (13.9 ns)
--c2c_latency -c0 -w2 -C496 -b512 -e -r
Latency = 48.9 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C498 -b512 -e -r
Latency = 48.0 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C500 -b512 -e -r
Latency = 47.9 core clocks (13.7 ns)
--c2c_latency -c0 -w2 -C502 -b512 -e -r
Latency = 48.8 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C504 -b512 -e -r
Latency = 49.0 core clocks (14.0 ns)
--c2c_latency -c0 -w2 -C506 -b512 -e -r
Latency = 48.2 core clocks (13.8 ns)
--c2c_latency -c0 -w2 -C508 -b512 -e -r
Latency = 49.7 core clocks (14.2 ns)
--c2c_latency -c0 -w2 -C510 -b512 -e -r
Latency = 49.2 core clocks (14.1 ns)
--c2c_latency -c0 -w2 -C512 -b512 -e -r
Latency = 48.7 core clocks (13.9 ns)
对intel的平台也没问题啊，我之前也给你说过原理了，而且也没有numa的影响。
我还觉得我真是个圣人喃，在这儿教你做人
评论
来了来了，看看民科工包哥怎么对战求秒帝
评论
前面几个偏低，后面就比较稳了。intel平台设置成2没事，1的时候也有惊喜呢。他是先拷一个window进L2然后开始测试，但是这个window如果非常小的话会不会在cpu别的地方也有存着呢（然后就变成clean hit）？默认状态结果非常准不看，手动用非常小的window也不知道跑在哪个硬件结构里，结果到底出了什么问题也不知道，先把intel官方的工具定义成不合理、自家cpu都不能测再说？
你原理是说了，但是多出来的40ns是什么组成没说，我也没法分析，很多人要源码也不给。还有你可验证过这个问题是系统的、每个类似软件都会出现，还是这个软件的独立问题？
不对啊，我之前只是说你的软件测试结果比intel官方高一倍，结果不是纯总线传输，还有我这边mlc没有出过问题。也没说别的啊。我都不知道你在激动什么，还是别谈了吧。态度正常点应该不会掉块肉。
评论
嗯，有点影射的味道。论坛也是个小社会，大社会什么样，小社会就会是什么样。
很多人最后选择了不说，楼主还是选择了尽可能的去表达。
评论
我该说都说了一遍了，反复问你的问题你也不正面回答，那就算了，也别怪我态度差。mlc的问题，我不止在这里，之前的帖子也说过。
intel工具是官方的，我相信它有它测试的意义，但这个意义你知道吗？所以我反复问你buffer和windows大小的影响到底是什么，为什么可以出现两个多周期这个根本不可能出现的延迟？如果你连原理和真正测试的内容和意义都不知道，你就敢说你mlc的结果就是官方和正确的延迟？我的测试软件，原理已经给你了，你觉得有问题你可以提，我会正面回答你。而对等的mlc的问题你也别给我回避。
评论
mlc我上个帖子和之前的文章早就回你了啊，手册里c2c的原理写的很明白。首先建立一个大buffer，然后取一小块做window让一个核心修改，之后另一个核心去读就会发现这块被修改过，于是就从那个发射核心里读。一次搞完了以后再取下一块，直到buffer耗尽。
我回了默认设置下测试结果并没有什么问题。至于为什么手动设超小window的时候延迟不准，我刚回帖给出了几个猜测和需要验证的地方，个人目前这方面实力有限，如果你觉得有什么可能的问题和影响因素也可以提出。
不知道我有没有理解错，反正我感觉你第一个回复的态度就很针对，问那么多问题像是质问而不是讨论。不过我估计以后也得这样吧，外面有些人的确啥都不懂就拿着错误百出的东西来杠，一巴掌扇死防止夜长梦多。
评论
我当然不是在说这个，更细节的东西，首先window怎么取的？完全随机，还是线性，还是说每次跨过一段？buffer建立之后，怎么保证修改状态没有自动传递到别的核心？等等等等
答不上来，那就直说，我也不用问了。
评论
看不太懂，这影响只是针对企业级吧。民用级别瓶颈在于SSD的性能吧
按他的意思，使用-r以后window是随机的，buffer的初始化也是随机（pseudo random）的。另外他是发射核心取数据以后会修改，然后接收核心马上读，而且每次的这个过程是独立的，状态应该没有传到别的核心。
你可以去研究一下他的文档。
评论
从结果上来看，-r确实稍微高了一点点，但依然无法解释为什么有那么大的波动。马上读这个马上也很有意思，它通过什么方法来通知另一个核心的，这个延迟是怎样的。
评论
我记得我引用过这段原文。他怎么操作的都在这。另外他还提供了-H的选项不修改直接读。他的说明文档比较严谨，各种测试操作间如果有加入delay的情况他都说明了。
你结果后面比较稳，有最多2，3个ns的差别可能是你测试时间太久了，你也知道这种小延迟的测试受系统后台影响非常大，不光这个软件其他测试软件也都一样。前面第一个看着像直接本地L2就有，第二个开始的几个看着像hit clean，再后面就比较稳了。所以说最好看看cpu自己对于这种小块是怎么处理的，这个细节我没找到资料，你要知道的话也可以说说，也可以看看是不是别的软件也有这种状况。不过我觉得你直接下定义这个软件就是错的不妥。
评论
我从来没说过这个软件是错的，我说的是你对他结果的理解是有问题。
后面稳不稳，无所谓，前面和中间那一段多次测试都是一样的结果，而且我今天正好重装了系统，0后台测试也一样，所以我觉得压根就没有理解它的机制。
小块无论cpu怎么处理，至少完全没有可能延迟短于L1的延迟，我猜测这点上，他的延迟计算方法也绝对不是按正常的方式来的，最大的可能是考虑了某些cpu架构方面的东西，对于延迟加了手工修正。这样的话，这个结果有些什么意义，就更值得商榷了。
评论
不对啊，我没有自己理解啊，我都是引用说明，最多就是说了你数值上比他大。而且你第一个回复直接就说这软件没合理性吧。。。
另外我把你前面两个测试结果画了个图，中段的问题应该出在设置的window大小不能被buffer整除上。0后台是不可能的，你就算新的系统，用别的软件测多次，也会有随机误差存在。
mlc_c2c vs blk.png (38.22 KB, 下载次数: 0)
他的计时开始和结束的时间可能有ns级别的误差，或者像你说那样结果上减去了一个预期的overhead，加上cpu某些机制的存在导致得出了L1级别的数。但是如果测大window的话这个影响应该不大。
评论
你用这个来测延迟，然后直接和我的结果对比，当然没有合理性，这也就是你自己的理解。
我说的延迟不稳定是说这个吗？麻烦你不要再偷换概念了。
所以不能被整除为啥就会出现这种结果喃？
这种怎么可能是误差带来的，每次测量都一样。CPU也不可能存在任何机制使得正常访存延迟低于L1延迟，除非是同一个核心上的前后两条指令一个写一个读同一个地址，可以有forwarding机制来产生低于L1的延迟的速度。
评论
都是测CPU互联延迟，就不能对比不同方法各自的机制和同条件下的结果？不仅不能做而且说一句这个现象都不行？我可没两种方法的结果画一个图里，然后说A处理器用方法1比B处理器用方法2延迟低所以A强这么比。
我哪知道你说的‘中段’不稳定是指第一个值后面几个还是指整体的中段，画个图以备万一就是偷换概念了？你说每次都一样，好像还真是这个图上这种情况。
不能整除的话，可能余数的部分空间就被舍弃了，实际上软件可能还是认为设置那么大的空间是全跑上的，结果就会低。这是一个推断，我连带小块延迟的问题去intel论坛问一下。不过不管怎么样，最好别拿除不尽这种可能有系统性问题的测试算数，更不要按这种情况说整个软件都不靠谱不稳定，尤其这个软件intel明确说过各种cpu上经过了验证。
总感觉和你说话不被莫名其妙的嘲讽基本不可能。我觉得再讨论意义也不大了，我也不可能把各种文档全都翻译一遍。不过奉劝你一句，以后如果你还是这样而且意外失误被不怎么赞同你观点的人抓到，可能被黑出翔。尤其是某扣分狂魔可能过一两年就不和你站队了。
评论
看你帖子才知道der8auer这个资深a粉都被喷过。。。十几年前就看过他在hwbot超频榜霸榜，还买了K8双路平台。
真的感觉给某些粉丝提出一丁点他们支持的品牌的意见都是体力活而不是脑力活，永远有人拿着漏洞百出的测试甚至毫无根据就给你站队，一旦严谨的求证过以后他们就玩消失，带完节奏就跑。这段不是针对求秒帝也不是针对楼上众人。求秒的实力还是可以的。
评论
都是中文，但是什么都看不懂
评论
强大的平台性能，不知还要多久桌面级能达到这样的性能
评论
不是不行，而是你既然连什么意义都不知道，然后跑来给我说一句，我的软件延迟测出来比官方的高一倍，很明显的就是说，我的不准嘛。
别的既然你也不知道，我也懒得和你讨论了。
我从来不和谁站队，有技术的人我从来都非常尊重，比如rskip。
评论
价钱intel就对了
评论
目前你的工具和intel的工具都提供了原理，这方面我很早就看过了；暂时都没提供实际代码的实现方式（据说再过几个版本intel mlc要开源），mlc小块的问题和你的第一个软件数值高的问题可能都有一部分出在这个方面。所以我怎么办？实际多拿几个软件测试对比。结果就出来3个问题：1. 地雷云的测试、mlc和你的新软件在结果上都比较统一，而且和已知的官方数值也比较统一，但是intel平台和你的老软件差一倍，这个量很难用简单的核心的overhead解释 2. 你的老软件在有些cpu上确定翻车了，比如rome 3. intel软件，至少默认设置下是经过他们实机验证的。
就算有这3条，现在我也没说你老软件一定是错的，我只是说你老软件结果里总线传输以外的因素影响可能比较大。你的老测试应该是来回加一个全局变量算总时间的吧，去年我也提醒你从多方面去看看是不是有这种问题，我建议过你看看核心在总时间中的占比会不会有点大，这个还会影响测出来的是不是idle latency（据我测其他设备的经验，总线或者两端负载比较大的时候测出来的loaded latency会比较难控制变量，而且官方标的一般也不是这种数值）。我回帖跳跃性太大、很多地方没说清楚而且有经验主义导致经常没讨论到一块去是我的锅，但是你没了解过地雷云的测试原理就否认，说mesh的cpu游戏性能差（证伪方面你可以看看外网4.6的3175x和4.8的10980x打9900K之类测试，虽然不排除大L2加成但是大体也能看出来），而且没意识到我已经在说ring测试结果也比较高、就讽刺我顾左右而言他。我不觉得完全没问题。
说这些其实也没什么太大的问题，我只是说，你能不能给没有经过你认证的人起码的尊重，讨论问题不要每3句就有一句嘲讽优越。放平心态。
评论
首先我老工具和新工具延迟是基本统一的，带numa的除外。我大概也知道你们的问题在哪，实际上，地雷云类似的结果，我在写第二个工具的时候也遇到过，只是我没有你们的代码，我就不会乱说，我猜测是和状态传播相关的。intel官方我没找到过有mesh实际延迟的说明，mlc测试的意义不明确之前，你有什么理由说默认就代表官方喃？
下面的，我写软件自然会考虑这些，循环本身的延迟我是测试过的，并且考虑到变量变化的点可能是循环任意位置，所以除了个2在最终结果中减去，同时也是因为这个任意位置，为了让结果符合概率上的期望，都是进行了非常多次测试取平均。
顾左右而言它，那么你说的这两个4.6 4.8的，mesh跑在多少频率喃？
我不是不尊重你，我和你讨论这么多，我有没有扯你别的黑历史？我有没有通过站队什么的来攻击你？反而上面你跑来说我失去别人站队就会怎么怎么样？我只是单方面讨厌你的不严谨，要发文就好好拿证据讲逻辑，脑补下结论什么的，你形象也就这样了，我心态可没办法放平。
评论
他说过在自家cpu上做过验证，那么如果同样默认设置多个硬件多次测试没有不稳定之类问题，那么至少在他自家cpu上可信度还是很高的。虽然mesh和ring的内部intel没直接给出（经过我的测试，也比较复杂），但是对于很多其他已有的官方数据不管intel还是amd都基本对的上。
tom's那个10980的测试只说了超主频，没超总线。而且就算超频率也很难超过ring，延迟更不用说。
我批评的只是你3句1讽刺和给他人随便下结论的态度。我说过多少次，我之前写的是预告，应一些朋友的邀请分享一些阶段性结论和接触过很多行业人士分享的经验，很多测试和验证还没完成，正文还有很久才能搞定。你就根据这个就给我下结论说我在脑补？严谨性在哪？结果也是嘛，有些人自己分析不完善，有些人在瞎质疑瞎给我下结论，3篇验证做下来结果怎么样呢？反而是之前别人拿来质疑我的“证据”漏洞百出，我结论都大差不离，只是架构图里一个部分在整理数据的时候犯了个低级错误，这方面反而没见有人提。这时候那些人就消失了，之前质疑过的只有mkkkno1站出来说我分析的不错。
你要说阶段性结论和经验都不给放，放了你的形象就这样的话，那么是不是这个论坛大部分经验总结讨论贴都得封、STH某些专家的文和视频都得封、ANAND一些评测得封、甚至很多官方的case study都得删、往大了说相对论和量子力学里至少有一个得烧书呢？我一个小预告要写到学术论文的严谨度，别人提出质疑和正式评测就不需要了？前两天有人猜ice lake的imc位置怎么不去怼。我还把测试放出来了，很多人完全就是经验。还有很多粉丝发帖完全就离谱，也应该去那照着人头怼？
我不赞同的是你的态度，我还没说两句你就要正面刚。我只是说你这个态度以后可能招黑，我也没别的意思，好好讨论还是可以的。
评论
这种模棱两可的说法就不用提了，毫无意义。你c2c测试，在amd的处理器上就完全对不上。
你睁着眼睛说瞎话的能力也是一绝：
Overclocking was a straightforward affair: We bumped memory speeds up to DDR4-3600 and used a 2.1v VCCIN paired with a 1.2V vCore. We also bumped up the mesh multiplier to 32 and increased vMesh to 1.2V, which imparts a nice performance kicker due to better cache latencies. We also uncorked all of the power limits in the BIOS. Temperatures with our custom loop peaked at 80C during AVX2 workloads, but be aware that standard closed-loop coolers will be a limiting factor.
后面这些，你原文怎么写的？一篇脑部下来就下结论，还别人给你下结论？以为都是鱼类记忆？我不喷你你会改？
我贴吧混了十几年，chh混了十几年，还轮不到你来教我做事。
别回了，和你说话真的恶心。
评论
你的是哪个评测，我指的是这个。
https://www.tomshardware.com/fea ... tel-core-i9-10980xe
我暂时没找到你这段话在哪个评测里。就算真的有，mesh也就3.2，影响我说的话？我可是超频的情况都说了哦。说为什么认为官方的测试靠谱都模棱两可了，amd的图我前几个回帖都放出来了，你比比呗，看和官方best case差多少。
是啊，我预告里基本只写了结论，推导过程写的很少，我没说过程就代表我脑补？有质疑的结论我都详细论证了，论证过程我也直接说随便找业内人士去问合不合理，并且全部投稿到行业文库。麻烦请仔细看看谁是鱼类记忆。
的确像贴吧混久的人，好好和你说你就这态度？亏得我还给楼上怼你的人评价话不要这么说，还我不喷你会改。以前我去贴吧说杂牌ssd用的是垃圾颗粒尽量不要买，有些人也是你这种态度，整天就是自己漏洞百出还教你做人，仗着有撑腰的人就开始皮。所以我现在都懒得去。
我早说咱别讨论了吧，这两天的确不是没恶心够，论证全都是别人的责任，自己只负责下结论人身攻击。结论还都是对人不对事。你的文是全篇都是AMD怎么好，intel的5way decode，多一倍simd位宽，更高效的指令集，短流水线、大L2统一L3哪个说到了，测个IPC指令并行性能也去排除指令融合的优势，说我怎么样你的客观性公正性呢。别回了算了，一旦谈到这些估计你又在某个犄角旮旯的地方找毛病然后全盘否定我。我废半天论证了你又一句话满盘无效。世界上就你一个人懂可以了吧，那些STH的专家都是傻子，都在脑补结论，行了吧。
我们来看看真正的大神前几天是怎么和我说事情的：
评论
找到另一个评测了，这个评测里总线是超频的，和3970x对比的评测里没说超。结论不变，很多测试mesh的10980xe和3175x以较低的总线频率和差不多的主频在游戏测试中打败9900K。
https://www.tomshardware.com/fea ... tel-core-i9-10980xe
https://www.tomshardware.com/reviews/intel-core-i9-10980xe/3
评论
我就绝望的想知道我3800X+X570ACE+intel P4510跟我的9900X+X299+p4510差距多少。。。。。。；另外科赋内存条我买的灯条在X570上稳如老狗，是哪里不好？谢谢
评论
P4510标称iops不高，所以差距应该不大，除非你插多块。杂牌内存到手最好memtest跑一遍500%确定不会读写出错。我之前买过4条光威结果2条默认跑不过mt。不是暂时玩两天游戏没问题就没问题的，很多时候内存硬盘出的是静默错误，这个错误会逐渐累积。
评论
所以这跟你说“8180打游戏跟9900K没区别”的论证
有什么关系么？
评论
咱别造谣成不
评论
出现了出现了
几个数学专家吵架，一个连一二三都不懂的纯外行忙着站队，给自己看不顺眼的那个专家泼冷水连带扣分
评论
聊天记录找不到了 当时在FCP群里头不就你讲的？
顺便婊了一下消费级 说消费级东西都是垃圾
只有企业级主板才够养眼这种话
谁爱造谣啊 咱不都实事求是么你看你说的那些我不懂的我有跟你BB多少么
评论
找不到还BB。请稍微说一句真话吧，不要随便脑补。
评论
谢谢
评论
把你和求秒帝上面的每一楼都看了。。。
就这层看懂了。。。
你的意思是9900KS不是“best gaming CPU”了？？？
评论
对了，关于上次的电源问题，我觉得淘宝买一个升压模块把5vsb升成12vsb可能可以兼容新标准。
不过战未来长期使用还是不建议的，毕竟里面元器件会老化。
评论
哟 在QQ里头随便讲的几句话就不承认了？
不然当时我把你T了干啥 不就一天到晚的洋垃圾洋垃圾
FC都私聊跟我说看着你烦
别人讨论个99K打游戏啥的你冷不丁的就这么来了句神论反正现在有点时间了又开始耍赖了？
那个氯化镁溶液是你吧我没认错？
评论
目前应该还是吧，毕竟都不超频99ks能赢，都超频99ks潜力也更大，而且没有fivr热量更好控制。
哦那个人就是你啊，我还和群主私下讨论过，然后他说看着你和他认识时间长的份上就不处理了，结果蹬鼻子上脸了还。
我整天说洋垃圾？那是“你认为”。我记得我原话说的是xeon打游戏也不差吧，你的看法还是“你认为”。别回了，在你看来和狮子讨论一些台达电源的方案都能成证据。本来还想找群主加一下的，不过有光谈立场不谈技术的人说得上话，暂时算了吧。
评论
群里头谁在那边开炮说高频内存没啥用，我2666 6通道一样玩？
你神论不是我说，基本谁都知道你爱讲啥东西
你的需求就=别人的需求？你用的爽了干啥还DISS别人？你喜欢怎么用，然后还要教别人怎么用啊？
凡是你在的群我基本都退了 虽然我平时很少水群 但是看你一天到晚高强度水群还在那边BB企业级牛逼就烦
想一想也是厉害啊。打开个QQ群就看到你在各种群里头水，仿佛服务器般7x24小时高强度运作
论坛现在也是为数不多的净土了，除了偶尔的有些人无限开提问之外也挺好的
评论
这么爱急着下结论干啥呢兰总
FC跟我讲他是不好意思把你T走 他不希望跟太多人结仇家。我就T了两个人，一个是整天刷政治的，还有一个是整天刷企业级牛逼消费级都是垃圾的
群里其他人早就对你产生厌恶情绪了，以前我还尝试过劝你不要讲那些东西的结果呢？
一本正经的还在那边讲什么企业级牛逼，有人说企业级贵啊啥的啥的
你让别人干啥？买洋垃圾
一开始我也玩过Xeon E5v3啥的 对于你的那篇文章也颇有赞同，可为啥现在就变了味了呢？
是本身人品就不行的还是咋滴呢？
难怪之前的ID 111alan会被BAN号
评论
哦对，群里晒配置晒测试也是立场不正确
我就不知道，你嘴里怎么蹦不出一句技术和真话呢？甚至你这个回帖不仅非常主观也基本全都是假的。能力对等以后再和我说话吧。
真会脑补啊，别人的厌烦你都脑补出来了，我要看别人烦了我可不会继续哦。上个ID是因为二手区不小心卖了不该卖的东西，那时候有多少人给我求情。这也可以联系上。你下结论的本领可真强，在下甘拜下风。
你要愿意你就继续，反正这些话都会成为证据。
评论
你晒配置跟晒测试跟你随便下结论有关系么？
评论
哟哟哟 现在又开始称呼什么“能力对等”了
难道现在玩个电脑的门槛都这么高了么？我有杠过你什么技术方面的问题么？我就拿我知道的来说啊，你说8180打游戏跟99k差不多啊，这就是你随便下结论的理由么？
是不是我也要去把一大堆论文翻了看过去，才能回复至高无上的您喃？
评论
首先你说我这么说过，要是真的不是造谣啊。
其次不仅断章取义还脑补，你可以的。你顾左右而言他的本领实在高强，咱甘拜下风。
在涛哥群里我否定过多少他的船，说他不是正式版，还说他diy的ssd不可靠，只要在群里的都知道。就因为这个他反而还挺尊重我的，我怼他他还给我管理。
说那么多一个证据都没，让他自己嗨吧。
评论
现在又开始来五十步笑百步了是吧
那你之前的那个ID喃？
有多少人跟你求情，你的意思是你的拥趸很多咯？但是这跟你做错事有什么牵连？你咋不说轮子跟胖版求情让他别BAN你呢？
继续啊 证据是什么喃 是你说企业级牛逼消费级垃圾喃？还是怎么样的咯？
评论
嘻嘻 那你问问呀 你问问别人有没有说这类话呗
一天到晚在群里头阴阳怪气的嘲讽企业级的可是你兰某人呀
评论
真要说造谣的话可以说带着帮“CHH阿涛”卖货了
这也真是个擦边球玩的真6的人。
评论
哟 又开始顾左右而言他了
你呀可别学我讲话呀 你现在别跟我扯这些有的没的 要不你验证一下8180打游戏跟99K没区别的论证咯
评论
自己搜一下很难么？另外你是不是觉得mesh频率要和ringbus同频才算公平？考虑过那是针对低频下的时序和优化吗？也就3.2嘛，也就超了个1/3嘛。
为什么模棱两可，数据和amd哪里对的上了，numa测试确实不差，你那c2c本地延迟测试差了多少？第二intel没有官方公布数据，你想当然就认为对上了？
没错反正结论一写，管什么推导对不对，我后面不喷你，你会把结论删了？
我不需要你来说什么，我也不仗着谁的势力，我自己说话自己负责。有问题就刚正面，谁错谁就当孙子。
是啊，一开始来说我的不对，我提问反驳就是人身攻击，对人不对事，自己避而不答，顾左右言它就是弱势群体。
厉害厉害，我一篇桌面u测试文，对比对象就一个1700x，外加上手上一个6700k对比下桌面架构，我就通篇在吹amd了。intel 5way decode？算上macro fusion确实可以做到5way，但是amd也可以，我没写我就叫吹？桌面架构差了一倍SIMD宽度？你桌面也是大L2？统一L3有Zen2一个CCX的L3大？AMD多个独立L3就没优势了，我是不是也该吹一番？ 排除指令融合的优势。。。 你先搞清楚是不是优势再说，算上宏融合，AMD就是六发射了。短流水线，我又没有办法准确的去测量AMD的流水线长度。。。 按zen1的来说 agner测的分支失败惩罚大约18，skylake是15-20。。。
然后我上面说的这些，这又是我来找毛病了是吧。。。 STH我不常看，我相信别人不会像你一样轻易的提理论，下结论。
agner我也非常尊重，对于架构方面知识的启蒙几乎全部来自于他和david kanter。
评论
ccx内16ns，ccx外90多ns，对不上么。
按这里的图skl不算fusion也是5way，多加了一个简单解码器。里面也写了流水线长度，zen2是19，skl是14-19。
https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(client)
你写的就是这样，严格来说都没什么大问题，但是你在分析整个架构，intel存在优势的地方除了μop fusion带了一下基本没有谈，反而不断去对比他劣势的地方，实验特性的设计和说明方面也比较偏向AMD有优势的地方。我只能认为你品牌之间有点不公平了。还有那个ILP 4和5的总宽度和大部分实际软件关系不大（因为一般软件CPI能做到0.7已经非常牛了），应该不是我们经常说的百分之几百分之十几提升那种IPC。
STH我放两个以前屯的文：
https://www.servethehome.com/why ... -lanes-and-a-bonus/
https://www.servethehome.com/amd ... f-memory-bandwidth/
请你说说，怎么样才不叫“轻易下结论”。我感觉只要有一点点预测性，在你眼里就完全别发出来。我就算有一个点有失误，在程序上也比STH完善，更比本坛里大部分人都完善是吧。而且我对有疑问的地方全部都去证明了是吧。还在说我“轻易下结论”，我觉得对于某些人来说就算发了nature也是轻易下结论。
写东西要证据，怀疑别人就可以轻易下结论了？有什么意见可以提，不要整天你就是错的。你自己看看你之前的回复有没有人身攻击，有没有一堆问题问的天花乱坠的别人好不好回答。。。
评论
神仙打架，，，
评论
厉害啊，原来你的传统艺能是 在群主面前撒娇 索要管理员？
评论
这是你的贴子对吧。
https://www.chiphell.com/thread-2184273-1-1.html
你就不能去看看agner让你看的pdf，人家都是实测的。。。
神了，理论测试还有偏向性？我本来主题就是3900x的测试，本来就只是为了科普基本知识顺带提了一下intel。。。 我真要黑i，那两个架构之间互有优劣的地方多了去了，我来测这些基本的东西？ 我测个整数浮点混合负载，vex非vex切换，不是黑的飞起？
我就问你人家有像你一样有不明白的地方还直接下结论吗？
论证完备就不是轻易下结论。
对我提出来的问题，我都一一的解答了，并且有问题我欢迎你问。我问你的喃？还要现去intel论坛上问，自己发帖之前就不能想想这些问题可能带来的影响？反过来怪我说我问题问的天花乱坠。。。
评论
我后续的帖子是这个：
https://www.chiphell.com/thread-2188283-1-1.html
这个帖子里7452延迟稍高是因为它主频总线频率都低一些。
没人敢专门建明显偏激的混合负载来做评测吧，也不需要。理论测试就不能有偏向性？我要黑傲腾那直接比高qd吞吐量，要黑SZ983那只放写入测试，要黑D700那只放QD1读。很难么？小白都是去理解，责任是写文的人的。有可比的地方就要说全。
有不明白的地方么，反而是你非要说intel官方测试测自家u都有毛病我才去问官方的吧，这么问还问出把柄了。我觉得按你的标准应该把windows反编译一遍，要不然就是问题没弄明白。之前有几个人想找你要源码把问题弄明白你也没给。
STH这两篇基本就是介绍一下背景然后给出自己的理论猜想。没有官方证据的地方和现在证伪的地方都有不少，而且他们还做了视频介绍这些理论。我觉得在你眼中他们应该是罪大恶极。回头来看，你是想一个预告（tease）我必须写几万字才能发？我觉得你不应该对我说这些，你应该对论坛和油管视频每天各种下结论的都去怼，我毕竟是测试基本做完才发的预告，数据都给出了，而人家是真正的胡吹胡黑。
评论
所以这里的3950x又被开除了？
基础理论测试你要觉得有偏向性，我也无话可说了。我说的混合负载不是你所谓的不公平的混合负载，而是常见的整数浮点混合，但intel整数浮点公用发射端，所以会影响性能，我连这种东西没测，我是不是按你的说法我就是吹I了，我有偏向性了？我不知道你那种上来拿着几张脑补图，就开始AMD互联不行算什么了。
我说了你测得意义不明，你既要使用你自己都不明白的东西去测，又觉得别人问的多，这可是直接与结果相关的东西，我能说啥喃？你很棒，结论严谨？
猜想当然可以有，你要发预告可以发，背后的东西不完备可以，说出来讨论，别人有质疑的就老老实实接着，自己研究清楚，而不是直接丢结论。
评论
3700x里面有。而且比较正常。
我当然知道你说的是啥，我发现你经常认为我不知道你说的是啥，比如上次那个存储山，我看那么多年anand评测每个cpu评测都有只是我不知道它中文名。
AMD核心间互联比intel差这个结论需要我那个图么？我早回过吧，他北桥分4个节点，每节点内跨die而且ccd内不同ccx和跨ccd延迟一样，各种互联延迟轻松上百，我说他性能完善度不如intel有毛病么？就算北桥里4个节点真的设计成全互联又怎样。ccx之间没互联测出来了，北桥节点两两接近也测出来了，最后关于节点排布的数据整理出问题，你就说我整个都有毛病都是脑补的？
所以现在连相信官方测试软件都变成不严谨了么，他的说明文档和我的目标完全相符。。。而且我回别人的只是你比他高，没说谁一定有问题谁一定没问题，难道我言论必须是你靠谱intel不靠谱么。非要用找bug的方法跑也没办法。。。
所以我没研究清楚？那我最近3个验证是干什么吃的。疑问可以接，问题是论坛上乱提疑问的比较麻烦。
评论
原来你这也要挑着来啊。
储存器山。。。我说anand哪有储存器山测试，不都是一个固定stride跑一遍么
你开始那几图不是脑补的？两张总线型的图一丢，连anandtech的说明都符合不了，就开始丢结论，你说我怎么看的下去。
你把我之前问的问题解答了，理解了意义，再来解读结果，我没有任何异议，明知测试软件原理不明，测试内容不明的情况下强行解读，那抱歉，确实不行。
不是你研究了就叫研究清楚了。你说的没错，对于你这样的我都耐心的一一回答，给出了符合逻辑的解释，你有什么理由不接？
评论
是啊，只是stride固定就不是一个三维结构而已。
anand那个引用解读空间挺大的，比如把这个官方图没画黑线的部分擦掉，一样符合他的引言。
EPYC2_IF.PNG (57.8 KB, 下载次数: 0)
总结下你提出过什么问题。还有什么我没看到的可以提。
1. window和buffer的取法测试方式我都回答过了，buffer也不是直接用的，每次会经过核心拷进去修改再测。
2. 波动的问题是你设的数值除不尽。你可以设除得尽数值，这样结果就很稳。
3. 具体操作流程都贴上了。我不清楚那个怎么通知另一个核心是哪一层面的含义。
4. 非常小块window的问题等回复，不过不用不就行了。
测试软件原理不明内容不明？看来我之前说那么多都白说了。目前只剩具体代码执行方式了。我要不接你的问题怎么会扯到现在。
我记得篇幅上那个架构和总线性能评价离得很远啊，两个也没有必然依赖关系，没有架构图我仍然会那么评价。你怎么判断我依据图写结论的。
大概知道了，你是不是把那个“总线拓扑”看出“总线型拓扑”了
评论
。。。那叫个什么储存器山
那么你试试能不能画成你的线形结构。
1.window和buffer的取法不明，只说了个这个完了就用下一个，但下一个取在什么位置？这个和第二点相关，为什么除不尽就会导致延迟变小？是小的延迟比较准，还是大的比较准？大的的结果是否其实也受到这个机制的影响？
3.你在当前线程写完之后，怎样通知读的核心来取数据？这个时间有多长，modified的状态是不是在这个期间已经通知给另一个核心了，甚至有可能的话，数据是不是也在这个期间传播过去了。
4.这个是和第一点相关的，就算本地访问L2缓存也有12个周期，跨核心无论如何都不可能有这个结果，所以这个互联延迟测试的内在的机制是否可靠，也是一个值得怀疑的点。
这些全部都和结果息息相关。其实你自己写个bat的批处理，-b -C的值拉通测一遍，你就知道MLC的结果问题还远不止这两点，所以理解内部机制十分的重要。我自己写软件，在这些地方也是下了很大功夫，即便我避免了这些情况，即便我在大多数处理器上都验证过，我第二个软件，也依然有没有解决的问题，所以我到现在也没有自信到敢拿出来当作标准参考。
那么当时你从什么地方判断的喃？我只能说幸好版主把你的帖子锁了，你原文还在那，两张错误的拓扑图，紧接着下面总结就是拓扑捉急。。。。 电路 电子 维修 求创维42c08RD电路图 评论 电视的图纸很少见 评论 电视的图纸很少见 评论 创维的图纸你要说 版号，不然无能为力 评论 板号5800-p42ALM-0050 168P-P42CLM-01 电路 电子 维修 我现在把定影部分拆出来了。想换下滚，因为卡纸。但是我发现灯管挡住了。拆不了。不会拆。论坛里的高手拆解过吗？ 评论 认真看，认真瞧。果然有收
·日本留学生活 求个大阪合租
·日本留学生活 自家房招租求
·日本留学生活 东京地区出9成新lv钱包
·日本育儿教育 孩子从国内过来如何学习日语
·日本育儿教育 明年四月横滨招月嫂
·日本育儿教育 请问咋让娃突破识字关？感谢分享中文共读和学习经验的妈妈
·中文新闻 东区明星迈克尔·格列柯，53 岁，将在第一次出生两年后第二次
·中文新闻 《爱情岛》明星卡米拉·瑟洛和杰米·朱维特在透露即将迎来第三