socket options

[Scott Lovenberg]

On 2/28/2013 4:37 PM, Andrew Bartlett wrote:
> On Thu, 2013-02-28 at 09:37 -0500, Scott Lovenberg wrote:
>> 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.
> I would rather not.  Useless options that are ignored are pretty safe,
> and if they are useful on another OS, then as defaults they should be
> fine.  We don't need to call it out specifically if they don't do harm.
> Instead, we want to just warn off making any changes here in general.
>
> Andrew Bartlett
>
That makes sense.  I'll write it up and submit the patch as worded before.