socket options

[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.

-- 
Peace and Blessings,
-Scott.