[linux-cifs-client] Re: Asynchronous readahead limit

[James Roper]

A quick comparison with ftp and smbfs:

cifs with async routines:
real    0m6.983s
user    0m0.020s
sys     0m0.688s

ftp:
real    0m2.222s
user    0m0.051s
sys     0m0.672s
obviously we have a long way to go...

smbfs:
real    0m9.114s
user    0m0.004s
sys     0m0.311s
we're on the right track though

Well, seeing those figures made me decide to use a larger file... lets
see how we go now:
173MB file
cifs with synchronous routines:
real    1m11.889s
user    0m0.023s
sys     0m2.927s
cifs with asynchronous routines and 32 page max readahead
real    0m24.318s
user    0m0.023s
sys     0m3.394s
cifs with asynchronous routines and 128 page max readahead
real    0m23.911s
user    0m0.017s
sys     0m3.459s
smbfs
real    1m8.609s
user    0m0.019s
sys     0m2.348s
and here's the big surprise, FTP:
real    0m26.786s
user    0m0.469s
sys     0m5.636s

So, it seems again that Windows XP makes very good use of asynchronous
IO.  I'm actually quite surprised, this is the same file that I tested
out when copying from the Linux Samba server on the same laptop (the
only thats changed is the harddrive died and so has been replaced),
here's a copy of results back then:
Test *      Trial 1     Trial 2     Trial 3     Average
Async      19.711      19.723      18.977      19.470
Sync        21.809      21.105      21.033      21.315
Why would samba be able to handle synchronous IO, with respect to
asynchronous IO much better than Windows XP?  Maybe Windows XP has a
very slow network stack, making the round trip time very large without
adversly affecting the network throughput.  At any rate, these results
are excellent news.  I wouldn't be that overjoyed about being faster
than the FTP server, the FTP server was the simplest GPL windows one I
could find off the net (http://en.typsoft.com/index.php), probably isn't
very fast.  And of course, an FTP server sits in userland, while i'd
assume that the windows XP file server is in the kernel, thus you would
expect it to perform better.  But at least it shows that we are in the
right  ball park.

I might drop a line to the samba guys to find out why they think samba
performed so much better.

James


Steve French wrote:

>Although there are significant functional differences, ... it would be
>useful as sort of a sanity check to get baseline numbers from a couple
>of other copy methods to see if the cifs numbers are in the right
>ballpark.
>
>Can you do a quick comparison with ftp, scp and/or nfs from the same
>machines?  In addition, copy of the same file from the same server via
>smbclient.
>
>If one of those is significantly faster than cifs->Samba we may want to
>push even harder at getting cifs in the ballpark of those.  We may also
>need to push harder to optimize Samba server if we see indications that
>the bottleneck is the server.
>
>Also remember for large number of simultaneous requests to up max_mux
>(which is configured on the Linux client via an insmod parm - do modinfo
>on cifs.ko to see its name, and on the server is configured via
>smb.conf).  It is not clear what the optimal number of simultaneous
>requests to be queued on the server - but the more there are the fancier
>we can make the server algorithm be for dispatching reads/writes.  50 is
>the default.
>
>I am quite interested in the results of this work.
>  
>

-- 
James Roper
u3205097 at alumni.anu.edu.au
Phone: +61 2 9524 3380      Mobile: +61 438 406 331