I have a capture and the network has redundancy built in. I and doing some captures for a client to help them determine why they are losing connection. in the capture, I see a Lott of window updates 740 I see duplicate acks 98 and I see TCP missed segment captured 98 My question is will a huge number of window updates cause a problem on the network? I know window updates are normal, but when there are a large number of updates, I am just wondering about that because I was ask what is the next step to improve the performance In short I don’t know can someone help thanks There are no windows zero or windows full asked 26 Mar '13, 20:52  Ernest Johnson edited 27 Mar '13, 03:08  grahamb ♦ |
One Answer:
No. Window updates are basically status messages about one node announcing a new window size in a TCP packet that contains no other new information. Depending on the application's communication profile it is quite common to have a lot of those. Zero Window and Window full are much more interesting for performance troubleshooting, but you say you've got none. Without a trace it is kinda hard to help in troubleshooting connection loss issues, so all I can tell you is that you do not have to worry about Window updates in most cases. answered 27 Mar '13, 02:18  Jasper ♦♦ showing 5 of 12 show 7 more comments |
I if add the capture will that help i just have to figure out how to upload it to the system
i am also seeing high delta times in the trace between the two servers
Yup, a trace would help, please put it on http://www.cloudshark.org and post the URL.
High delta times have no meaning unless you can see the conversation in context, so having the trace would help to determine what the problem may be.
once i figure out how to get the 64meg file upload i will get it to you
maybe you can do a partial upload. Wireshark allows you to export packets of a certain packet range, so if you have a section in the big trace that shows what your problem is as an example, cut it out and post it. See File -> Export specified packets to do that.
https://www.cloudshark.org/captures/be154089189d
I did a smaller capture for a time where the user said that she lost connection for afew sec 6:37am
I see a lot of keep-alives and that is whee the high delta times are not quite sure what that means
I appricate your help much Happy Easter
https://www.cloudshark.org/captures/be154089189d Here is a link to the file, i captured a time or around 6:37am when the users stated that there was a disconnect between the server and the database.
there are a lot of keep-alive in the trace
Thanks your much
Ernest
have a good weekend
Keep-Alives are not a problem; in fact they are neutral or positive. Keep-Alives mean that both nodes do not have data to send, so they send each other some sort of "let's prevent this session from getting axed" packets.
Typical indicators for this are "nice" delta times between the last "data" packet and the keep-alive, as you can see for example in packet 164, with a delta time of about 30 seconds. A little strange is the fact that there are repeated keep-alives within a few milliseconds, but maybe one node got a little impatient when the Keep-Alive-ACK doesn't arrive quickly enough, so it sends another one.
So far there is no indicator in that partial trace why a connection would be lost; I checked and colorized all TCP conversations in your trace and they're all ongoing without any obvious problem. Maybe you can scan your larger trace for Reset packets? Filter would be "tcp.flags.reset==1". If you find a sample like that it would help to tell what happened, but if you don't see any you could try to find other session terminations by looking for FIN packets.
Have a good weekend, too!
so you dont see any issues with that trace why all th keep-alives
not thing comes up for tcp.flags.reset==1 the trace is much bigger, so you have mover keep-lives but it look the same as the one it just sent you.
i thanks the problem is with the application
Keep-Alives happen when users don't use the application or are using it but the application is not sending data back and forth (for example if a user fills out a large form and sends it minutes later). Keep-Alives prevent that the connection gets torn down; otherwise the user would see a "nice of you to want to send data now, but the connection is lost after you worked on the form too long" message - and he's not going to be happy about that. So Keep-Alives are helping to prevent that.
My guess is - if you don't see TCP connections fail (usually resets), it's probably the application.