LogNet: UNetDriver::TickDispatch: Very long time between ticks

Community Community & Industry Discussion
, , , ,
1

I’ve been getting this mysterious error since I migrate to 4.15.
It’s happening every few seconds when doing multiple client PIE. ( running several instance to test multiplayer )
It’s comign to a point where it’s impossible to work at all. Any idea what’s causing this?

LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.24, Realtime: 15.35. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.24, Realtime: 15.34. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.75, Realtime: 8.75. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.75, Realtime: 8.74. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.96, Realtime: 8.97. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.96, Realtime: 8.93. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 39.85, Realtime: 40.11. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 39.85, Realtime: 40.09. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.77, Realtime: 7.83. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.77, Realtime: 7.80. IpNetDriver_3
LogEditorViewport: Clicking on Actor (context menu): StaticMeshActor (B_sunway_floor_1)
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 11.59, Realtime: 11.72. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 11.59, Realtime: 11.71. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 9.55, Realtime: 9.68. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 9.55, Realtime: 9.67. IpNetDriver_3
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.10, Realtime: 8.05. IpNetDriver_2
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.10, Realtime: 8.06. IpNetDriver_3

1 Like
2

Hey Frozenfire,

Unfortunately, I haven’t seen this error before on my end.

I’ve got a few questions/suggestions:

  • How many clients are you running? Does this occur when running one or two clients as well or only with more than that?
  • Which OSS are you working with?
  • Do you see any settings in your DefaultEngine.ini related to timeout, such as AsyncTimeout or P2PConnectionTimeout that you could potentially increase?
3

Apparently the game freezes ( on both clients ) together with the editor as many seconds as it says hence it’s impossible to debug anything when this happens.

I’m certain it’s not performance related as I’ve tried setting to the lowest settings. Perhaps it might have something to do with multi-threading of the game instance? what do you think?

4

That’s interesting, I haven’t been able to reproduce the issue on my end. I’d imagine it’d have to be something relating to performance.

Is it happening for you in a clean project as well or is it only happening in your current project? If you can determine a way to reproduce it, let me know and I’ll take another look. However, at this time, I do not believe that this is a bug. Definitely let me know if you find more information though and we can reopen the investigation.

5

Was this ever resolved or figured out? I’m seeing the same thing in the Shooter Game in editor so far only.

Lots of

LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.12, Realtime: 8.12. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_13

6

Hey Nonlin,

What steps are you taking in ShooterGame to reproduce this? What is your framerate sitting at when you’re seeing these warnings?

7

Its been happening to me since Shooter Game in 4.9.
Also in 4.10 and 4.12.

After 4.12 I’ve been manually updating the source up to 4.17 so far.

All I have to do each time is just run the game with two players, one player (listen server) in editor window and the other in a separate window. Does not seem to happen with just the listen server (1 player).

It doesn’t happen instantly, I have to leave the game running for at least 20 seconds before it starts to happen. It isn’t a consistent 20 seconds either.

Frames are between 60-70 then it hitches and flashes red too quickly for me to see how low its going.
Makes debugging in editor a pain.
EDIT: During a recent hang from this issue I saw it freeze down to 1FPS.

8

Are you only seeing this in-editor? Is this happening if you package out the game and test it on separate PCs?

If you’re seeing it only in-editor, then it’s likely due to the fact that you’re running two instances of the game locally, while also rendering the editor. This could definitely cause a drop in performance and hitch the game in a way that prevents replication from occurring at its regular intervals.

As I stated in one of my answers, I’m not thinking that this is a bug, as Networking features are best tested in a packaged game on separate PCs to begin with to simulate a more realistic network environment, so I’d be interested to hear if you’re seeing the same results if you test it that way.

9

I am marking this topic as resolved for tracking purposes, as we have not heard from you in a few days. If this issue persists, feel free to respond to this thread. For any new issues, please create a new Answerhub topic.

Have a great day

10

Could you explain your answer in more detail?

