Scheduling ( phantom latency ) issue

[zemerick]

Severe growing latency triggered by specific things, such as a powerful fusion reactor. CPU, GPU and network load all remain low

After some looking into it, it may be sound related. http://i.imgur.com/aM6nGTj.png?1

This shows the reactorcraft sound packet causing the client thread to wait on it, very frequently.

Additionally, during this time, the sound of the fusion reactor in my test world crackles/pops, and other sounds such as the VDG and Toroid discharges stops. Once they reactor is turned off and things catch back up, a flood of discharge sounds occurs as it all catches up.

Finally: If I turned the reactor on from a fair distance away ( about 3 chunks from the nearest piece of the reactor ), the latency never appears.

I don't yet know if this ReC sounds specifically, or if others could end up the same. I believe it is related to the substantial stacking of the fusion sound caused by my using 28 injectors. To test the other mods sounds would require another one that can be stacked very high like this.

[rkane31174]

Scheduling issues. So that's what they're called. I'm having the exact same problem in the latest version (v28a) The fusion reactor is fine if I'm only running one injector, but any more than that results in increasing latency regardless of whether I'm in single player or on a server. The reactor is fully chunkloaded, and is mostly the only thing that exists in the world.

[ReikaKalseki]

Sounds are supposed to just blindly stack, and indeed I do that all the time, and have seen it in vanilla all the time (back in 2011 and 2012 when I played vanilla). They are not supposed to "queue".

[rkane31174]

Is it possible that there are simply too many sounds playing at once? I have a bunch of VDGs, creative coils, pumps, condensers, refrigerators, and three HPTs all in the same area as the fusion reactor. They all make sounds. Lots and lots of sounds. The sound of the HPTs is also intermittent, oddly enough.

[ReikaKalseki]

Intermittency of a should-be-looped sound is typically just caused by low TPS, where the sound expires before the requisite number of ticks has passed.

As for "too many" sounds, there is nothing in the MC sound engine that imposes such a limit, nor can store a queue. That said, the paulscode sound system is too impenetrable to make the same statement with any confidence. There is a visible queue there, but it is not limited in size and is processed on its own thread.

[rkane31174]

I checked the mean tick time in the console. Normally it's about 8ms With the reactor running it increases to 11ms. TPS remains 20. It looks like nothing's wrong, but the command takes more than 8 seconds to return when the reactor is running, compared to near immediately when it isn't. I must be missing something...

[ReikaKalseki]

The internal implementation of the command is unknown and a delay in its processing cannot be taken to indicate anything, especially if TPS remains 20.

As for a tick time load from the reactor, that makes plenty of sense, but that does not indicate sounds to be the issue. Tons of Entity updates and related code almost certainly is.

[rkane31174]

That makes perfect sense, except that the reactor is chunkloaded and the problem goes away when I move far enough away from it.

[ReikaKalseki]

That would not affect server tick time - the sounds are played no matter what; being out of range simply means you do not receive the packets.

[rkane31174]

Is it the same with entity updates? This is a single player world.

[ReikaKalseki]

Entity updates are processing, not something broadcast (their position changes are broadcast, but those are not substantially expensive).