Re: [fuse-devel] Re: ftpfs recommendations

[Miklos S. <mi...@sz...>]

> > > Here's the raw data on the original test system:
> > > ftp/rcp: 9.0 MB/s
> > > sftp/scp: 6.8 MB/s
> > > 
> > > Other systems with better connections get:
> > > rcp: 13.4 MB/s
> > > scp: 9.7 MB/s
> > 
> > I don't understand.
> > 
> > If CPU is the bottleneck due to en/description, then scp numbers
> > shouldn't vary with bandwidth change.
> 
> Unfortunately, the systems on the two networks are like apples and
> oranges with respect to CPU.  I can't do a direct comparison, but
> the results still point to a delay due to encryption, since the
> encrypting the data stream on Kerberized rcp produces roughly the
> same results as scp.

I see, OK.

> > Yes.  It does some readahead, but not enough.  It's 64k (on 2.4
> > kernels it's less).  If RTT*bandwidth is bigger than this, then there
> > will be some loss of speed.  That is a 64ms max RTT for 10MB/s.  And
> > that includes the en/decription delays added by ssh as well as the
> > network delay.  So it's pretty easy to go over this limit.
> 
> Ahh, of course.  I am in fact using a 2.4 kernel, at least for now.
> Wouldn't it be 6.4 ms?

It's 4k by default on 2.4, so that's only about 4ms.

>  Anyway, I'm getting ~0.5 ms on my pings, so depending upon the 2.4
> cache size, that would do it.  Given that a majority of our accesses
> will be long, streaming reads, I might try to increase the cache
> size and/or use the large_read FUSE option.

Yes, in fact the large_read option might fix the problem in your case,
since the network delay is pretty small.

Miklos