Clarifications on receiveTimeMs

Runtime Framework
,
1

Hi! I’d love to know how the “receiveTimeMs” from the “messages” (in the Typescript runtime, in case they are different) is calculated so I can get the same time during the match loop. Could I get some insight on that?

Thanks.

2

Hello @nico,

The receiveTimeMs is the time at which the message has been received by the server, not the time at which it has been delivered to the match handler, there may be some delay depending on when the message was received and what time the next tick fires.

Best.

3

Thanks for the reply.

Can you confirm if it’s a UNIX timestamp, if it’s relative to the match init timestamp, or any other option?

Essentially I would like to know how much time elapsed from the time that message arrived at the server, from the current time in the match loop (regardless of any minor delay between arriving at the server and being relayed to the match handler).

Thanks!

4

yes, it is a Unix Timestamp.

To calculate elapsed time between message reception and message handling within the match loop you can do something like:

Date.now() - message.receiveTimeMs;
1 Like
5

Hi @sesposito , a quick follow-up question on this.

You mentioned there could be a delay between the time the message was received at the server, and when it was delivered to the match handler.

I’m getting an average delay of 68 ms between the two. Being a client and server both local on the same machine, it feels a little high.

Is this delay normal?

FYI, this is how I’m calculating it:

On matchInit, I set initTime on the match state like so:
initTime: Date.now().

Then, on the matchLoop I get the current time like so:

state.currentTime = Date.now();

for (let message of this.messages) {
const delay: number = this.state.currentTime - message.receiveTimeMs;
}

That delay there is giving me a very stable 68 ms.

If I should start a new topic, I apologize. Let me know and I’ll do.

Thanks!

6

I’ve updated my response above as your approach is simpler, I was trying to save a system call but it isn’t crucial.

This may vary depending on the tick rate. Say you’ve set the tick rate to 10 ticks per second. If the message is received right after a tick fires, then it’ll only be delivered to the match loop in the next tick, so the maximum delay could be close to 100ms. A higher tick rate will lower the average delay but use more resources.

1 Like
7

Ah! The tick rate… I completely overlooked that in my calculations.

Now it makes sense. Thank you very much!