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

Bug: NetCode 0.5.0-preview.5: Large serverTick prediction error. Server tick rollback to # delta.

Discussion in 'NetCode for ECS' started by VolatileCoder, Oct 30, 2020.

  1. VolatileCoder

    VolatileCoder

    Joined:
    Sep 21, 2014
    Posts:
    18
    Disregard. This ended up being an issue in my Entites.ForEach, but misreported as the above.
     
    Last edited: Oct 31, 2020
  2. UsmanMemon

    UsmanMemon

    Joined:
    Jan 24, 2020
    Posts:
    87
    Yes, happens to me also but turning off burst compilation resolves the issue for me. 0.4 used to work correctly with burst but 0.5 just introduced this error(burst-only) and i followed the upgrade guide too. Is there anything else to upgrade?
     
    Last edited: Oct 31, 2020
    adammpolak likes this.
  3. AdamBebko

    AdamBebko

    Joined:
    Apr 8, 2016
    Posts:
    164
    me too. same as Usman
     
    adammpolak likes this.
  4. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    I only get this for the first frame with Burst and 0.5
     
  5. Lukas_Kastern

    Lukas_Kastern

    Joined:
    Aug 31, 2018
    Posts:
    97
    I only saw this happening when the ClientServerTickRate component on my Client did differ from the Server one.
     
    adammpolak likes this.
  6. VolatileCoder

    VolatileCoder

    Joined:
    Sep 21, 2014
    Posts:
    18
    This actually ended up being an issue on my Surface Book with Performance Base. The gaming video card was disconnected, and the crappy video card in the 'tablet' half of the laptop couldn't keep up with the physics simulation.
     
  7. adammpolak

    adammpolak

    Joined:
    Sep 9, 2018
    Posts:
    450
  8. UsmanMemon

    UsmanMemon

    Joined:
    Jan 24, 2020
    Posts:
    87
    when doing prediction this error was happening but taking deltaTime from
    GhostPredictionSystemGroup.Time.DeltaTime instead of Time.deltaTime fixed my issue.
     
    mikaelK likes this.
  9. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    Good find, although it's weird as the samples use Time.deltaTime and they should be the same. I get one prediction error when the character is loading in so I was ignoring it. (I think only the spawn position is wrong at first, which is to be expected)
     
  10. adammpolak

    adammpolak

    Joined:
    Sep 9, 2018
    Posts:
    450
  11. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    Wow this sounds like easy fix and it might fix the issue. I'll give it a try tomorrow. Thanks!
     
    adammpolak likes this.
  12. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    Ok I tried and no luck. I tried to remove all the code related to input handling, turned burst off, jobs off and also removed code off from player moving on the getting started with version 0.5 and it still gives those errors. Even tried to change the player prediction mode to interpolated. The only thing that was left was the logic for spawning cube player and the logic for handling go in game events and server start.

    My conclusion is that the prediction error must come from the system and not from the player.
    upload_2020-11-29_15-35-41.png
     
  13. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    Take a look at the NetDbg. (Found in the multiplayer menu coming with NetCode) It runs in a website and you can check prediction errors there to see which data is actually mispredicted.
     
  14. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    @Enzi This is what I get. I get the prediction errors even if I remove the code in sample input script and move CubeSystem scripts. The only way to prevent the system from giving these errors is to uncomment following line.
    Code (CSharp):
    1. PostUpdateCommands.AddComponent(req, new SendRpcCommandRequestComponent {TargetConnection = ent});
    Which I understand prevents the client from sending commands to server.
    upload_2020-11-30_0-34-7.png
     
  15. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    Are you using vsync or Application.targetFrameRate = 60 ?
    There are no real prediction errors visible, client just might be too far ahead.

    The line you pasted is a component to send the req as RPC to the connection ent. It doesn't mean much without context. (Read the docs)
     
  16. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    @Enzi "Are you using vsync or Application.targetFrameRate = 60 ?
    There are no real prediction errors visible, client just might be too far ahead."

    Not using and vsync doesn't seem to affect the errors.

    "The line you pasted is a component to send the req as RPC to the connection ent. It doesn't mean much without context. (Read the docs)"
    I know read my comment. I just stated that the only way to prevent the errors is to prevent client from communicating with the server. xD
     
  17. UsmanMemon

    UsmanMemon

    Joined:
    Jan 24, 2020
    Posts:
    87
    @mikaelK have you upgraded your systems
    Upgrade guide
    • The systems adding input to the ICommandData buffer needs to be moved to GhostInputSystemGroup
     
  18. UsmanMemon

    UsmanMemon

    Joined:
    Jan 24, 2020
    Posts:
    87
    Sorry but this was'nt what fixed my issue. I dont know what did at the time.
     
  19. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    Its a bug alright. I just redid the NetCode getting started, got it working and its broken again. Try dot net 4.0 or il2cpp. That one broke it for me. Also I tried porting the working netcode to my project without changes and started getting these errors again. I have made like 2-4 bug reports on the issue and many more surrounding it.
     
  20. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    Also just playing around with settings seems to spawn lot of these errors.Sorry to say this, but my conclusion is that the 0.5 NetCode cannot be used for anything right now. Its very fragile for all kinds of errors.

    Edit. Ok I take that IL2CPP back. IL2cpp works with my original working getting started project and its fine, but not if I try to bring openvr, game code and plugins.. I guess openvr and combination of other stuff is the thing that is breaking the netcode for me
     
    Last edited: Dec 1, 2020
  21. Enzi

    Enzi

    Joined:
    Jan 28, 2013
    Posts:
    954
    Which framerate is it running? If it's running higher than 60 the prediction errors will be thrown.
    There's an additional vsync button in the editor game scene. The quality settings vsync does nothing in the editor.
     
  22. mikaelK

    mikaelK

    Joined:
    Oct 2, 2013
    Posts:
    284
    Hi, then it must be this since vr-content must be run over 90 frames a second in most devices. I'll try this out.
    I just confirmed adding open-vr makes the prediction error appear sooner or later.

    edit.
    Filed a bug report also turning v-sync on or off from the play window did not help with the issue.
     
    Last edited: Dec 1, 2020
  23. anihilnine

    anihilnine

    Joined:
    Jan 29, 2016
    Posts:
    27
    For me this was occuring because I had disabled running multiple frames per tick on the server. By removing this the server tick issue went away

    Code (CSharp):
    1.                     new ClientServerTickRate
    2.                     {
    3.                         MaxSimulationStepsPerFrame = 1,
    4.                         NetworkTickRate = 60,
    5.                         SimulationTickRate = 60,
    6.                         TargetFrameRateMode = ClientServerTickRate.FrameRateMode.Auto
    7.                     });
    8.  
    Having said that there are some weird things frame-things going on with 0.5
     
    adammpolak likes this.
  24. anihilnine

    anihilnine

    Joined:
    Jan 29, 2016
    Posts:
    27
    Someone PM'd me to ask if Application.targetFrameRate or ClientServerTickRate can be used to fix the "large server tick prediction error" issue. I thought I would write it up to help others because it took me a long time to figure it out.

    I think "large server tick prediction error" just means your server is running slower than expected. Like if processing is taking too long the server starts to get behind (in ticks) where it should be. Your client is constantly guessing where the server is up to by keeping track of time itself - the server starts to chug then the client is AHEAD of the server and it decides to throw an exception. Maybe the client should slow down instead of throwing the exception.

    With the code I posted about ClientServerTickRate ... I had added the code so you probably dont have it. What it did was changed MaxSimulationStepsPerFrame to 1 instead of the default value which is 4. What happens is the server is also keeping track of time and knows how many ticks it should have executed. If it is behind it intentionally runs multiple ticks to catch up. This can have a snowball effect where that puts it further behind and next frame, it runs 3 ticks, then 4, then after a while, 20 ticks. My code forced it to only be able to run 1 tick, which also meant the server couldn't really catch up, which also meant the client got ahead, which is why commenting out my code fixed the "large server tick prediction error".

    About this one "Application.targetFrameRate = 60"... If you search for targetFrameRate you will see the netcode is overriding your value anyway when the server is running. So that will only have an effect if you are running a client-only-build. One issue I had is I had a server-build running on my machine and a client-build as well. Both of them were using a lot of CPU and because I had the client focused, the client was using more that 50% of the CPU, which slowed down the server, which caused the client to get ahead and the server tick prediction error to happen. By restricting the targetFrameRate on the client that freed up resources so my server didn't get behind.

    I have stopped using netcode. Also I was using version 0.4.0 and 0.5.0 mostly. From my point of view 0.5.0 had issues surrounding ticks and just didnt have basic frame stability, even in the out of the box (for 0.4.0) examples.

    To conclude, my guess would be your server is just taking too long to execute a frame - check the profiler to see how long the server is taking when the client gets the error. Then start speeding it up.

    Cheers
     
  25. anihilnine

    anihilnine

    Joined:
    Jan 29, 2016
    Posts:
    27