WinXP<->Linux samba server test results

BG - Ben Armstrong BArmstrong at dymaxion.ca
Tue Sep 21 12:34:00 GMT 2004


On Mon, 2004-09-20 at 18:32 -0400, John E. Malmberg wrote:
> What version of SAMBA is running on the LINUX system?

Samba 3.0.7 + smbfs 3.0.7.

> Other than that, I am not set up to take advantage of your data at the 
> moment.  I do not have any way of reading the etherreal data.

If it is because you don't have a Linux system, the ethereal data is not
specific to ethereal or Linux.  A number of utilities can read it, some
of which run on OpenVMS, and many of which run on Windows.

Tcpdump, which is available for TCPIP 5.4, can read it.  For example:

$ tcpdump=="$sys$system:tcpip$tcpdump"
$ tcpdump -vr test.cap

Also, tcptrace, which, like tcpdump, is based on libpcap, can read it.
See:

http://jarok.cs.ohiou.edu/software/tcptrace/download.html

e.g.

$ tcptrace == "$path_to:tcptrace"
$ tcptrace -v test.cap

Finally, if you run Windows, Ethereal works on Windows as well as Linux.

> It may be useful if you can find a specific difference in the protocol 
> negotiation if the SAMBA versions are the same.

Making the Samba versions the same would be a rather costly project for
me at this time.  I'd like to explore other avenues before trying that.

I find it rather interesting that Linux can negotiate Write AndX to
write large buffers at a time to OpenVMS, and Windows can negotiate
Write AndX to write large buffers at a time to Linux, but Windows can
only negotiate Write to write 1K blocks at a time to OpenVMS.  So
clearly OpenVMS Samba *is* capable of doing Write AndX, since it happily
receives them from the Linux client, which writes 4096 byte buffers at a
time.  Doesn't this indicate that the Samba server, either due to tuning
or some other factor, has missed an opportunity to take advantage of a
more efficient method of transfer, rather than simply an incompatibility
between versions?

Also, if pre-allocation is an expensive operation in OpenVMS, doesn't
that indicate there is room for improvement here in the current Samba
implementation for OpenVMS?  Since the Windows host insists on
preallocating, and since OpenVMS Samba refuses (or is unable) to send
back EOF and allocation responses to the file info requests, it appears
that Windows thinks it can only pre-allocate a small amount ahead of
where it is writing, instead of further ahead, as it does in the Windows
-> Linux case.  Wouldn't sending back EOF and allocation figures allow
the Windows client to write further ahead, resulting in fewer
preallocation requests?  As it stands, after the first 64K are written,
one file info + one extra preallocation write are done per 1024 byte
block written!  That is exorbitantly expensive, and totally unnecessary,
if only the server would give the client the info necessary to make
larger, and therefore fewer preallocation writes.

Ben



More information about the samba-vms mailing list