perf issues with 3.6.0...(SMB2) (relnotes?)

[Linda Walsh]

I'm working with Win7-64 and samba, so that's where these comments apply.
01234567890123456789012345678901234567890123456789012345678901234567890123456789
the news is mixed....first is that it's probably at least as fast as SMB. 
In some areas, it is faster. Certainly in network traffic it is 'better',
in so much as when I watch in wireshark, there are fewer separate packets
going back and forth.  I'd say that write performance throughput may be
slightly higher, but that's only in a 'feel' from the win7 side,
(I.e. can't be physically faster, since I know I measured top speed under
SMB, at 125MB/s  (on a Gb network, you can't get faster than that).
Reads under smb topped out around 119-121MB/s).

Well, windows 'writes' are 'going faster', BUT, the final acknowledgment
that things went ok, **seems** to take longer (this is subjective --
haven't done  extensive measurements)...  but what I see, (from progress
indicator in Adobe Photoshop writing out ~800MB files (i.e. when I save
my work), the 'write' indicator (green bar) goes by much more quickly, BUT,
then Adobe waits on the 'close'...it's the 'close' that takes MUCH longer.

I can't see why windows would have changed it's local buffering due to
protocol change, but it's possible -- but watching a network monitor
(xosview running on server), I see the network and disk write speeds going
about the same speeds as under SMB).  It's the final cleanup stages that
seem to be taking longer.   What I notice when a file is written, is
that the filename is 'created' as a zero length file.  Then a tmp-file
is written in the same dir with the data, and that's finally renamed
to the real file.

(Note: during some self-inflicted auth-probs trying to
fix another prob, the 'rename' would fail.  I.e. it would create the
0-len file, write the tmp, THEN, the rename would fail with 'file-exists'
failure (fortunately with 'vfs_recycle' turned on, I'd find the
~pfXXXXX files in the appropriate recycle dir, and renamed, they'd be
the 'saved' file!  I wouldn't recommend that as  normal way to save files!)
Once the 'auth' problems were corrected (my passwd db was corrupt by
my attempting to solve the enum users '*' issue not working) by restoring
from that morning's backup, that prob went away)).

But in addition to the long lag on 'close times', I see an extra 2-3
second delay upon opening any network share directory (SMB wait was,
"effectively", none).

But the main problem I notice -- if am playing AUDIO on windows from
an SMB file, I now get MANY long dropouts (even under SMB had my song
player's buffer set to ~350ms).  Now, even 3000ms isn't enough!  I've
also reduced the number of 'send-buffers' on my network card's tcp offload
buffers by 75% (2048->512)...though the rcv buffers are still @ 2048.

I originally had them set high to get the high throughput with SMB
(I also use a 9014 size MTU on my net)...

I have yet to engage in more tuning, but I wanted to document this as
a 'cautionary' note -- for those upgrading to using SMB2, in that a
network stack tuned for perf under SMB, might required alot of rework to
retune for SMB2...(and still haven't gotten to the ideal mix, AND I know
(told by Volker(?)) that SMB2 is being artificially limited in it's
max packet size to 64K rather than the default 1M allowed under Win7,
so the problem could be worse when fuller packet sizes are enabled.

Now I understand some of the advice I saw on the Win7 forums about turning
off TCP-large send/receve offload, on network cards and such...basically
it seems otherwise, Win7 will saturate an SMB2 connection and disallow
smaller reads needed for 'audio' to work ...

I currently do *NOT* have QOS enabled on my network stack (under SMB
it never created any noticeable benefit)....   I might try that next
as well as continuing to lower the amount of allowed buffer offloading
on the card -- hopefully it won't impact my overall throughput -- which
may be higher on win7 due to the SMB2 protocol.   But it' is requiring
a whole new approach to network stack tuning...