thr3ads.net - samba - Samba writing speed with big blocks [Dec 1999]

If this information is useful, please help other people find it:
Share via:

Petr Sulla

1999-Dec-12 15:38 UTC

Samba writing speed with big blocks

Hello !

I'm having serious problems with Samba's writing speed (both 2.0.5a from
RH 6.1 and 2.0.6 compiled from sources) on a 100Mbit network.

If I write a file with block size 65487 or less, then the writing speed is about
7-8 MB/s - a very nice value, my bow to the Samba team :)

If I change the block size to 65488 or more, then the writing speed falls
down to 3 MB/s, which is not what I expect from a 100Mbit network :\

Samba behaves this way even if SO_RCVBUF and SO_SNDBUF are set to 8192
and "read size" to 16384 and "max xmit" to 16384.

The corresponding part of my smb.conf looks like this:

   client code page = 852
   preserve case = yes
   socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT SO_KEEPALIVE
SO_RCVBUF=65535 SO_SNDBUF=65535
   oplocks = True
   getwd cache = Yes
   null passwords = no
   read raw = yes
   write raw = yes
   read size = 65535
   max xmit = 65535
   deadtime = 15
   strict sync = no
   interfaces = 192.168.33.2/24
   remote announce = 192.168.33.255

The box is a PIII 500Mhz, software RAID5 with read and write throughput of
30MB/s
and 15MB/s. It has RH6.1 installed, with 2.2.13ac3 kernel. The network card
uses the DECchip Tulip driver. FTP reads 9MB/s and writes 7MB/s. The tested
client was W98 SR 1.

This problem is perhaps not very interesting if you only use Explorer or
WinCommander, because they both use block size smaller than 65488. But we
use a special program with greater blocksize... :\

What causes this strange behaviour ? Is there something strange with the
2.2.13 kernel, or the ac3 patch ? What could I do about this ?
Do you experience this too ?

Please help, because my boss already makes unpolite notices about Linux and
threatens with installing NT on the server and I would be quite unhappy if
this would happen.

Yours sincerely
                        Petr Sulla

Andre Grueneberg

1999-Dec-12 17:59 UTC

head link

Samba writing speed with big blocks

-=( Hi Petr )=-

Petr Sulla schrieb:

 > If I change the block size to 65488 or more, then the writing speed
 > falls down to 3 MB/s, which is not what I expect from a 100Mbit
 > network :\ 

I had some similar experiences, but the transfer rate decrease by a factor of 
n*ten (from 5MB/s to ~120KB/s). I have had a 3com 3c905 card. After replacing 
it with a RTL8139 powered NIC, I got 5MB/s at all block sizes (tested it up to 

10MB block size using OS/2 client with a DEC Tulip NIC). I also experienced, 
that two Win95 systems didn't have these speed increases (with various kinds
of NICs (RTL8139, 3c905, DEC Tulip, AMD)), but after running Win98 or NT on 
them, I got the full speed.

BTW: No settings in smb.conf changed anything of this behaviour. And why are 
you that diappointed about 3MB/s...it's a great value...;))

 > Please help, because my boss already makes unpolite notices about
 > Linux and threatens with installing NT on the server and I would be
 > quite unhappy if this would happen.

Has he tested, whether NT can use the above rates?

  -=( CU Andre )=-         E-Mail: andre@grueneberg.de

Steve Litt

1999-Dec-12 21:07 UTC

head link

Samba writing speed with big blocks

This is just a shot in the dark, but what if you reduce max xmit=? Also,
see what your logs say during the write, and see what tcpdump says during
the write. See what kind of performance FTP has with the big blocks.

Steve Litt


