Date: Sun, 24 Oct 1999 14:31:03 +1000 (EST) From: Tony Jago <T.Jago@its.uq.edu.au> To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, samba@samba.org Subject: Very Poor Samba -> Win9x performance Message-ID: <Pine.BSF.4.10.9910241401400.98311-100000@doughnut.cc.uq.edu.au>
next in thread | raw e-mail | index | archive | help
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@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@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9910241401400.98311-100000>