[jcifs] Speed please..

[Paddy Cerri]

Dudes - thanks for the interesting replies. :-)

So it's something to do with these :-

'It's the internet crossed with the smb protocol that produces this slow 
transfer..' - hope not..
or
'Windows is bollox, and we can't make it any faster because of them' - 
probable
or
'Try wacking up the buffer sizes and see...' - think I tried it all

Can I client-side-internally/server-side increase something  - since I have 
played with most of the SmbConstants ?

What buffers Chuck ? Do you mean the send and recieve buffers ? I think 
65536 is the max on the server end, in smb.cnf, and the default in 
SmbConstants for the client is allready 60416 ?

I have looked at the SMBTransport line 325 peekKey() function for ages to 
see if there is any difference in the packets being recieved and there 
doesn't seem to be.

I imagine the latency of the message going from the client to the server and 
back, as you predict Chris,is the reason for the low transfer speeds. Makes 
sense anyway. As no real delay exists on a LAN and as far as the code is 
concerned, they are the same address.. That's the only bit that has changed.

Has anyone tried to download the file I put up ?

What download speed did you get on your bandwith ?

paddy

----- Original Message ----- 
From: "Caldarale, Charles R" <Chuck.Caldarale at unisys.com>
To: "Christopher R. Hertel" <crh at ubiqx.mn.org>; "Patrick Cerri" 
<robogiant at hotmail.com>
Cc: <jcifs at lists.samba.org>
Sent: Tuesday, October 03, 2006 6:08 PM
Subject: RE: [jcifs] Speed please..


> From: jcifs at lists.samba.org On Behalf Of Christopher R. Hertel
> Subject: Re: [jcifs] Speed please..
>
> The one that is probably impacting you is that CIFS is basically
> a request/response protocol.  The client sends a request, and the
> server processes the request and sends a response.  Because of this
> highly serial behavior, CIFS is very sensitive to network latency
> and jitter.

I believe this is what the READ/WRITE_RAW and READ/WRITE_MPX commands
were intended to address.  However, at least some of the MS
implementations of the raw functions are unusable, since they do not
disable request concurrency in a reliable fashion.  To make it worse, MS
decided to support the MPX versions only on connectionless transports,
which makes no sense to me.  For the moment, we mitigate the long
latency problem by using really big buffers in our native client and
server.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.