Thank you for the suggestion. I'll keep the info for reference.
Followup for the performance issue:
The trace shows that the conversation changes right after the trans2:
query file info internal stage, so I looked into the samba code at this
file:
http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0/source/smbd/trans2.c?rev=8959view=markup
case SMB_FILE_INTERNAL_INFORMATION:
/* This should be an index number - looks like
dev/ino to me :-)
I think this causes us to fail the IFSKIT
BasicFileInformationTest. -tpot */
DEBUG(10,(call_trans2qfilepathinfo:
SMB_FILE_INTERNAL_INFORMATION\n));
SIVAL(pdata,0,sbuf.st_dev);
SIVAL(pdata,4,sbuf.st_ino);
data_size = 8;
break;
The comment speaks for itself. I suspect the 8 byte here contains some
magic that makes XP behaves as I found.
I made an other experiment: I turned off the oplock support (Oplocks =
No) and this made XP behave like if it was talking to a Windows server.
No extra tran2 calls and 1 byte writes. The performance got better
because the slowdowns disappeared, but it was still slower compared to
the windows machine.
Then I looked into the traces again and found that XP sends 1260 bytes
in each packets when talking to the windows server and 536 bytes when
talking to the samba server. The MTU is 1300. I suspect, this issue may
be related to the different subnets where the two machines are located.
Hope this helps someone out there,
David.
Jonathan Johnson wrote:
I can't say that this will apply in your situation, but I've seen
where having stale connections to non-existent servers can cause a
performance issue when browsing. Here's a couple of things to try:
1) Remove any shortcuts to non-existent network locations -- this
applies to broken mapped drives, shortcuts on the desktop and in My
Documents, and shortcuts in My Network Places
2) Look in the registry at
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
(or ...\MountPoints) -- Under this key, there will be several subkeys.
Some of these are in the form of ##Server##Share -- if there are any
of these that refer to nonexistent servers or shares, remove them. DO
NOT remove any of the other keys, else your system might not boot
properly. This key is seems to be the Windows version of the
/etc/fstab file.
Nevertheless, I'm glad to see that you found something interesting.
Hopefully, your research will help the developers solve some other
nagging problems!
--Jonathan Johnson
David Beck wrote:
Hello There,
After having googled the whole internet for days I decided to go
public with this issue.
The result of my google queries so far is that there are plenty of
others with the very same problem I have and noone posted a
reasonable answer to this:
Using Samba 3 with XP gets bad performance. I tested this on Tru64
5.1b and FreeBSD 5.3 with the very same symptoms.
The throughput bw XP and Samba goes up and down. It starts
transfering with a reasonable speed and after having transfered
around 16 megs it slows down.
I tried many configuration options regarding locking, tcp settings,
xmit size and every combination that could make any sense for me.
Then I gave up with this configuration mess as I could lower the
performnce easily, but the performance jittering was the same.
Now a few notes before I continue: I tested the FreeBSD server on the
loopback interface and the file write speed was around 43 Megs that
is close to the disks maximum. I also tested the XP machine with a
Windows server and the write performnce was around 10 Megs on a
100Mbit link. In addition to that the FreeBSD machine is at my home
and the Tru64 and the Windows server are where I work. I'm pretty
sure that this is not a network issue.
After spending a lot of time with investigation I decided to go
deeper in this issue. I installed ethereal to capture the traffic and
compare the results bw XP-Windows and XP-Tru64. The test was to copy
50Meg file to both servers and capture the packets. To my surprise
the conversation was quite different.
XP-Windows (excerpt):
- nt create and x
- trans2: query file info internal
- set file info
- tcp data stream...
XP-Samba (excerpt):
- nt create and x
- trans2: query file info internal
- (query file info + write and x request) many times, incresing
offset, one byte length
- tcp data stream
In case of XP-Samba, the last two steps are repeated many times.
Large part of the effective bandwith is filled with query file info
and 1 byte writes.
The packet data can be downloaded from these links:
http://dbeck.beckground.hu/download/xp-samba.bz2
http://dbeck.beckground.hu/download/xp-win.bz2
I also made a screenshot of a bandwith monitor to show what I mean by
performance
