Packet analysis: WinXP vs. Linux<->VMS shows dramatic differences

[BG - Ben Armstrong]

Hi,

I'm trying to figure out why the bench.rb test program I included in my
previous note takes several times longer to run using a WinXP client
than a Linux client, both talking to our OpenVMS samba server.  The big
picture question is, "How do we tune our clients and/or server to
improve overall performance?"

I have captured packets between a WinXP client & the OpenVMS Samba
server and also between a Linux client & the OpenVMS Samba server while
running bench.rb.

The quick summary of my analysis of the capture files is that vastly
more packets (and different kinds) are exchanged between WinXP and
OpenVMS than between Linux and OpenVMS.  This accounts for the huge
difference in performance we are seeing.

Given this analysis, can anyone see what's going wrong with the WinXP ->
OpenVMS Samba conversations, and more importantly, can it be fixed?

Details follow.  Hardhats required.

WinXP->OpenVMS
--------------
For WinXP writing to OpenVMS, after the initial handshaking, the
conversation consists largely of SMBwrite requests & replies for the
first 140 packets, each of which contains 1024 bytes of blanks (ASCII
0x20).  There are a couple of netbios-ssn ACKs in there sent from the
server back to the client, one at 18615 bytes (window = 61440), the next
at 53047.

After this point, the conversation changes.  The last SMBwrite for 1024
bytes, offset 64512 is followed by a SMBwrite for 1 byte (containing a
null) at offset 66559 (which is beyond 64512+1024, contrary to my
expectations).

This is followed by a SMBTrans2 QUERY_FILE_INFO "Query File Standard
Info (258)" against the FID we are writing to.  The response from the
server returns without errors, but doesn't seem to contain much.
According to ethereal, the SMB data returned by the server is:

Allocation Size: 0
End Of File: 0
Link Count: 1
Delete Pending: Normal, no pending delete (0)
Is Directory: This is NOT a directory (0)
Unknown Data: 0000

Every write that follows is now broken into two writes, one containing
the 1024 bytes of blanks, (resuming at offset 65536, where I'd expect
the next byte to be written,) and one containing a single null, (the
next one at 67583, again beyond the end of data,) and after that,
another QUERY_FILE_INFO (each immediately followed by a response from
the server).

The conversation continues like that:
- write + response (1024 bytes)
- write + response (1 byte)
- file info + response

The only other packets, appearing at irregular but infrequent intervals,
are netbios-ssn ACK packets (the next at 75305, 95926, 101991, 106927,
etc.) going from the server back to the client.

In the end, 29890 packets are sent by the client, and 30648 are
received.  The whole ordeal takes 4 minutes 3 seconds elapsed time, for
a staggeringly slow send throughput of 49851 Bps (on a 100 Mbps
network!)

Linux -> OpenVMS
----------------
By contrast, the Linux to OpenVMS conversation is much more
straightforward.  A total of 7535 packets are sent and 5116 packets are
received, taking 27 seconds elapsed time, for a send throughput of
387309 Bps, an order of magnitude better than WinXP.

After the initial handshaking, the Linux client sends SMBWriteX (note,
*not* SMBWrite) requests to VMS, each one for 4096 bytes, which don't
all fit, given an MTU of 1500, so they are broken into 1392 for the
first packet, which contains the extra header stuff, 1460 for the next
continuation packet, and finally 1244 in the final continuation packet,
for a total of 4096.  Each SMBWriteX of 4096 bytes is followed by a
netbios-ssn ACK (to ack the 4096 byte reassembly, I guess,) and a
SMBWriteX response ACK back from the server.

The conversation continues this way until the end of file.

The big question is, given the above analysis, can anyone see what's
going wrong with the WinXP -> OpenVMS Samba conversations, and more
importantly, can it be fixed?

Thanks,
Ben
p.s. I will supplement this test with a WinXP client -> Linux Samba
server test to see which of the two conversations it more closely
resembles, and will email the results of that test under separate cover.
p.p.s. The raw libpcap capture files are available upon request if
anyone wants to do a deeper analysis of my data.