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
>