Okay, it sounds like we may have to clarify something. When you use the terms 'upload' and 'download', it would be better to express this in terms of 'client' vs 'server'. The samba server and client components are distinctly different parts. When you are getting slow performance, what host (windows vs linux) is the server, and which is the client? It is possible that the bottleneck is on a windows host. There are four possible scenarios:

1. Linux read of smb mounted file from Windows host.
2. Linux write smb mounted file to Windows host.
3. Windows host writes to linux samba server.
4. Windwos host reads from linux samba server.

Which of these works adequately and which one(s) do not?
Have you verified that the same slow performance exists if the linux host is replaced with a windows host serving the same purpose (different hardware, too, would be best)? Just trying to establish whether there is a linux component to this, and/or whether there is a hardware issue.

--- rod.

OK, sorry for being unclear. With Windows host you mean a Windows box acting as server (you can get files from the local hard drive on that Windows box)? Well there is none. The only server is that box.

I don't see any big difference if I'm using either a Linux or a Windows client for accessing that server. So scenario 3 and 4 are the case, with the nuance that instead Windows sometimes also Linux boxes are clients (so far there has never been more than one machine connected to the server at the same time).

I will also try to set up another Samba server an a more powerfull machine, but only this weekend.

So I have

Linux/Windows client -> Samba server (slow but usable, about 2.5 - 3 MB/sec)
Linux/Windows client <- Samba server (really painfully slow)

As said, no big performance difference if I use either Linux or Windows XP as a client, they are both equally slow (which is the reason I suspect the server). Also, there are different Samba clients: one that ships with Ubuntu Edgy the other that comes with Mandriva 2007. Same performance with both ...

Good. Now, since the server is set up with a full-fledged distro, it should be simple enough to enable other services on it, such as ssh, if it isn't already enabled by default. I would like you to try doing scp &/or sftp from the the server to another linux host in both of two scenarios:

1. logged into the server, scp/sftp someBigFile someOtherHost
2. logged into the other linux host, scp/sftp theSlowServer:/someBigFile .

This should tell something about whether the transfer speed is being limited by generic network level problems, or is specific to your Samba server. It may be relatively simple to set up the same sort of test using other services on your slow server, such as HTTP, ftp, NFS, etc. Also, I suggest setting up a test using a network transfer diagnostic tool such as iperf.

--- rod.

Have you tried replacing the Ethernet cable between the slow server and the switch?
Or even just flipping the cable over?

Yes, like I suggested in my first reply to this thread. Thanks for reinforcing that, snuffy115. In ethernet networking problems, the hardware has a higher probability of failure than for many other faults.

--- rod.

Let's try the SSH thing. Here sftp gives speeds server->client of about 1MB/sec. The cables seem OK by the way I just unplugged two cables on the machine side (other end stayed in switch) and it didn't change anything. The server still is slow for server->client transfers while the Windows labtop reaches 10MB/sec in both directions to a test "samba server" on my Mandriva box with the cable that was previously on the Ubuntu box.

OK, seems there is something wrong with the network after all, has somebody any clue what the numbers in TcpExt mean?

OK, I found the problem finally. It was the network card. Or something that has to do with it. At least replacing it improved the overall network performance and the server now reaches about 4MB/sec in both directions, which is a big improvement.

Big thanks to all who helped.

Did anybody find a fix for the high CPU usage of /index_cpu.cgi? I have this running at 78% on a ClarkConnect server. File serving is really suffering, and media streaming is unwatchable.

4516 root 78.0 % /usr/libexec/webmin/proc/index_cpu.cgi

Any ideas what causes this / how to address?

BTW -- I have used other distributions (Puppy Linux, NASLite) and file serving is fine. So, I think that this is not a hardware issue, so must be a config, driver or software issue of ClarkConnect