NETTIME does not just mean net time

I saw a post which mentioned NETTIME and where people assume it is the network time.   It is more subtle than that.

If NETTIME is small then dont worry.   If NETTIME is large it can mean

• Slow network times
• Problems processing messages at the remote end

Consider a well behaved channel where there are 2 messages on the transmission queue

In this case the NETTIME is the total time less the time at the receiver end.  So NETTIME is the network time.

In round numbers

• it takes 2 millisecond from sending the data to it being received
• get + send takes 0 ms ( the duration of these calls is measured in microseconds)
• receive (when there is data) + MQPUT and put works, takes 0 ms
• commit takes 10 ms
• it takes 1 ms between sending the response and it arriving.
• “10 ms” is sent in the response message

This is a simplified picture with details omitted.

The sender channel sees 13 ms  between the last send and getting the response.  (13 ms – 10 m)s is 3 ms – the time spent in the network.

Now introduce a queue full situation at the receiver end

In round numbers

• it takes 2 millisecond from sending the data to it being received
• get + send takes 0 ms ( it is in microseconds)
• receive (when there is data) takes 0 ms
• the pause and retry took 500 ms
• the second receive and MQPUT takes 0 ms
• commit takes 10 ms
• it takes 1 ms between sending the response and it arriving.
• “10 ms” is sent ( as before) in the response message (the time between the channel code seeing the “end of batch” flag and the end of its processing
• Buffer 3 with the “end of batch” flag was sitting in the TCP buffers for 500 ms

The sender channel sees 513 ms  between the last send and getting the response.  513 ms – 10 ms is 503  ms – and reports this as ” the time spent in the network” when in fact the network time was 3 ms, and 500 ms was spent wait to put the message.

Regardless of the root cause of the problem, a large nettime should be investigated:

• do a TCP ping to do a quick check of the network
• check the error logs at the receiver end
• check events etc to see if the queues are filling up at the receiver end