Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

FixedUpdate() on connected machines seems to have different fixedDeltaTime

Discussion in 'Multiplayer' started by Zolden, Nov 6, 2018.

  1. Zolden

    Zolden

    Joined:
    May 9, 2014
    Posts:
    141
    Again a rather noob question, but I'm really a few days into networking, and might miss some basics.

    So, I have two mobile phones (a fast one and an old slow one) connected with com.unity.transport thingy.

    At start I sync the simulation, so both have equal frame index at the same moment of real time. Frame index then being increased in FixedUpdate() on each side independently.

    Tests show that indeed events happen seemingly simultaneously. At least at start. But the more the simulation goes, the more the difference between current frame indexes at each given moment is.

    For example, there's about 0.4 seconds difference between the phones reach 5000th frame each. The faster one is slightly ahead, and the difference slowly grows.

    Is this normal? I thought FixedUpdate() is really fixed no matter what and we can rely on its pace.

    What are the general methods of fixing this issue? I'd really like to keep the simulations go with the exactly rate. Maybe I should set fixedDeltaTime manually at start? Maybe make it bigger than default for both, so the slower one to have time to finish all routines?

    Or maybe somehow I need to track the difference in real time and compensate it somehow?
     
  2. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    FixedUpdate is not exactly fixed. It executes on a schedule, but does not interrupt other processing. If for example LateUpdate is running when FixedUpdate is scheduled to fire, FixedUpdate will have to wait until all LateUpdate calls on all scripts complete first.

    The whole point of FixedUpdate is to give you a place to put physics related code immediately before the physics update occurs. It rarely should be used for any other purpose. It is not guaranteed to execute exactly at the expected time.
     
  3. fholm

    fholm

    Joined:
    Aug 20, 2011
    Posts:
    2,052
    It seems weird they should desync that much in just 5000 frames, Time.fixedDeltaTime is a constant value defined in the editor, it's not 'variable' between the updates. So it will not change/drift.

    What might change/drift is how many calls you see between different clients over a long period of time if the clocks drift, but 5000 frames is not a 'long' time.

    You can always implement your own fixed time step update, which doesn't rely on the built in FixedUpdate. This is commonly done in multiplayer games for example (look at the unity fps sample, it does this).
     
  4. Zolden

    Zolden

    Joined:
    May 9, 2014
    Posts:
    141
    You right, that wasn't the case, I made i mistake in interpreting results. In fact it was a combination of badly done initial sync + random per frame ping delay, not a systematic desync. More thorough tests show that there's no noticeable permanent drift during about 30k frames.

    And yea, I'll check the fps example, thanks.
     
  5. fholm

    fholm

    Joined:
    Aug 20, 2011
    Posts:
    2,052
    Sounds about right.