Speed problem - smbclient doesn't send duplicate ACKs in case
of pacekt loss
hno at squid-cache.org
Mon Jan 3 09:46:53 GMT 2005
On Sun, 2 Jan 2005, Heinz Knocke wrote:
> My general question is why it happens and what can I do about it? Is
> it a samba side problem or OS' ? I don't expect to be the latter,
> because netperf TCP stream gives as much as 720 Mbps.
> One thing that specially makes me wonder, is that theoretically client
> doesnt need to send duplicate ACK, because the missing segment is the
> last in the burst sent (see packet dump extract below). So it may not
> know if it's just missing or never sent. What should the TCP do then,
> what may I tune?
The client side TCP should not send a duplicate ACK in this specific case.
The source to the difference here is timing. netperf is a server
continously trying to send data to the receiver, while Samba is using a
record based protocol where the client pulls data from the server by
sending requests. If a segment is lost in a netperf stream additional
segments follows shortly and the receiver will send duplicate acks to
indicate packet loss, while if the last packet in a Samba message record
is lost then no additional data will follow until server side TCP
retransmit timeout. At least according to my fairly non-existing
understanding of the SMB protocol (no heavy use of pipelining of requests,
limited size request records most of the time).
If the lost segment is not the last packet in a message record then client
side driven TCP recovery should kick in quickly, as seen in your netperf
Note: In the above context client == data recipient, server == data
sender, but the problem applies in any direction of the TCP stream.
More information about the samba-technical