Why isn't the timestamp updating in this Playground example

Developers Language Support
1

I’m testing out some code making calls between a calling canister and a receiving canister

Caller - Motoko Playground - DFINITY
Receiver - Motoko Playground - DFINITY

This is the canister API that I’m calling

public shared func callReceiver() : async TimeResult {
    let startTimestamp = abs(now());
    let receiverActor = getReceiverActor();
    let receivedExecutedTimestamp = await receiverActor.call();
    let endTimestamp = abs(now());

    {
      startTimestamp;
      receivedExecutedTimestamp;
      endTimestamp;
      timeToReceiverInMs = (receivedExecutedTimestamp - startTimestamp) / 1_000_000;
      roundTripTimeInMs = (endTimestamp - startTimestamp) / 1_000_000;
    }
  };

And this is the result I’m receiving

(record {
  timeToReceiverInMs=0;
  roundTripTimeInMs=0;
  endTimestamp=1731105528705974575;
  startTimestamp=1731105528705974575;
  receivedExecutedTimestamp=1731105528705974575
})

Why are all the timestamps the same? I would expect the receiving canister to execute with a different timestamp, and then the final end timestamp to execute later. Like this:

  1. t1 - Caller processes ingress message and records startTimestamp at time t1
  2. t1 - Caller initiates call to receiver at time t1
  3. t2 - Receiver processes inter-canister (same subnet) call from caller at time t2 and returns t2 as receivedExecutedTimestamp back to the caller
  4. t3 - Caller receives response back from receiver at time t3 and records endTimestamp
2

Looking into this further, the Motoko Playground is on this subnet https://dashboard.internetcomputer.org/subnet/pae4o-o6dxf-xki7q-ezclx-znyd6-fnk6w-vkv5z-5lfwh-xym2i-otrrw-fqe, which has 2.8k canisters. It seems like pae4o-o6dxf-xki7q-ezclx-znyd6-fnk6w-vkv5z-5lfwh-xym2i-otrrw-fqe is a closed (not public) subnet.

Is it possible that there’s such low load on this subnet that all messages can be processed in a single round and the same subnet inter-canister is near 0?

So then with a bunch of spare compute capacity can same subnet inter-canister messages go through consensus and be executed in a single round with 0 latency? Also, for clarity these are update call and not composite queries.

3

Every canister that execute during a single block shares the same blocked timestamp for Time.now. since those canisters are on the same subnet It’s possible for them to share at the same time . I’m guessing we’re just seeing this now because of the new scheduler code that allows many more canisters to have a chance to execute in a round Instead of round robining.

4

Yes, since all canisters on the same subnet share the same blocked timestamp, it’s likely why you’re seeing identical timestamps. The new scheduler allows more canisters to execute in a round, which could explain this behavior.

1 Like