WinXP -> OpenVMS tests reproduced using C++ test progra m

[COLLOT Jean-Yves]

Hi.

After some research, I have answers about that issue.

Actually, when analysing the network dialogues between the Samba/VMS server
and the clients, there are two differences:

1. The block size (1024 bytes when XP client, 61 Kbytes when Linux client)
2. The 1-byte writes and QFILE_INFOs requests, (only some with Linux client,
very numerous with XP client).

I tried to see what happens when using an XP client with a Linux Samba
server. The block size was 1024 bytes too, but there was only a couple of
1-byte writes.

So, it seemed that the block size was client-dependent, and the numerous
1-byte writes was server-dependent.

In order to check that, I made some changes in Ben's C++ bench program.
First, I changed the code in order to use binary stream files (using "
fout.open(dataFile,ios::binary);". With only that change, the block size
went up to 4096 Kb.
Then, I made additional changes, in order to force a 60 Kbytes buffer for
the stream file (using setvbuf()). As I expected, the block size was now 60
Kbytes.

My conclusion is that the block size is only due to the client. In the
original bench code, the stream file buffer is left to the system default.
It looks like the system default is 61 Kb on Linux, and either 1Kb or 4Kb on
XP, depending upon the text/binary characteristic of the stream.
This point is by far the main reason of the poor performances. The bench
elapsed time goes from 45 seconds down to 6 seconds by adding the 60 Kbytes
buffer. 
Unfortunately, I don't know if it is possible to change the XP default
buffer size at system level. I made some research, but I could not find
anything. 

Now let's see the 1-byte writes and QFILE_INFOs requests.

It looks like those actions are done by the client in order to provoke
extensions of the allocated file space, before actually writing into it.
Unfortunately, on VMS, the real size of the file is not visible until the
file is closed. That can be seen by typing "DIR/SIZE=ALL" while the file is
being written. It gives "0/nnnn". So, when the client asks for an extension
(Write 1 byte) then checks the new file size (QFILE_INFO), it always gets 0
for answer. That is quite perturbing for him, so it goes on trying to extend
the file.

I made a small change on the VMS server side: when the write request is only
1 byte long, I close and reopen the file. This updates the "external" view
of the file size. With that change, the numerous 1-byte writes and
QFILE_INFOs disappear, and the dialog is exactly the same with XP client
that it is with the Linux client. The time is the same too: 3.5 seconds.

I'll make some additional testing to check that this Close/Reopen does not
have side effects, and if it does not, I'll include that change in the next
release.

Jean-Yves