[OpenAFS] Re: WAN speed

[Andrew Deason]

On Sat, 24 Mar 2012 02:59:19 +0200 (EET)
jukka.tuominen@finndesign.fi wrote:

> Thanks for the help, I got it working now
> 
> -chunksize 23 transfer speeds:
> 
> 20M/2000 files:
> 
> SSH to AFS ~150KB/s
> AFS to SSH ~285KB/s

To be clear, none of the suggestions given were intended to improve this
case. iirc, it is likely that this is just how fast AFS is going to go
with such little files and that level of latency (Jeffrey already
provided a more in-detail explanation). There is not much you can do
about that; filesystems don't usually perform very well with lots of
little files written in sequence.

> 109M single file:
> SSH to AFS ~533KB/s
> AFS to SSH ~840KB/s
> 
> 109M to AFS seems to actually hang in the end. In nautilus it shows as
> if ok, but when it reaches 100% the dialog doesn't go away (have to
> kill the process). It could be reading the file into RAM and writes it
> to disk afterwards, or something. This wasn't just with the changed
> chunksize.

When you write a file to AFS, you are actually writing to the cache on
the local client until you close the file (or run fsync()). So, what is
probably happening is that that graphical file progress dialog thing is
showing progress when we write() the contents, but that last part is
when nautilus is calling close(), which will take a while since we need
to write the data to the fileserver.

Nautilus may not a good program to be using to determine how fast file
transfers are going. Using either:

dd if=/path/to/src of=/path/to/dst

or

time cp /path/to/src /path/to/dst

on the command line is probably a better way to see this; they will
allow you to easily calculate the overall rate of the transfer after it
is finished.

> > If it still seems slow no matter what you try, what may be helpful is if
> > you can provide the output of:
> >
> > rxdebug <client> 7001 -rxstat -noconn
> > rxdebug <server> 7000 -rxstat -noconn
> >
> > So we could see the rate of resends and such for Rx. Provide that output
> > both immediately before and immediately after you try a transfer.
> 
> I hope this helps

The rate of resends from the client to the server seems a bit high,
along with the rate of dup packets on the server side. I'm not sure at
the moment if this is just then a result of the quality of the client
network... or maybe Rx just handles out-of-order packets or latency
spikes poorly.

-- 
Andrew Deason
adeason@sinenomine.net