既然找到了问题，那下一步就是尽快解决它。
幸运的是，查阅代码后，我们可以很好的理解这一问题。从这里出发，我们假设可以通过做一个配置改变，来补偿这个计算错误。
既然我们有了办法来模拟环境，也有了办法来使用自研工具测试实际延迟，那么就可以通过调节配置，得到我们想要的结果。
以下图表显示了与两个实验相同的网络环境，但这一次使用了将错误修正后的配置文件。
实验三：在正确的配置下启用延迟服务工具
和前两次实验一样，先模拟一个低 ping值环境，几分钟后再模拟一个高 ping值环境。和之前实验结果不同的是，在使用了更改的配置后，这次延迟服务的补偿终于正确了。这张图表显示，即便 ping值从低切换到高，延迟都是基本相同的。
问题解决了吗？
这个配置修正了一个游戏中 ping值计算的错误，却也产生了一个副作用，即釜山场馆内选手屏幕上的帧数和 ping值显示（Ctl-V）会出现错误。显示的 ping值会比实际 ping值低大约 13ms。这是因为，我们上述对延迟服务所做的配置更改，本质上是在目标值上直接添加了一个偏移量，以补偿计算错误。这会对客户端中记录和显示的 ping值应用偏移量产生下游效应（稍后我们会详细分析这点）。其结果是外部客户端显示的数字将比实际 ping 低 13 ms左右。虽然这个结果不是完美的，但当时我们认为确保同等竞赛环境里的对等延迟是一件更重要的事情，即便这意味着釜山场馆外显屏幕会显示错误的数值。
下一步措施，以及一个困难的现实
既然我们已经知道如何准确测量真正的延迟，并找到了一个通过更改配置能够补偿这个计算错误的解决方法，我们马上准备了一个计划进行修正部署，并准备向选手和粉丝沟通，说明之前出现的问题。
但当我们明白了问题所在，我们却面临着一个困难的现实。
我们意识到，在场馆内的选手之前都是在高于35ms范围 的网络下进行比赛的，但在上海远程参赛的队伍，却是在实际的35ms范围内进行比赛的——35ms左右是釜山至上海的自然网络延迟 。我们没有做到公平竞争原则下的延迟对等。
我们需要立即告知队伍。唯一的问题是，这个差异是否大到足以需要重赛。这是一个赛事运营的决定。经过估算，由于计算错误，前三个比赛日中釜山和上海的真实延迟差值大约在15 - 20ms 之间。这也让我们最终做出一个艰难的决定，即使用更新后的配置，将三场受影响的比赛进行重赛，以确保竞赛公平性。
理解ping值的显示数字
在我们决定重赛早期比赛之后，我们知道我们还有很多工作要做。这意味着重新制定赛程，并与队伍联系，以确保他们了解正在发生的事情和原因。 这还意味着我们准备对比赛场馆的服务器和数据中心服务器的配置进行更改，并重新运行所有测试以验证更改是否正确运行。 我们还邀请职业选手前往比赛现场测试新设置下的服务器，多次检查我们是否解决了这个问题。 我们甚至进行了盲测，让职业选手在不知情的情况下尝试两种配置，并让我们知道哪一种感觉像 35ms 延迟，哪一种感觉不止于此。
很不幸的是，我们并没有及时且清晰地将这个外显误差向各位玩家以及转播团队沟通。
不久之后，我们的粉丝就指出了对韩国队伍来说似乎是不公平的优势。 我们开始看到粉丝发布一张显示 22ms 延迟的屏幕截图，而不是预期的约 35ms 的延迟。
这是我们必须回应的问题。
如之前提到的，延迟服务中漏洞的解决方法是添加到配置文件中的补偿偏移值。
此偏移量对屏幕显示的数值有副作用：
