How to debug 100x variance in writing the same file?

Richard Sharpe rsharpe at
Sat Jan 22 22:36:49 GMT 2005

On Fri, 21 Jan 2005, John Gerth wrote:

> > OK, to be more specific, if a packet is dropped towards the end of a
> > read response (or a write request) where there are no subsequent segments
> > to trigger normal TCP behavior (fast-retransmit) then we will see big
> > reductions in throughput as Chris mentions.
> >
>   Interesting...there's clearly going to be some learning curve here as
>   I'll also have to look at traces of non-delayed writes to become familiar
>   with normal behavior.
>   Is the packet timeout you mention configurable for SMB or is
>   it TCP specific for the OS?

This is a function of the TCP layer. It computes a retransmit timeout
(RTO), which is typically a function of the smoothed round trip time that
the TCP layer is seeing for the connection.

When a segment gets dropped by the network, if there is more data coming,
then the subsequent segments will cause the receiver to issue acks
pointing to the dropped segment (there is an RFC on this, and Richard
Stevens' book has a good description). Once the sender sees a couple of
acks for a segment it has already sent it is supposed to resend that
segment on the assumption that the receiver hasn't got it because it got
dropped. However, at the end of a higher layer request or response, there
are no more segments, and we have to wait for RTO to go off.

>   Does any of this get reported in high number (10?) debug logs?

Samba doesn't see these problems. The TCP layer works it out, but
introduces a big delay.

>   I'm asking because the delay I observe on the client's Task Manager network
>   activity graph is on the order of *tens of seconds* of no activity.

Then there is something really wrong. RTO is often set to something like
four times the SRTT value, and I have not normally seen anything more than
a few milliseconds.

A trace would be useful, as we said before, so we can see where the delay
is and what is actually causing it. It would be useful to mentin again
what OSes are involved.

Richard Sharpe, rsharpe[at], rsharpe[at],

More information about the samba-technical mailing list