This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Transmission delays 5 seconds in W7

0

Dear All,

we are using a 64 bit W7, PC. It communicates with a PLC in a production plant. Sometimes our outgoing message is delayed 5 seconds, causing alarms and production comes to stop. How do we change the setting so that our PC re-transmitts not after waiting 5,000 ms but 500 ms?

Please advice, Knocking

asked 20 Dec '14, 10:02

Knocking's gravatar image

Knocking
11112
accept rate: 0%

This is difficult to answer, because the reason for the delay for the outgoing message is unclear. Do you have a capture of this happening that you could share?

(20 Dec '14, 10:17) Jasper ♦♦

KB2861819 adresses the 5 second TCP delay in Windows 7. It's not 100% guaranteed, but it fixed 4 differnt delay problems for me.

(20 Dec '14, 14:27) DarrenWright

Hello again, and thank you for showing interest in this problem.

I have studied the WS logging and can send it to you along with the PC log showing what and when entries are made in our C# code.

I think one can conclude that it is the C# code which does not read the incoming message immediately but waits. When it is read the answer is immediate which can be confirmed also in WS logging - outgoing message.

I guess the question has come to why our C# code do not read what is available?

I am happy to send log files (approx 550 kb), if you only can tell me how or where?

Best regards Knocking

(21 Dec '14, 03:49) Knocking

Also, it seems as if the problems are less when we run the software as Administrator. (the windows firewall is turned off.)

Best regards Knocking

(21 Dec '14, 03:52) Knocking

I am happy to send log files (approx 550 kb), if you only can tell me how or where?

upload them on google drive, dropbox or cloudshark.org and then post the link here.

(27 Dec '14, 08:57) Kurt Knochner ♦

Dear All,

there are 3 files:

  1. Shark file.
  2. Log file from our software
  3. Excel document to assist in comparing.

Thank you for all help!

https://drive.google.com/folderview?id=0B-2RoGZWzudQRGlLSmlTU0pNb2s&usp=sharing

(08 Jan '15, 03:17) Knocking

Please add more details where in the capture file (frame number!) you see the 5 second delay.

(08 Jan '15, 04:40) Kurt Knochner ♦

Dear All,

please see the following description/comments:

On row no 2188 a query was received on board 7087. On the next no (2189) the data had been processed by our software and response was sent. Total processing time was approximately 10 ms.

For the next board (7088) the situation is different. On row no 2192 the query was received by WS but the response was sent approximately 5032 ms later, on row 2205. In the log for the software we can see that the data was received and response sent within a few ms. Also, this timestamp correlates to the response in WS. However, our software did not start the processing after a delay of approx 5010 ms. So, the query was detected by WS and detected by our software 5010 ms later. (Immediately the software processed and sent the response, which also is confirmed in WS.)

Of course this pattern occurs regularly (see row no 2501, 2502, 2503, 2524) . The delay in our logging is always 5000 ms (+5 to +15 ms).

We find it very strange that when there is a delay, it is always 5000 ms. Of course, there could be a capacity problem on our CPU but the delay should differ, which it doesn´t.

Anybody who can advise? Any help appreciated.

Knocking

(08 Jan '15, 08:49) Knocking
showing 5 of 8 show 3 more comments

One Answer:

0

For the next board (7088) the situation is different.

If you set a filter for that TCP stream, you will see the following.

alt text

Frame 2192: Client (.6) sends request.
Frame 2194: ACK for that frame was received, meaning the server (.71) TCP/IP stack has seen the request and confirmed it with an ACK.
Frame 2201: The client closes the connection after 5 seconds, maybe due to a timeout.
Frame 2202: The FIN was ACKed
Frame 2205: The server sends it's response. It's unclear why this happens!!

So,

  • either frame 2192 did not really reach the server. In that case some kind of TCP proxy must be between the client/server - which is rather unlikely in this case
  • or there is a bug in the TCP/IP stack of the server
  • or there is a bug in the server software (which is what I believe).

You won't be able to figure this out with the help of Wireshark. What you probably can do:

Capture in front of the client AND server (switch mirror port) to verify what we are seeing on one capture file, currently taken at the client. If you see the same behaviour, the next step would be debugging of the server application and/or the TCP/IP stack of the server.

Regards
Kurt

answered 08 Jan '15, 09:17

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 08 Jan '15, 09:23

It's not a server, rather it's a PLC. Good luck trying to debug that. Some PLC's have a separate comms processor to handle things such as Modbus so there shouldn't be any delays caused by the real-time process loop in the PLC, but others do rely on the main process loop to handle comms.

It may be that the PLC does just take 5 seconds to respond sometimes (which is very slow), so increasing the client timeout would help. I would try increasing the timeout in the client software say to 7 seconds.

It's also possible that the client FIN wakes the PLC up and causes it to send the response, in which case increasing the client timeout won't help.

What make is the PLC?

(08 Jan '15, 09:38) grahamb ♦