在我们查看日志和代码时，我们逐渐收到了来自各方队伍的更多反馈。大家对季中冠军赛场地环境的抱怨比其他任何环境都多。这和我们的理解有所相背。毕竟，线下比赛和选手在同一建筑里的硬件上进行的。在拥有完美可控的网络环境下怎么会比通过在韩国互联网服务器上进行比赛感觉更糟糕？
这引发了另一个设想…如果日志的延迟测量显示良好，但体验相反，那会不会是日志出了问题？会不会是我们测量延迟的方式有问题？
开发团队随即写了几段代码来验证这个猜想。一般情况下，日志是根据游戏数据包在服务器的网络层和客户端的网络层之间的往返产生的。这些日志没有发现任何错误。所以我们换了一种方式用新工具来测试延迟。不再测试网络层的流量延迟，改为测试整个“端到端”的循环，从用户点击，再到看到该点击响应。换句话说，测量的不再只是网络表现，只要游戏中任何系统之间的互动会被选手接触到，就都会去测量。
可以参考以上的图表了解这个概念。现有的网络监控测量的是包括网络层延迟和延迟服务时延，这一点会通过绿色箭头展示在上图中。但是新的工具模拟了输入层的输入，然后测量在该输入和服务器响应之间发生的全栈延迟。红色箭头展示了新工具的监测轨迹。
有了这个新工具，我们就能在实验室中进行测试，看看能不能重现选手们的问题。
我们做的第一件事，就是在不运行延迟服务下，设置一个基准线。因为我们有来自公共服务器上无数小时的玩家数据，我们相信服务器没有任何漏洞，因此我们以它们来做参照组。 第一个设置基准线的实验模拟了在韩国参赛的队伍和在中国参赛的队伍均从互联网接入服务器的场景。
实验一：关闭延迟服务工具，对比韩国和中国的网络
这类实验的数据十分复杂，这里我们将其整理之后用图表的形式展现出来，可以帮助大家理解我们所看到的情况。
如果你沿着横轴（游戏时间）看，会发现一开始（图表左侧）的延迟值很低。几分钟后（图中从左到右的中间部分），我们开始模拟较高ping值的网络（例如：上海）。我们可以看到，竖轴上的延迟在上升。这和预想的完全一样。在低ping值网络下，延迟较低；在高ping值网络下，延迟较高。
第一个实验，作为参照组，说明用新工具测量的结果是符合我们预期的。这是个好的开始。
下一个实验，我们会用相同的步骤进行检测，但这次我们开启延迟服务工具。
实验二：开启延迟服务工具，对比韩国和中国的网络
我们需要记住的是，人工延迟服务的目的就是无条件平衡网络 ping值。所以如果我们更改了实验室中的网络ping值特性，那么我们的预期就是延迟服务将加入延迟，使得测量值保持相同。然而，数据却表明不是这样的。正如所看到的，上海的模拟网络所显示的延迟比韩国模拟网络所显示的延迟要低。这是在我们意料之外的，这也展示了延迟服务为韩国网络环境带来了比上海网络环境更高的延迟。
从这份报告我们可以确定三件事：
1)问题是真实存在的，且确实与选手们报告的情况相符
2)我们自己可以在实验室重现这个问题
3)问题很可能就出现在人工延迟工具上
从这些信息入手，我们就知道需要在代码中的何处寻找问题。 在运行各种额外的测试以了解我们更改实验室环境的特性时发生了什么后，我们意识到，只有在实际 ping显著低于目标延迟的情况下才会出现计算错误。 在这种情况下，实际延迟将远远高于屏幕上显示的延迟。
这便解释了目前的一系列问题。为什么日志不显示这些问题：因为运算错了。为什么场馆比网络服务器体感还差：因为环境 ping值越低，这个漏洞就越明显。这也解释了为什么在釜山现场的选手觉得比赛体感延迟比屏幕上显示的约 35ms差多了：因为实际延迟确实
