Samba too slow in Win2K => HP-UX direction

[Mustafa Ozturk]

We have purchased a X2100 Win2K box recently. On Win2k, we mapped NFS drives through Samba 2.2.3a. We observed that files copied & pasted from Win2k to HP-UX 11.00 server transferred about 6 times slower than in the opposite direction. In our 100FD network, we measure speeds about 6-7 MByte/s from Win2k to HP-UX, and about 1 MByte/s from HP-UX to Win2k box. Using ftp, however, speeds go up to 10-11 MByte/s in both ways.
We are getting support from local HP site, but they weren't able to find a solution so far. My questions are :
1) Is this performance drop normal with Samba ? Is there anyone else out there who have experienced the same problem ?
2) We are assuming that the network hardware are OK, as ftp works fast both ways. May we be missing anything ?
3) Is there anyother solution than Samba?

[U.SivaKumar_2]

Hi,
IF you have any NFS server loaded in win2k and if you try NFS from HP-UX NFS client. This setup will faster than SAMBA. SMB protocol is
slower than NFS .
Also Do you have any routers in between the win2k machine and HP-UX ?.

regards,
U.SivaKumar

[sven verhaegen]

I wonder on this , it is true that ftp and NFS TCP or SAMBA operate at different speeds , FTP should be faster as it's protocol isn't this complex , but the difference should not excessive , first idea that comes to mind is a duplex issue with the 100MB lancard but FTP is ALSO TCP-IP orientated , can you confirm that the speed problem is only uni-directional , if so , please do check the duplex setting on the switch and the HP and PC , they should be identical , bad duplex settign can cause unidirectional speed problems , perhaps FTP recovers faster because it is not hindered by the bigger latency that SAMBA or NFS related products know

[Bill Hassell]

Actually, FTP is faster because it has a rather complicated protocol. FTP was designed to handle a wide variety of transmission speeds, from 1200 baud modems to Gigabit network cards. It does this by maximizing each packet size (regardless of the original record sizes) to match the link speeds and allowing multiple packets to be sent without an immediate reply. This overlapping send/acknowledge mechanism makes it much faster than NFS, Samba/CIFS or rcp. It is also more reliable in that packet acknowledgement is more robust.

[Donald Kok]

A year ago we had speed problems from ux->NT over CIFS. HP suggested the following:

- apply latetst (NFS and netcard) patches (they always says that)
at the time: PHNE_23249 + Dependencies
- use cifs-version 1.06 or above
- kernel parameters:
nfsTimeout 50
nfsRetransmit 5


It did help me at the time.
Goodluck

[Mustafa Ozturk]

Sorry for the late reply. For some reason I didn't get any notification e-mails for your replies.

Reply To : U.SivaKumar :
The server and the client are on the same switch. I didn't really get what you mean by your first sentence. Sorry I am not really godd at networking.

Reply to Sven Verhaegen :
The problem is uni-directional. The server, client and the switch is 100FD, AutoNeg=OFF

Reply to Donald Kok.
Our HP support people upgraded Samba, installed the latest patches. Stiil got the problem.

I have seen people with and without the problem in our our CAD software's mail list. None had a performance drop as significant as ours, though.

Can you help me collect some data about the problem ? Can you measure Windows Copy/Paste times in your system?
My figures for a ~25 MB file are :
From Win2k to UX : ~17-18 secs
From UX to Win2k : 3-4 secs !and for a 95 MB file
From Win2k to UX : ~55-58 secs
From UX to Win2k : 10-11 secs !

[sven verhaegen]

there are styll 2 things i can advise het , try disabling the source quench enging on the HP-UX 11.0 version , it has sometimes caused performance issues on heavily loaded system ,this feature is new on 11 system , didn't exist on 10.x , it isn't 100% needed (10.x could do fine without it) , it is a system tunable parameter which controls this , to deactivate it use ndd , ndd only work on the running system so to make it permanent you need to put it in /etc/rc.config.d/nddconf file
also

the line command to make it work at once is :

ndd -set /dev/ip ip_send_source_quenche 0

if this fails to solve the issue you're down to the worst of the possible solution "TRACING" , either use the nettl tool provided by HP-UX (if you need to know how we can explain it) or use a PC with lanmonitor (it is much nicer in it's presentation) and try to find out what direction packets are lost or slow or dropped or if you are you seeing execisive retransmission or other things like this....