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

[John Gerth]

Richard Sharpe wrote:
> On Fri, 21 Jan 2005, Christopher R. Hertel wrote:
> 
> 
>>The problem we are suggesting *may* be the source of your headache is the
>>request/response nature of the higher-level SMB protocol.
>>
>>With a stream protocol, if a packet is dropped it is simply resent a few
>>packets later and the receiving end pops it back into its correct place
>>and all is well.  Other packets continue to flow so there is little
>>interruption.
>>
>>With a request/response protocol, if a packet is dropped the entire
>>transaction gets held up.  You have to wait until the timeout expires
>>before the dropped packet is resent, then the transaction is processed,
>>then the response is sent and, once again, if you lose a packet you wait.
> 
> 
> 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?

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

  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.