At 02:39 AM 12/13/1999 +1100, Petr Sulla wrote:>Hello !
>
>I'm having serious problems with Samba's writing speed (both 2.0.5a
from
>RH 6.1 and 2.0.6 compiled from sources) on a 100Mbit network.
>
>If I write a file with block size 65487 or less, then the writing speed is
about>7-8 MB/s - a very nice value, my bow to the Samba team :)
>
>If I change the block size to 65488 or more, then the writing speed falls
>down to 3 MB/s, which is not what I expect from a 100Mbit network :\
>
>Samba behaves this way even if SO_RCVBUF and SO_SNDBUF are set to 8192
>and "read size" to 16384 and "max xmit" to 16384.
>
>The corresponding part of my smb.conf looks like this:
>
>   client code page = 852
>   preserve case = yes
>   socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
SO_KEEPALIVE SO_RCVBUF=65535 SO_SNDBUF=65535>   oplocks = True
>   getwd cache = Yes
>   null passwords = no
>   read raw = yes
>   write raw = yes
>   read size = 65535
>   max xmit = 65535
>   deadtime = 15
>   strict sync = no
>   interfaces = 192.168.33.2/24
>   remote announce = 192.168.33.255
>
>The box is a PIII 500Mhz, software RAID5 with read and write throughput of
30MB/s>and 15MB/s. It has RH6.1 installed, with 2.2.13ac3 kernel. The network card
>uses the DECchip Tulip driver. FTP reads 9MB/s and writes 7MB/s. The tested
>client was W98 SR 1.
>
>This problem is perhaps not very interesting if you only use Explorer or
>WinCommander, because they both use block size smaller than 65488. But we
>use a special program with greater blocksize... :\
>
>What causes this strange behaviour ? Is there something strange with the
>2.2.13 kernel, or the ac3 patch ? What could I do about this ?
>Do you experience this too ?
>
>Please help, because my boss already makes unpolite notices about Linux and
>threatens with installing NT on the server and I would be quite unhappy if
>this would happen.
>
>Yours sincerely
>                        Petr Sulla
>
>

David Collier-Brown

1999-Dec-13 13:37 UTC

head link

Samba writing speed with big blocks

Petr Sulla <xsulla@informatics.muni.cz> wrote:> I'm having serious problems with Samba's writing speed (both 2.0.5a
from
> RH 6.1 and 2.0.6 compiled from sources) on a 100Mbit network.
> 
> If I write a file with block size 65487 or less, then the writing speed 
> is about 7-8 MB/s - a very nice value, my bow to the Samba team :)
> 
> If I change the block size to 65488 or more, then the writing speed falls
> down to 3 MB/s, which is not what I expect from a 100Mbit network :\
> 
> Samba behaves this way even if SO_RCVBUF and SO_SNDBUF are set to 8192
> and "read size" to 16384 and "max xmit" to 16384.
> 
> The corresponding part of my smb.conf looks like this:
>    socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT
SO_KEEPALIVE SO_RCVBUF=65535 SO_SNDBUF=65535
	A quibble: IPTOS_LOWDELAY IPTOS_THROUGHPUT are opposites,
	so only one will be used. I recommend IPTOS_LOWDELAY,  but
	don't expect this to have any measurable effect in your case...
>    read size = 65535
>    max xmit = 65535
> This problem is perhaps not very interesting if you only use Explorer or
> WinCommander, because they both use block size smaller than 65488. But we
> use a special program with greater blocksize... :\
	Ok, something's out of whack.... let's go through the
	parameters first, then the testing procedure you'll need
	to apply.

1) max xmit is a parameter that is used to negotiate 
the size of the largest smb transfer unit. The code says:

/*
 * Size of data we can send to client. Set
 *  by the client for all protocols above CORE.
 *  Set by us for CORE protocol.
 */
int max_send = BUFFER_SIZE;
/*
 * Size of the data we can receive. Set by us.
 * Can be modified by the max xmit parameter.
 */
int max_recv = BUFFER_SIZE;

  If the client is requesting large buffers, Samba
will try to honor the request, and max xmit won't
help much. If you set your debug level greater than 6,
you should see a line "Client requested max send size of xxx"
in the log.

2) read size is a "buffering option for servers with mismatched disk
and
network speeds". The code says:

if (size == 0) {
    size = lp_readsize();
    size = MAX(size,1024);
}

  So it will be set to 1024 or less in transfer_file() and
do_read_prediction()... and the code doesn't seem to agree with the
documentation, it really looks like some kind of buffer size.[Samba
team: did this not used to be MIN(xxx,1024) ???]

3) SO_RCVBUF and SO_SNDBUF are the window sizes used by TCP: the
number of bytes to read/write before demanding an ACK from the other
end.

  All of these will need to be tuned independently, as we don't
know a priori which is going to address the problem.

  I suggest a set of trivial benchmarks, starting with a test
with ftp, to see if it's TCP or Samba proper, then 
setting all the options back to the defaults, then varying
one at a time and ploting a little graph for each, which should
look like
http://www.oreilly.com/catalog/samba/chapter/book/appb_02.html#appb-34738

  Feel free to seemed me raw data in email: I'm curious why you're
seeing this effect, and I'd like to see it running faster.

  And one last thing: after one run at debug level = 6 or more, set it
back to 1 or 0: the higher levels of logging slow the program
significantly!

--dave 
--
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb@canada.sun.com

Reasonably Related Threads

Search for more possibly parallel threads

samba - Dec 1999 - Samba writing speed with big blocks

Samba writing speed with big blocks

Samba writing speed with big blocks

Samba writing speed with big blocks

Samba writing speed with big blocks

Reasonably Related Threads