Date: Sat, 23 Oct 1999 22:18:58 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: Tony Jago <T.Jago@its.uq.edu.au> Cc: freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG, samba@samba.org Subject: Re: Very Poor Samba -> Win9x performance Message-ID: <Pine.BSF.4.10.9910232218230.4943-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.10.9910241401400.98311-100000@doughnut.cc.uq.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 > 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.9910232218230.4943-100000>