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

What are the causes of slow response between two host?


We are using the SAS progaram to run through a drive that is in the data center and the user are experiencing real slowness on a gig link running wireshark I saw a lots of [TCP segment of Reassembled PDU] between two host and the program runs so slow.

10.119.xx.yy    10.120.xx.yy    TCP 1514    [TCP segment of a reassembled PDU]
10.119.xx.yy    10.120.xx.yy    TCP 1514    [TCP segment of a reassembled PDU]
10.119.xx.yy    10.120.xx.yy    TCP 1514    [TCP segment of a reassembled PDU]
10.119.xx.yy    10.120.xx.yy    TCP 1514    [TCP segment of a reassembled PDU]

Transmission Control Protocol, Src Port: eims-admin (4199), Dst Port: netbios-ssn (139), Seq: 64145, Ack: 52, Len: 1460

Window size value: 63710

The network seems to be not the issue here as we are utilizing less than 10% of the Bandwidth. The latency between sites is 6ms when we do traceroute and ping.

Please assist in explaining / analyzing what this means?


asked 25 Oct ‘11, 11:01

mEc's gravatar image

accept rate: 0%

edited 27 Oct ‘11, 07:53

multipleinterfaces's gravatar image


One Answer:


The frame from your posting is part of a message from the workstation to the server. This can be deducted from the destination port 139.

The hint "TCP segment of a reassembled PDU" indicates that the workstation is sending a large message to the server. In fact the message is so large that it is split over several frames. As soon as Wireshark sees the last frame it pieces the segments together and decodes the whole message.

As you have provided some interesting and important information we can find one probable cause for the sluggish response.

The TCP window size controls how many bytes a sender can transmit to the remote end. The window size can roughly be compared to the volume of a water hose: If you don't have enough water in the hose water comes out sputtering. If you have too much water the pressure blows a valve.

The "volume of the network pipe" can be calculated by multiplying the bandwidth given in byte per second with the round trip time. For your network the calculation goes like this:

  • Slowest link = 1 Gigabit per second = 125 MByte/sec = 125.000.000 Byte/sec
  • Round Trip Time = 6 msec = 0,006 sec
  • Window Size = 125.000.000 * 0,006 = 750.000 Byte

If the client is running Windows XP this will not be a problem, as SMB requests are limited to something less then 64 kB. If the client is running Windows Vista or 7 the window size can be a problem, as the client can request more than 64 kB at a time using SMB pipelining - if the SAS programmer was smart enough to use the right system calls.

Also, SMB is not the best protocol for WAN links. This is discussed in this answer to another question.

Last, but not least you want to check if the server is busy. Wireshark has some excellent tools for that: Statistics -> Service Response Time -> SMB is a huge help. Use the display filter ip.src == 10.120.yy.yy (your servers address) to focus on the response times for just this server. Finally an advanced IO graph showing the server load for your server reveals the number of concurrent requests handled by that system.

Good hunting!

answered 26 Oct '11, 07:00

packethunter's gravatar image

accept rate: 8%

edited 27 Oct '11, 07:51

multipleinterfaces's gravatar image


PH has given an excellent response here. SMB + WAN = headache. 6ms RTT isn't so bad though, and you seem to have plenty of bandwidth. You need to determine if the client and/or server is/are having resource contention issues - check CPU and disk I/O while the transfer is going on. An overactive antivirus can also slow things down depending on what kind of file(s) you're transferring.

(27 Oct '11, 06:14) GeonJay

What a great explanation.Thanks. You helped me, help myself in debugging a network sluggishness issue. Search is a wonderful thing.

(09 Jun '14, 10:07) kwold