Poor performance in smbclient while transmitting

Ok, a couple of questions first.

1. What type of network card?
2. How are you doing the tests?
3. How is the sever configured?

Thanks
chuck

1. Server: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Laptop: Intel Corporation 82573L Gigabit Ethernet Controller

2. Copying both small (~1-2 MB) and large (4,7 GB) files to/from the server with nautilus. I get the speed from nautilus (laptop) and cacti (server)
Both server and laptop are idle.

3. testparm on server:

[global]
 workgroup = MSHOME
 server string =
 obey pam restrictions = Yes
 passdb backend = tdbsam
 passwd program = /usr/bin/passwd %u
 passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *passwd:*password\supdated\ssuccessfully* .
 syslog = 0
 log file = /var/log/samba/log.%m
 max log size = 1000
 domain master = Yes
 dns proxy = No
 panic action = /usr/share/samba/panic-action %d
 invalid users = root
 create mask = 0700

[Share]
 path = /home/Share
 valid users = [username]
 read only = No

The samba shares is mounted with cifs and the driver used on the laptop is e1000.

I just tested with an another computer instead of the server.
This computer is running Vista and the result almost is the same.

laptop -> vista computer <3,7 MB/s
laptop <- vista computer <~6,7 MB/s

Have you tried testing other types of connection.

Can you try installing pscp on your windows machine and try do more testing?

Thanks
chuck

Hi,

I'm curious... Would it be possible for you to try and scp a file
from your Linux Server to your Vista client? You can use something
like Putty's pscp from:
http://the.earth.li/~sgtatham/putty/latest/x86/pscp.exe
See what sort of throughput you get on a secure copy.

Also, check that your Linux server is connected at Fast Ethernet
(100Mbps) using ethtool:
ethtool eth0

Finally, see what your hard disk throughput is using hdparm:
hdparm -t /dev/sda

:-Dustin

Laptop:
eth0: 100 Mb/s in full duplex
Disk throughput: 44,60 MB/s.

Server eth0: 100 Mb/s in full duplex
Disk throughput: 45,20 MB/s.

I'll try pscp tomorrow.

"Have you tried testing other types of connection."
Yes, I've tried copying a file from the server to the laptop over HTTP.
I have apache installed on the server and I tested downloading the Ubuntu iso from it and I got 10-13 MB/s

Pscp (Vista)
SSH (Ubuntu)

1x 700 MB file

Ubuntu -> Server: 1,9 MB/s
Vista -> Server: 5,2-5,4 MB/s

Ubuntu <- Server: 6,5-6,8 MB/s
Vista <- Server: Peak speed is ~ 5 MB/s. The speed is decreasing until the recieving is finished. Stops at 1,1 MB/s

30x ~3 MB files

Ubuntu -> Server: The transmit never starts actually.. It stands on 0 byte until you force it to quit.
Vista -> Server: 3,9-4,1 MB/s

Ubuntu <- Server: 7-8 MB/s
Vista <- Server: 2,3 MB/s

nire wrote:
> Vista <- Server: Peak speed is ~ 5 MB/s. The speed is decreasing until the recieving is finished. Stops at 1,1 MB/s

Okay, for one thing, you should wrap the copy with "time" on Linux, or
something equivalent on Windows. Relying on the program's running
tally of throughput isn't a good idea when benchmarking. Take your
700MB file, and divide that by the total time to transfer (70 seconds,
say), and get your 10MB/s rate. Repeat that a few times, and average
it together, looking for any extreme outliers.

So copying over SSH, you're getting...
> Ubuntu -> Server: 1,9 MB/s
> Vista -> Server: 5,2-5,4 MB/s

And copying over Samba, you're getting:
Client (Ubuntu 8.04) -> Server Never above 3,7 MB/s
Client (Vista) -> Server ~12 MB/s

So the interesting thing to me here is that this doesn't really seem
like a Samba issue here. By these numbers, I think you're saying that
it takes 2-3 times as long to send the same large file from the same
laptop running Hardy vs Vista, to the same server running Ubuntu? And
you've run this repeatedly, with the same file, same hardware, just
different OS (Hardy vs Vista)?

If that's true, I think we're dealing with something more fundamental
to the networking stack and probably your ethernet driver.

> Ubuntu -> Server: The transmit never starts actually.. It stands on 0 byte until you force it to quit.

What happened here?

> Ubuntu <- Server: 7-8 MB/s
> Vista <- Server: 2,3 MB/s

This result is puzzling, and not consistent with the rest of your
stats. In this one case, the network transfer to Ubuntu outperforms
Vista by 2-3 times. Hmm.

