[linux-cifs-client] Re: cifs transferspeed breaks down during upload

[Martin Loewer]

James Roper wrote:
>>>When I upload a file it starts with a transferspeed at 3 Mbyte/s.
>>>Then it loses the transfer speed slowly during the upload. With a 1
>>>GByte file it end
>>>up at 800 kByte/s or even less than that which is really slow.
> 
> Well, initially the ftp server may accept data at 3mb/s, as it may buffer it 
> or something.  This would drop off quickly if the transfer to the smb server 
> was slower, but if your ftp client is measuring upload speed using the 
> average upload speed, it may take some time for it to appear to slow down.  I 
> wouldn't imagine that it would take too long to slow down though.

Well, I meassured the write performace to the disk at the smb server and 
it reaveals that the behavier to the disk is the same as what the ftp 
client told me.

But you are right at the point that the ftp client gives me avarage 
figures. The disk figures are even worse.
I can give an example:
500MByte:
Initial :    	2,5 MByte/s to the disk
after 30 s   	1,7 MByte/s to the disk
after 1 m	1,3 MByte/s to the disk
after 2 m 	1,0 MByte/s to the disk
after 3 m	0,8 MByte/s to the disk
after 4 m 	0,7 MByte/s to the disk
after 5 m 	0,65 MByte/s to the disk
after 7 m 	0,54 MByte/s to the disk
after 10 m	0,4  MByte/s to the disk
end: 		0,38 Mbyte/s to the disk

avarage from the ftp client: 661 kB/s

I also discovered that the ftp deamon is using 80% of the CPU, I don't 
know why. When transfering to smbfs mounted share it uses 10 % .
( When I do the same with netcat instead of the ftp deamon it uses also 
80 % of the CPU. I don't think that it is the fault of the ftp deamon.)


> 
>>>With a smbfs mount the  transfer speed is constant at 4 Mbyte/s .
> 
> smbfs may use a larger write size than cifs, or maybe they're even using 
> asynchronous message passing.  Currently, cifs can only write 16KB at a time, 
> and it does this synchronously.  That means, if your network has a round trip 
> time of 20ms, regardless of the bandwidth of the network (even if it was a 
> gigabit network), the maximum possible speed you could get out of the cifs 
> client is 16kb every 20ms, that is, 800kb/s.  This is going to change though.  
> I've implemented an asynchronous read routine, and assuming no one else does 
> it, i'll probably do a write one too.  Having implemented this, and some 
> other optimisations, hopefully we'll be able to get 80-90% bandwidth 
> utilisation, and the round trip time shouldn't have an effect.

Ok, I understand the round trip time problem. For test purposes I have 
copied 512 M to the cifs mounted share (dd if=/dev/zero of=testfilebs=1m 
M count=512) it gives me a data rate at 5 MByte/s .

> Other than that, I have no idea what could be causing the problem.
> 
> If you'd like to try out the asynchronous read routine, let me know and I'll 
> email you a patch.  I've tested it with 2.6.8, but it's still in it's early 
> stages, so if you're in a mission critical environment, i strongly recommend 
> you don't use it.

Thanks for the offer, but I don't have a focus on download as I have for 
  upload. And I tested the behavier for download: no problem .
I can download a file at 5 MByte/s without any problem .

Regards Martin