We found the network delay about 20 seconds.
The result is like the below.
A packet(1510 Byte) was sent by 5 fragments(Number 47215, 49041, 50848, 52765, 52785) The delay for each segment was 5 seconds.
For this test, i didn't set 'tcp window size' and 'nagle option' on Window Server 2008 R2 64bit.
I have two questions. 1. TCP window size on screen shot as you see is under 256. Is this normal? 2. A long packet delay was found between segments. Is this normal?
Please give me your help for solving those problems.
asked 22 Dec '10, 18:28
That's on the same subnet. There's some out of order stuff going on. So basically some frames are being destroyed between the source and destination. Is there a duplex mismatch somewhere? Is anything hard coded to full?
answered 22 Dec '10, 18:55
Regarding the Window Size: I'd say it's normal, I see sizes like that a lot, and usually for Vista/2008 and up. These OSes use the TCP window scaling option (RFC 1323), which means that the specified window size is multiplied by a certain scale factor. Vista and 2008 often use a scale factor of 8, which means that the window size is multiplied by 2^8 (256). So for example if your window is 256 you need to calculate the scaled window, which is 256*256=65536.
Wireshark can calculate the scaled window size for you if you enabled it in the TCP settings ("relative sequence numbers and window scaling"). Since the scale factor is only agreed upon within the SYN-SYN/ACK packets of a connection you need to make sure you capture them, otherwise Wireshark doesn't know what the scale factor is and can only show the base value, which I guess is what happened in your trace.
answered 23 Dec '10, 01:11