I have encountered this problem while trying to connect a client to a dedicated server in 4.18.1. The problem did not exist in 4.17 or prior.

I see the Very Long TIme message and this apparently causes replication problems which makes the client immediately disconnect.

11

Hi @Nonlin ,

Nope never did , asked everybody I know , nobody in the community had any idea. Apparently it’s happening to ATI cards only I read. Are you using ATI card?

12

@Rhynehall,

I don’t believe it has a specific solution. It dissappeared on my when I switch PC. It’s card related to me. Are you using ATI? It’s ONLY happening with network for me.

If I found a way to reproduce I’ll submit a separate bug report. Do you have any extra info on it?

13

Sorry, my comment was directed at the author of the answer, @Sean L

14

I get exactly the same problem here, I run a server & client.
All is going good, after have play some secs or mins it start to freeze randomly with the long ticks message.
I can wait the freeze and continue to play, sometimes it seen to go ok and I can play a longtime.
When I run only one instance of my project I get 120 fps or over.
When I run two instance with the multiplayer it running at around 60 70 fps.
I have try many configuration about the PIE mode but nothing really change.

I don’t have get the chance to test my project over the internet or on lan with multiple computers.
I have only test my project in the same computer.
I use unreal engine 4.18.1 with a nvidia 1060 gtx

You can see here in this video at 1:34secs and at 4:21secs and at 10:23 secs…
Some time the freeze is more long it never exactly same.

Sorry about my english.
15

Apologies as I’ve missed out the reply. Thank you for your respond.

Q: How many clients are you running? Does this occur when running one or two clients as well or only with more than that?
only when 2 or more…

Q: Which OSS are you working with?
4.15.1 Binary version

Q: Do you see any settings in your DefaultEngine.ini related to timeout, such as AsyncTimeout or P2PConnectionTimeout that you could potentially increase?
I have this under OnlineSystemSteam but I doubt it’s applicable in Editor
P2PConnectionTimeout=90, I will try increasing them. I also have “InitialConnectTimeout=120.0” under [/Script/OnlineSubsystemUtils.IpNetDriver] , what settings do you propose I increase and how much?

16

Was this ever resolved or figured out? I’m seeing the same thing in the Shooter Game in editor so far only.

Lots of

LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 8.12, Realtime: 8.12. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 15.03, Realtime: 15.03. IpNetDriver_13
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_12
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 7.21, Realtime: 7.21. IpNetDriver_13

17

Hello,

The warning itself is fairly explanatory - the time between frames is really long (8 ~ 15 seconds in the cases you’ve pointed out).

Unfortunately, there could be a number of reasons for this:

  1. If you’re running multiple instances of the Game / Editor, only the one in the foreground will have focus. This may include PIE sessions (although, it may not). When a instance of the Game or Editor is not in focus the OS (i.e. Windows) has the ability to, and almost always will, reduce the amount of CPU time given to that instance. This alone could legitimately cause the tick times between frames to drop to only a few times a second. In some cases, it may even be multiple seconds between frames.

  2. Similarly, if you have other potentially intense software running on your PC at the same time (video capture, virus scanners, other computationally or graphically intense software, etc.) this could cause some issues (although I wouldn’t expect it to cause several seconds worth of hitching, unless it was a high priority process).

  3. If you’re trying to do a lot of heavy lifting on a single PC that can’t handle it, resource contention may also be at play. With that in mind, what are the Specs of the PC you are using.

  4. When Sean had asked about the OSS, he meant the Online Subsystem. Unfortunately, Binary 4.15.1 doesn’t really tell us what you’re using, as the OSS refers to specific platforms (Steam, Oculus, PS4, etc.) I’m going to guess you’re likely using the Null OSS (the unconfigured default), but please correct me if I’m wrong.

What I’d recommend is using the Stats system to determine where these hitches or delays are coming from.

https://wiki.unrealengine.com/Profiling,_How_To_Count_CPU_Cycles_Of_Specific_Blocks_Of_Your_Game_Code

