Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Oct 1999 18:33:06 +1000 (EST)
From:      Tony Jago <T.Jago@its.uq.edu.au>
To:        Julian Elischer <julian@whistle.com>
Cc:        freebsd-net@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG
Subject:   Very Poor Samba -> Win9x performance [more]
Message-ID:  <Pine.BSF.4.10.9910251820510.98311-100000@doughnut.cc.uq.edu.au>
In-Reply-To: <Pine.BSF.4.10.9910232218230.4943-100000@current1.whistle.com>

next in thread | previous in thread | raw e-mail | index | archive | help

 Further to my problem with slow smbclient "put"'s.

 1. FreeBSD 3.[23] machine -> Win98  slow (9k per second).
 2. Solaris machine        -> Win98  fast (500+k per second).
 3. FreeBSD 2.2.7 machine  -> Win98  fast (500+k per second).

 Just incase I was doing something insane, I installed a brand new
 3.3-RELEASE machine running the GENERIC kernel, installed samba from the
 ports and did a smbclient "put" - still very slow performance. This is
 very repeatable, I have tryed this on 3 different hardware platforms on
 different networks and different network cards, they all do exactly the
 same thing.

 Tweeking with the samba config file makes no difference, this must be
 something way beyond that. We are talking 9k a second, not much more then
 a modem out of 100M ethernet cards on switched networks! These machine
 can ftp at rates closer to 5 megabytes a second and above.

  smbclient \\\\win98box\\test -N -c "put 1mfile"

 Could some reading this that has samba installed on a FreeBSD 3.3 machine
 please try this just so that I know that I am not going insane?

 Thanks

   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.

> 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.9910251820510.98311-100000>