Confounding lag with TD Networking

Beginners
1

I’m new to networking besides websockets, and have data from VirtualDJ that I’d like in TD.

I’ve had success in being able to do that, but certain actions cause a significant (60+ seconds before recovery significant) lag spike for reasons that I cannot determine.
The protocol is os2l, aka JSON over TCP/IP.

I started with a tcpipDAT and a few scriptDATs for processing.
Thinking that TCP being reliable and ordered (and increased TCP packet size at time of spike) may have relevance, I switched to UDP by writing a python middleman to forward the TCP packets to TD as UDP.

I figured that if there was some lag induced by TCP, in this scenario the middleman would experience spikes but TD would not.

This is not the case. Instead, it appears as though the middleman experiences no spike, but TD still does.

  • Lowering the poll rate to every 250ms did not resolve the issue.
  • The size of the UDP packet TD receives is no larger at the time of spike. (The middleman reformats it as to not be.)
  • The time between TD receiving UDP packets does not increase by more than 10% at the time of spike.

The performance monitor gives me the infinitely helpful “Presenting Windows” as the cause. Any entry regarding the udpoutDAT totals only ~0.2ms.
Disabling the containers which displayed the data did not resolve the issue.
Vsync is not on. The gpu is not overloaded.

Is this a bug? Both TCP and UDP experience the same issue.
Is my understanding of UDP incorrect? (“Fire and Forget” has one or more asterisks?)
What on earth is happening?

2

Hard to tell.
Best way here is to strip down your project to an absolute minimum. This helps your for one to confirm that your packages are the actual problem, but also makes it possible for others to test your setup to get a better feeling for the problem, because tbh I cannot realy envison your setup and reasons/solutions for your problem.

3

You could say that again.

After sleeping it off and extensive testing—and the problem persisting even when the server isn’t even connected :person_facepalming:—I’ve determined that the GPU was being absolutely hogged by VirtualDJ to calculate stems for tracks. This eluded me originally because I forgot that task manager doesn’t accurately report GPU stats.

Bafflingly, the task manager process that takes credit for that analysis is “Desktop Window Manager”, so that’s likely why performance monitor was confused.
I’ve since altered performance settings within VDJ and am running smoothly.

Sorry for the trouble.