What I’d start with is stat dumphitches to see if there’s any repeated offender. If that doesn’t make things clear, try waiting until your game instance is running very poorly and do a stat startfile, wait for a few seconds, and then do a stat stopfile. This will generate a stat capture which can be viewed in the Profiler tool and you can dig into what may be causing the issues.

As Sean has said, this very likely is not a bug in the engine itself. We do extensive regression testing before releases. While this process is not perfect and things can slip through, egregious issues like this are always grounds for Hotfixes, so if this was something found internally or by any of our licensees it would have been fixed.

That, given how easily you can repro it, I’m more inclined to believe it has something to do with your specific setup.

I already asked, but I figured I’d mention again so it’s not lost in a sea of text. Can you please provide the Specs of your machine, including your GPU, CPU, RAM, Operating System, etc.

Apparently the game freezes ( on both
clients ) together with the editor as
many seconds as it says hence it’s
impossible to debug anything when this
happens.

Even if the game freezes, you could still use stat dumphitches to get a report. You’d just need to make sure that was running before the hitch. E.G., you could start the game instances, immediately enable stat dumphitches, and then wait for a freeze.

Thanks,
Jon N.

18

After further investigation, it appears that this is not a bug. The reason for this is that when the client is running at low FPS it wont have any room to replicate because the actor replication is done in the game thread.

This is just a warning and should be safe to ignore unless it causes issues with actual functionality.

19

I think I have find from where the problem come in my project.
Thanks about all the profiling informations.
I’m pretty new with unreal, and really noob with the network stuff.
At the begin I have learn some methods to implement the multiplayer from youtube video.
After this I have start to rebuild my solo game to a multiplayer game.
To control the characters animation and rotation and more, All need to come replicated.
To do this I need to update all my replicated variables from the character tick… because the animation bp don’t replicate if i’m not wrong.
Because i’m new and from what I have learn at the begin… I have badly implement this tick part.
At the begin I have use a custom event for the server replications and one custom event for the remote client. This both custom event called on my character tick cause my lag problem and is my noob error :slight_smile:
All my characters animation appear to updating good anyway with my error but I don’t need this both custom event, Because my variable is all replicated. I only need to check authority and add all my anim and rotation data just after this. Now all seen to work like a charm and I can run 4 instances without lag or freeze.
Sorry about my english again, and many thanks for all informations in this post thread.

20

This seems to be an ongoing problem that only happens on some machines and some builds of UE4 but not others. (I do not think this should be marked as resolved. but i also agree these are the types of issues that are hard to address as they are hard to reproduce consistently).

My OS is win10pro64 build 16299.125) …
I do not get the issue on UE4.15.3
But I do get the issue on UE4.18.2

Here’s the steps I did to recreate the issue…

Create a brand new empty blueprint project, then set number of players to 2 and press play (everything works fine in this case with just 2.)

If I set numbers of players to 3 and press play the windows spawn but the editor (server) and both client windows lock up for 30 seconds and I see these messages in the log…

LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 0.01, Realtime: 30.15. IpNetDriver_7
LogNet: UNetDriver::TickDispatch: Very long time between ticks. DeltaTime: 30.19, Realtime: 30.34. IpNetDriver_5

I’ve had someone else try on their machine machine and they had no problems on 4.18.2. So It seems this is something that only happens on certain machines (perhaps a bug in certain network drivers?)

The key points after reading everything above and what i’ve seen are:

  1. It doesn’t happen to everyone but it does seem to be affecting several people.
  2. For the people it affects the lockup happens when we go over 2 PIE instances (three players without dedicated, two players with dedicated server option)
  3. It’s a combination of UE4 version and something else (buggy network driver?) so it’s hard to reproduce.
  4. However even on my machine everything works fine in UE 4.15.3 but UE 4.18.2 locks up for 30 seconds. So if it is something like a buggy network driver UE4.15.3 is dealing with it better.
  5. Update: The lockup doesn’t happen on the first play attempt after launching the editor .exe with the project. But it happens every play attempt after.