In any of these cases you might have caching issues, where you send a
file from one machine to another, delete it, then try to send again
and it's been cached in memory somewhere, either on the client or
server.

So from these results, I'd tend to conclude that this isn't a
Samba-specific issue, that it's something more networking related. To
debug that, you're going to need some more scientific network
benchmarking tools. I recommend installing the dbench package
(written by one of the samba authors, cooincidently), and using the
tbench utility. You'll need it on both the client and the server.
You'll run "tbench_srv" on the server. And then you'll run something
like "tbench -t 60 SERVER_IP" on the client.

See:
http://samba.org/ftp/tridge/dbench/README

:-Dustin

Also can you make sure you have the latest window updates?

Thanks
chuck

I have the latest updates on all systems.

The tbench test gives the following results:

Server running tbench_srv
Client running tbench X [server ip]

Throughput 3.92733 MB/sec 1 procs
Throughput 6.34039 MB/sec 2 procs
Throughput 7.9146 MB/sec 3 procs
Throughput 9.05223 MB/sec 4 procs
Throughput 9.90074 MB/sec 5 procs
Throughput 10.5856 MB/sec 6 procs
Throughput 11.1638 MB/sec 7 procs
Throughput 11.6075 MB/sec 8 procs

Server running tbench X [client ip]
Client running tbench_srv

Throughput 3.93161 MB/sec 1 procs
Throughput 6.28949 MB/sec 2 procs
Throughput 7.82666 MB/sec 3 procs
Throughput 8.93178 MB/sec 4 procs
Throughput 9.7954 MB/sec 5 procs
Throughput 10.421 MB/sec 6 procs
Throughput 11.1116 MB/sec 7 procs
Throughput 11.4404 MB/sec 8 procs

Is the low throughput normal?

You might want to have a look at this:

http://forums.whirlpool.net.au/forum-replies-archive.cfm/691048.html

It doesn't explain the poor performance between two Ubuntu computers. Vista is the quicker in my results.
Those posts in your link are a year old and the problem is probably solved because I don't feel that i've experienced it.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

local network running 2 ubuntu intrepids both updated.
tbench_srv (192.168.1.101) running on VIA Rhine II , link up with 100Mbps, full duplex.
tbench client running on Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCI Express) 10/100/1000Base-T

tbench 10 192.168.1.101
Throughput 12.6571 MB/sec 10 procs

dmesg tells me:
[ 146.168934] tg3: eth0: Link is up at 100 Mbps, full duplex.
[ 146.168940] tg3: eth0: Flow control is off for TX and off for RX.

It seems that something is off performance wise.
They are linked via a Dlink DI-524UP

Sorry, btw,
real world performance (ie copying files over the network using smb) is about half that ~5.3MB/s.

I uncommented the performance related options in smb.conf

        SO_RCVBUF=8192 SO_SNDBUF=8192
   socket options = TCP_NODELAY

and that brings realworld file transfers up to just over 6 MB/s

This is still an issue and I'm fairly certain that its in samba on the client side. Setup is as follows:

Server:

OpenSolaris 2009.06, using native CIFS of a ZFS filesystem. Intel e1000g network card

Client:

1) Windows 2003 server 3Com 10/100 NIC, mounting above FS gives a solid 11MB/sec copying a single large file. Therefore saturating the network link.

2) Ubuntu 9.04, same hardware as client (1), mounting the above FS gives at most 6MB/sec copying a single large file. Transfering the same file over SFTP gives a solid 11MB/sec.

From this testing the following can be ruled out of the stack:

1) The server, we get different performance to the same server
2) The network layer, we've been able to achieve full wire speed
3) The protocol itself, the windows client shows that CIFS is capable of high speed transfer
4) The client hardware and driver configuration, otherwise SFTP would also be slow

It is therefore possible to conclude that the problem must be with SAMBAs implementation of a CIFS client.

This is a stable setup, so if peple are interested in helping me debug I will be able to provide any required data.

iinomine:
I think there are several separate issues here. Niclas original issue is a RTL81xx/Samba specific issue, duplicate of bug 46081, also mentionned here:
https://bugzilla.samba.org/show_bug.cgi?id=4889

Your issue is about bad performance of Samba in general compared to a Windows client. If you want to track that, please open a new bug and post your interesting benchmarking results there, so that we can rule out the hardy/RTL81xx/CIFS usual suspects and make sure the discussion isn't polluted by those. Btw, do you get bad performance using smbclient ? using kernel-based CIFS mounts ? Any regression from when SMBFS was used instead of CIFS ?

Niclas L, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.