Very Poor Samba -> Win9x performance

Sun Oct 24 05:18:58 GMT 1999

did you use the port?
there is a patch in the ports for a slowness problem.

On Sun, 24 Oct 1999, Tony Jago wrote:

> 
>  Hello, when transferring a file from a FreeBSD box to a Win9x share using
>  smbclient the performance appears to be very slow (ie. about 10k per
>  second). I am running FreeBSD 3.3-STABLE (as of 24/10/99) and Samba
>  2.0.5a although the problem occurs on slightly older versions of FreeBSD
>  and of samba.
> 
>  As you can see, the get and put performance is vastly different. The
>  tests were performed on a dedicated network.
> 
> # smbclient \\\\panic\\upload -N -c "put 1mb.dat"
> Added interface ip=10.0.2.1 bcast=10.0.2.255 nmask=255.255.255.0
> Got a positive name query response from 10.0.2.18 ( 10.0.2.18 )
> putting file 1mb.dat as \1mb.dat (9.82971 kb/s) (average 9.82971 kb/s)
> 
> # smbclient \\\\panic\\upload -N -c "get 1mb.dat"
> Added interface ip=10.0.2.1 bcast=10.0.2.255 nmask=255.255.255.0
> Got a positive name query response from 10.0.2.18 ( 10.0.2.18 )
> getting file 1mb.dat of size 1048576 as 1mb.dat (425.603 kb/s) (average
> 425.603 kb/s)
> 
>  If I boot the FreeBSD box into Windows then it can transfer files to the
>  other windows box at high speed.
> 
>  I have reproduced the problem on 3 different FreeBSD boxes and 2
>  different windows boxes (win95 & win98).
> 
>  I am unsure if the problem is a TCP problem or a Samba problem. During
>  the slow transfer, netstat always reports 2111 bytes in the SendQ on the
>  BSD box.
> 
> # netstat -n     
> Active Internet connections
> Proto Recv-Q Send-Q Local Address         Foreign Address       (state)
> tcp        0   2111 10.0.2.1.1108         10.0.2.18.139        ESTABLISHED
> 
>  A tcpdump of the transfer however shows some longish pauses waiting for
>  the windows box to reply. This pause seems to be about the same length of
>  time no matter if the windows box is is a Pentium 120 or a PII 333.
> 
>  10.0.2.1 (FreeBSD PC)       10.0.2.18 (Windows 95 PC)
> 
> # tcpdump -i ed0 -n
> tcpdump: listening on ed0
> 14:22:47.143804 10.0.2.1.1282 > 10.0.2.255.137: udp 50
> 14:22:47.144432 10.0.2.18.137 > 10.0.2.1.1282: udp 62
> 14:22:47.444199 10.0.2.1.1109 > 10.0.2.18.139: S 811544824:811544824(0)
> win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> (DF)
> 14:22:47.444710 10.0.2.18.139 > 10.0.2.1.1109: S 17659612:17659612(0) ack
> 811544825 win 8760 <mss 1460> (DF)
> 14:22:47.444921 10.0.2.1.1109 > 10.0.2.18.139: . ack 1 win 17520 (DF)
> 14:22:47.704063 10.0.2.1.1109 > 10.0.2.18.139: P 1:77(76) ack 1 win 17520
> (DF)
> 14:22:47.704723 10.0.2.18.139 > 10.0.2.1.1109: P 1:5(4) ack 77 win 8684
> (DF)
> 14:22:47.705465 10.0.2.1.1109 > 10.0.2.18.139: P 77:245(168) ack 5 win
> 17520 (DF)
> 14:22:47.706348 10.0.2.18.139 > 10.0.2.1.1109: P 5:86(81) ack 245 win 8516
> (DF)
> 14:22:47.718935 10.0.2.1.1109 > 10.0.2.18.139: P 245:339(94) ack 86 win
> 17520 (DF)
> 14:22:47.719783 10.0.2.18.139 > 10.0.2.1.1109: P 86:131(45) ack 339 win
> 8422 (DF)
> 14:22:47.726618 10.0.2.1.1109 > 10.0.2.18.139: P 339:431(92) ack 131 win
> 17520 (DF)
> 14:22:47.728456 10.0.2.18.139 > 10.0.2.1.1109: P 131:177(46) ack 431 win
> 8330 (DF)
> 14:22:47.729473 10.0.2.1.1109 > 10.0.2.18.139: P 431:509(78) ack 177 win
> 17520 (DF)
> 14:22:47.732845 10.0.2.18.139 > 10.0.2.1.1109: P 177:246(69) ack 509 win
> 8252 (DF)
> 14:22:47.740104 10.0.2.1.1109 > 10.0.2.18.139: . 509:1969(1460) ack 246
> win 17520 (DF)
> 14:22:47.933404 10.0.2.18.139 > 10.0.2.1.1109: . ack 1969 win 8760 (DF)
> 14:22:47.933898 10.0.2.1.1109 > 10.0.2.18.139: P 1969:2620(651) ack 246
> win 17520 (DF)
> 14:22:47.935734 10.0.2.18.139 > 10.0.2.1.1109: P 246:297(51) ack 2620 win
> 8109 (DF)
> 14:22:47.936794 10.0.2.1.1109 > 10.0.2.18.139: . 2620:4080(1460) ack 297
> win 17520 (DF)
> 14:22:48.135970 10.0.2.18.139 > 10.0.2.1.1109: . ack 4080 win 8760 (DF)
> 14:22:48.136422 10.0.2.1.1109 > 10.0.2.18.139: P 4080:4731(651) ack 297
> win 17520 (DF)
> 14:22:48.138145 10.0.2.18.139 > 10.0.2.1.1109: P 297:348(51) ack 4731 win
> 8109 (DF)
> 14:22:48.139198 10.0.2.1.1109 > 10.0.2.18.139: . 4731:6191(1460) ack 348
> win 17520 (DF)
> 14:22:48.338442 10.0.2.18.139 > 10.0.2.1.1109: . ack 6191 win 8760 (DF)
> 14:22:48.338894 10.0.2.1.1109 > 10.0.2.18.139: P 6191:6842(651) ack 348
> win 17520 (DF)
> 14:22:48.340633 10.0.2.18.139 > 10.0.2.1.1109: P 348:399(51) ack 6842 win
> 8109 (DF)
> 14:22:48.341720 10.0.2.1.1109 > 10.0.2.18.139: . 6842:8302(1460) ack 399
> win 17520 (DF)
> 14:22:48.540938 10.0.2.18.139 > 10.0.2.1.1109: . ack 8302 win 8760 (DF)
> 14:22:48.541398 10.0.2.1.1109 > 10.0.2.18.139: P 8302:8953(651) ack 399
> win 17520 (DF)
> 14:22:48.543140 10.0.2.18.139 > 10.0.2.1.1109: P 399:450(51) ack 8953 win
> 8109 (DF)
> 14:22:48.544242 10.0.2.1.1109 > 10.0.2.18.139: . 8953:10413(1460) ack 450
> win 17520 (DF)
> 
>  I do have "tcp_extensions" switched on but I have tried putting them off
>  and tweaking with the Microsoft TCP stack as well and it makes no
>  difference. Samba has "TCP_NODELAY" as a socket option. 
> 
>  If anybody can shed some light on this problem it would be great. Thanks
>  in Advance,
> 
>   Tony
> 
> ---
> Tony Jago, System Administrator,        E-Mail: T.Jago at its.uq.edu.au
> Server and Security Group,               Phone: +61 7 3365 4078
> Information Technology Services,
> The University of Queensland.  Brisbane, Australia. 4072.
> 
> 
> 
> To Unsubscribe: send mail to majordomo at FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message
> 