Its certainly strange, the samba transfer rate is more the sort of level I was expecting. Top is supposedly showing nice time as well, and running a straight sar instead also gave the same results.
Disabling ipv6, UseDNS(*), compression on the SFTP windows client all made little or no difference. Interestingly changing to another sftp client on the wintel end, (the sftp from the putty suite instead of filezilla) appears to run quicker but with occasional large slowdowns with very high CPU usage on the client, (but not the server) ... transfer using this was 12mins, not great but better than before I think that you are correct and that this is a client issue not a problem with the linux server. Cheers Tim (*) although this isn't the problem here I think I may be encountering this elsewhere so cheers for that too :) On 3/13/07, John Andersen <[EMAIL PROTECTED]> wrote:
On Tuesday 13 March 2007, Tim Hempstead wrote: > John, > > Ok, I've tested again with both samba and SFTP. Samba is > significantly quicker than SFTP with the iso file copying in ~5-6 > minutes instead of the 35+ being shown by SFTP. But looking at top > whilst the processes are running the system is doing virtually nothing > during both transfers, (both smbd and sshd during the respective > transfers are peaking at <5% CPU usage, Hmmm, thats more improvement that even I would have expected. Is top showing you the Nice time too? Perhaps the processing has been niced out of the display? But to avoid getting side tracked, does that performance live up to your expectations when running under samba? Can we rule out problems with the hard drive array as well as the network? If so, it sounds like an encryption problem somewhere, and the windows side looks guilty to me. I've never had much luck compressing an ISO, is your sftp trying to use compression in addition to encryption? ----------------------- Interesting (and perhaps unrelated) side note regarding ssh: somewhere along the way (in the last month or so) ssh connections started treating the "UseDNS yes" parameter differently than in the past on one of my servers, either that or bind is horked. The symptom taking was 30 seconds to connect, and from there on running at normal speed. 30 seconds tipped me off to the fact that it was waiting for dns to time out. UseDNS causes it to reverse map the dns to see that it gets something that resolves back to the machine trying to connect. With out host entries on the dns server for local machines it was taking forever. Adding entries to hosts fixed it. Turning off UseDNS would have also been an option. -- _____________________________________ John Andersen
-- Tim Hempstead [EMAIL PROTECTED] -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
