<div>Thanks for the excellent response.  It does seem to be a nagle/buffering issue of some sort.  I set up stunnel as you suggested (so that all conns are localhost -> remotehost) and the problem disappeared.  However, after again explicitly turning TCP_NODELAY off completely in samba and stunnel, restarting, etc, the problem remains in the localhost -> localhost configuration.  </div>

<div> </div>
<div>It'd be nice to fix it, but none of the socket options seem to change anything so will probably have to find a work around, such as keeping the number of files in the directory low or pushing harder to use cifs instead of stunnel.</div>

<div> </div>
<div>Thanks again for your time.</div>
<div> </div>
<div>Paul<br> </div>
<div><span class="gmail_quote">On 4/3/08, <b class="gmail_sendername">Geoff Thorpe</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:geoff@geoffthorpe.net" target="_blank">geoff@geoffthorpe.net</a>> wrote:</span> 
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Wed, 2008-04-02 at 14:12 +1100, Paul Kerin wrote:<br>> I've got stunnel debug set to 7 on client and server.  No errors and<br>
> no logging at all except for the initial handshake when the mount is<br>> created.  Including the tcpdump would probably be excessive at this<br>> stage.  In summary, using stunnel the data gets transmitted in packets<br>
> usually containing around 200 bytes, whereas without stunnel it's<br>> mostly 1408 byte packets.<br>><br>> Any suggestions?<br><br>Given that you are also experiencing data-expansion overall (despite<br>
getting smaller individual packets), I'm guessing that you are losing<br>coalescing as data enters the SSL tunnel. I assume the majority of data<br>is in the server-->client direction if you're doing an "ls", so what is<br>
probably happening is this;<br><br>1. in the unencrypted case, small amounts of data are being emitted from<br>the samba server via socket writes, but it is coalescing within the TCP<br>stack due to Nagle (TCP_NODELAY).<br>
<br>2. in the encrypted case, samba server output is being emitted locally<br>into the SSL tunnel which produces delineated SSL records to be written<br>out on to the network. Even ignoring the expansion of SSL records<br>
relative to small unencrypted inputs, there may also be sufficient<br>additional processing overhead in stunnel that Nagle doesn't get a<br>chance to coalesce these 200byte SSL records into larger TCP packets.<br><br>
If my hunch is right, the individual writes from the samba server are<br>probably quite small (perhaps one per file in the directory listing<br>response) because even once they're encapsulated in SSL, the records are<br>
still only 200 bytes. Depending on the SSL/TLS cipher-suite you're<br>using, that could be a significant expansion relative to the unencrypted<br>data. Also, in the unencrypted case (no stunnel), I imagine that if you<br>
ran 10 copies of "openssl speed rsa1024" in a while(1) loop on the<br>server, you may find that you start getting smaller packets from the<br>server rather than the nice coalescing you're currently seeing. Ie. if<br>
you slow samba down a little, the Nagle algorithm may start to fail you<br>in the same way you're already seeing with stunnel.<br><br>Also, certain combinations of SSL/TLS version and cipher-suite produce a<br>lot of extra "chatter" over the wire. Consider playing with the versions<br>
and cipher-suites of your SSL tunnel to see if you can get a tunnel that<br>gets you a better data rate. Eg. the "default" cipher-suites for openssl<br>apps are often set to use ephemeral key-exchange cipher-suites because<br>
they have a theoretical security advantage ("perfect forward secrecy"),<br>but they're also typically a lot bulkier (though this would be most<br>observable in the initial handshake rather than in the data-plane). Also<br>
try SSLv3 rather than TLSv1, just for kicks...<br><br>What else? If the NAGLE issue is the key difference here, the localhost<br>connection between the stunnel server and the samba server is probably<br>too direct for samba's output to coalesce into larger packets the way it<br>
does when it goes unencrypted onto the network. You could possibly<br>confirm this by moving the stunnel server to a different machine (even<br>back on the same machine as the stunnel client, just for curiosity's<br>sake) so that the samba output is still going unencrypted through a real<br>
network link before it reaches the SSL tunnel. If this is the issue,<br>then you would observe that the SSL records within the encrypted tunnel<br>get larger, there should be fewer of them, and the expansion ratio of<br>data-size between unencrypted and encrypted network data should reduce<br>
significantly (because you're possibly encrypting ~1Kb per SSL record,<br>rather than encrypting 10-50 bytes per SSL record, as may be the case<br>currently).<br><br>Those are all the thoughts I have for now - let me know what you find<br>
and perhaps we can suggest something in consequence.<br><br>Cheers,<br>Geoff<br><br><br><br></blockquote></div><br>