socket options

[Günter Kukkukk]

Am Donnerstag, 28. Februar 2013, 15:37:20 schrieb Scott Lovenberg:
> On Wed, Feb 20, 2013 at 4:47 PM, Scott Lovenberg
> 
> <scott.lovenberg at gmail.com> wrote:
> > On Wed, Feb 20, 2013 at 4:27 PM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> On Wed, 2013-02-20 at 16:15 -0500, Scott Lovenberg wrote:
> >>> On Sun, Feb 17, 2013 at 4:11 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> >>> > Would you like to write a patch to at least improve the warnings in
> >>> > 'man smb.conf'?  Probably not ascii-art, but some clear text
> >>> > explaining why this should be the last, not first resort,
> >>> > particularly on Linux.
> >>> > 
> >>> > Thanks,
> >>> > 
> >>> > Andrew Bartlett
> >>> 
> >>> How about this wording?  If everyone is ok with it, I'll format it for
> >>> a man page and submit it as a patch (since the mailing list hates
> >>> non-plain text).
> >>> 
> >>> "
> >>> Warning:
> >>> "Premature optimization is the root of all evil." -- Donald Knuth
> >>> 
> >>> Changing socket options should be attempted only after consulting the
> >>> Samba Performance Tuning chapter of _The Official Samba HOWTO and
> >>> Reference Guide_
> >>> (http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/speed.html)
> >>> and exhausting all other means of improving performance.
> >> 
> >> The problem with linking to that document is that it is more a source of
> >> confusion and outdated information than a solution to it.
> >> 
> >> I'm actually in a mood to totally remove it, or if not to gut it,
> >> because I have no indication (in the commit logs) that it has had any
> >> significant attention to technical detail in 10 (probably more like 15)
> >> years.  (Notice it compares with NT, and mentions NetBEUI as a common
> >> network protocol...).
> > 
> > I just actually read through the entire section.  It is very dated.
> > I'm not sure it is relevant any more and I'd understand if you removed
> > it entirely.
> > 
> >>> Modern server operating systems are tuned for high network performance
> >>> in the majority of situations; when you set socket options you are
> >>> overriding those settings.  Linux in particular has an auto-tuning
> >>> mechanism for buffer sizes that will be disabled if you specify a
> >>> socket buffer size.  This can potentially cripple your TCP/IP stack.
> >>> 
> >>> Getting the socket options correct can make a big difference to your
> >>> performance, but getting them wrong can degrade it by just as much.
> >>> As with any other low level setting, if you must make changes to it,
> >>> make small changes and test the effect before making any large
> >>> changes.
> >>> "
> >>> 
> >>> Is this wording acceptable?  I could definitely drop the Knuth quote,
> >>> but I think it sets the tone perfectly for socket tuning.  Plus, I
> >>> like to quote Knuth.
> >> 
> >> Otherwise, I like it.  Perhaps we start with just the last two
> >> paragraphs (and the quote, if you can find the right docbook syntax).
> > 
> > That works for me.  I'll write it up.
> > 
> > --
> > Peace and Blessings,
> > -Scott.
> 
> Sorry for the delay (I got a cold 2 days after getting over a cold.
> Never attend a 2 year old's birthday party, there be germs.), I'd like
> to make one additional change to the text in regards to Linux.
> Apparently, as is currently being discussed on the linux-cifs mailing
> list, the TCP_NODELAY socket option is essentially useless on Linux
> now that the sockets are "plugged" (ie, like the deadline disk
> scheduler does for writes).  The cifs mount utility is doing away with
> the option all together, so I think it should be noted in the
> documentation that this is another socket option that should not be
> used with Linux.
> 
> If there is no objection, I will add that to my doc patch.

then we should also carefully examine the sources - i remember that
TCP_NODELAY is always used - whether set in smb.conf or not.

./source3/include/includes.h:
#define DEFAULT_SOCKET_OPTIONS "TCP_NODELAY"

./source3/param/loadparm.c:     
string_set(&Globals.socket_options, DEFAULT_SOCKET_OPTIONS);

I only had a very short look at this - so a deeper look is needed.

Cheers, Günter