40 ms·

It looks like the error they made was this: They added too much latency because they forgot to account for the latency they added in the client. You can see f

It looks like the error they made was this: They added too much latency because they forgot to account for the latency they added in the client. You can see from their architecture diagram (Figure 4) that the latency measurement didn't include the client delay. https://images.contentstack.io/v3/assets/bltad9188aa9a70543a/blt0d8af56e436d6dc3/6283653ad5f9386926e63767/Asset4.PNG https://images.contentstack.io/v3/assets/bltad9188aa9a70543a... The blog post states: "The existing network monitoring system measured the latency at the networking layer as shown by the green arrow."

chabons 4y ago
I read that section as comparing what they logged before vs what the player experiences: the time taken for an input to be registered and it's effect communicated to the user. Maybe I'm wrong, but I don't think the intention was a precise description of the error, but rather the hazard of not having logs which reflect what the user experiences.
- upwardbound 4y ago
  They stated that they use the same calculation for the logs as for other purposes such as latency compensation. From near the top of the blog post: "The reason we did not find it sooner is that the cause of the issue was a code bug that miscalculated latency, which meant that the values in our logs were also wrong." And from later in the post: "Our logs were not displaying the issue because the calculation was wrong. It explained why the latency was worse in the venue than on the internet servers"
  - chabons 4y ago
    Right, but my point was that I think you're reading into the diagram beyond it's intended purpose. I'm not sure how you can tell that they're logging only the server-side delay, and not the client-side delay, from a systems diagram which shows each of those as a box connected by a bi-directional arrow. For instance, it's clear to me that they don't include the latency included by the game engine in that metric, but not whether they include the server-added latency or if they're aware of it and subtract it off.

chabons 4y ago

I read that section as comparing what they logged before vs what the player experiences: the time taken for an input to be registered and it's effect communicated to the user. Maybe I'm wrong, but I don't think the intention was a precise description of the error, but rather the hazard of not having logs which reflect what the user experiences.

upwardbound 4y ago
They stated that they use the same calculation for the logs as for other purposes such as latency compensation. From near the top of the blog post: "The reason we did not find it sooner is that the cause of the issue was a code bug that miscalculated latency, which meant that the values in our logs were also wrong." And from later in the post: "Our logs were not displaying the issue because the calculation was wrong. It explained why the latency was worse in the venue than on the internet servers"
- chabons 4y ago
  Right, but my point was that I think you're reading into the diagram beyond it's intended purpose. I'm not sure how you can tell that they're logging only the server-side delay, and not the client-side delay, from a systems diagram which shows each of those as a box connected by a bi-directional arrow. For instance, it's clear to me that they don't include the latency included by the game engine in that metric, but not whether they include the server-added latency or if they're aware of it and subtract it off.