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

John E. Malmberg wb8tyw at qsl.net
Wed Sep 22 13:10:01 GMT 2004


In article <CF0913E9C3D53D4E94DE47FDE25C633D05048E85 at hermes.cofiroute.com>,
COLLOT Jean-Yves <jean-yves.collot at cofiroute.fr> writes:
>
> Excuse me, but I don't agree. I just ran Ben's "ruby" bench, which is
> creating that 10000 Kb file, and I can see the very, very slow =
> behaviour: it takes more than 36 seconds to run the bench
>  (compared to 2.35 seconds = for running a simple COPY).

My error from reading too early in the morning here.  I missed the "Kb",
and used it as "bytes" even though I also typed "Kb"

The undesired behavior starts somewhere above 65535 bytes, not Kb.  And
it can be reproduced with a Windows NT 4.0 client on SAMBA 2.0.6.  I have
not tested it on anything earlier.

It appears that there are two issues that affect the performance, and my
guess is that the protocol negotiation is the main one.  Fixing that will
probably require porting a newer version of SAMBA.

There are other consequences to RMS, and for the "magic" translation of VFC
files to text files for this out-of-order translation that I want to look at
also, as one of my goals is get the "notepad" problem on VMS fixed, even
if it can not be fixed on UNIX.  On VMS we have an advantage as we can tell
if the file originally created on VMS is a text file, and what it's
organization is.

It is no problem setting up a SAMBA to serve any type of text file to a
PC client as a stream-CRLF or a stream-LF regardless of it's original
organization.  It is handling the modify in place where the problems
come in.

So I think for the big problem, an updated port is needed, and for the second
one, moving to a VFS loaded file system instead of wrappers for the file
system calls.  A VFS based system can bypass the CRTL completely to get
the best speed.  And by having one VFS for ODS-2 and one for ODS-5, it saves
overhead on trying to support Pathworks name mangling.

I also may be able to move the wild card matching into the VFS as an
enhancement.  I think it would speed up both the VMS and UNIX performance,
especially the VMS performance.  Especially with large directories.

I pulled down the SAMBA4 kits last night with my barely functional rsync
client.  It looks like the only way to build it on VMS will initially require
GNV and PERL.  I do not know if I will get to trying that before next week.

Regards,
-John
wb8tyw at qsl.net
Personal Opinion Only



More information about the samba-vms mailing list