What does "Grab network data" step in performance monitor?

please what exactly does this step do (found in performance monitor)? Thanks. :slight_smile:


It’s a generic event for most network-based operators (such as the UDP In DAT) and is triggered when checking for data received from the network socket.

@eric.b thanks for reply. However I am a bit confused - please what is the difference between “Grab network data” and “Network Message Check”?

Up until now I have thought there is just one place where new packets are being received - that being “Network Message Check” which is always placed somewhere at the start of a new frame. Therefore seeing “Grab network data” (which tends to be executed much later) got me thinking what is happening under the hood. Thanks.

“Grab Network Data” is at the socket level and “Network Message Check” is a layer up from that at the OP level. The role of the “Network Message Check” is to determine if the OP needs to cook and process any received messages. I hope that clears things up.

1 Like

Oh, now things are starting to make sense to me.
I have realized the position at which “Grab Network Data” is performed is causing me quite a lot of problems. Up until now I have thought TouchDesigner receives packets from socket right at the start of the frame (in “Network Message Check”) and processes them right away. I have been struggling to understand why I am getting one more frame of latency in some very specific scenario. Please feel free to correct me if I am wrong - maybe I have misunderstood this thing and falsely thought this is the root of my problem :smiley:

The thing is - I have a device that sends data to TouchDesigner right on frame start (determined by tri-level sync). TouchDesigner starts cooking the frame very short time after that (it is also locked to the same tri-level sync as it waits for image from AJA card to start cooking). This means TouchDesigner should have the latest data, but so far I was always getting the data from previous frame. Now that I now this, I feel like this is what is happening. Packet arrives to NIC couple of microseconds after the frame starts and is ready to be received with socket call. About a millisecond later TouchDesigner starts with “Network Message Check”, where it processes old data from last frame (the ones “Grab Network Data” received from socket on previous frame). Then in progresses further in cook process and later it performs “Grab Network Data” where it receives the packet that have already been available on start of the frame. This packet is then handled on OP level on the next frame… Am I right? I feel like this is the cause of the latency I am seeing (and unsuccessfully fighting) for a long time.

In case I am right, please wouldn’t it make sense to perform “Grab Network Data” as the first thing on start of the frame and then continue with “Network Message Check”? I imagine this way we would receive latest packets from socket and we could process them right away (without waiting for the next frame)?


Grab Network Data should already occur at the beginning of the frame. Which operator do you experience this issue with? Not all operators work the same with how they receive/process data.

Oh, I didn’t see it there (when looking at Performance Monitor) so I thought it occurs only later in frame. I am using UDP In DAT.

So if Grab Network Data is executed also before Network Message Check (when using UDP In DAT) my theory described in previous post is invalid… :smiley: Sorry about that.
Hmm and may I ask whether is Grab Network Data executed right before Network Message Check (meaning nothing else cooks between those two)?

In the case of the UDP In DAT:

The Network Message Check can sometimes be triggered before the Grab Network Data call (though they both still happen at the beginning of the frame). But it doesn’t really matter since the UDP In DAT will trigger its own grab data anyway, so there shouldn’t be any latency due to packets not grabbed before the cook.

1 Like

I see. That definitely breaks my theory. Anyway thank you very much for explanation. I guess I have to go back to the drawing board (or rather the oscilloscope) and find the real cause of my latency issue :slight_smile:

1 Like