[OpenAFS] WAN speed

chas williams - CONTRACTOR chas@cmf.nrl.navy.mil
Thu, 22 Mar 2012 10:18:44 -0400


On Thu, 22 Mar 2012 08:42:16 +0100
Lars Schimmer <l.schimmer@cgv.tugraz.at> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 2012-03-22 00:53, jukka.tuominen@finndesign.fi wrote:
> > Forgot one thing:
> > 
> > ...
> >> For me the slowness in WAN is about latency.
> > ...
> > 
> > I've tried to address this with faster DNS, installing BIND etc,
> > but with no notable improvement. Is this especially critical with
> > OpenAFS, or possibly when transferring a high number of small files
> > (like Firefox writing things to HD?).
> 
> For each file OpenAFS has to do at least one lookup on the fileserver
> (across the local file cache on client). The more little files you
> use, the more stats are in network queue, the longer it takes.
> My 2 MB/sec was with files >2 GB which do still fit in local cache.
> With very much small files the speed goes down to 100 kb/sec and less.

even outside of the size of files, , the afs rpc fetches a certain
amount of data over the wire with each request.  if each fetch
requests 32k and the delay is 10ms, the rate you can expect is given by
the bandwidth-delay product. see

http://en.wikipedia.org/wiki/Bandwidth_delay_product

but for this example, expect 26Mb/s.   i dont happen to recall how much
afs fetches for each read.

but besides this limit, there is also another determining factor in rx.
rx, like tcp, negotiates a window of data to send before waiting for an
ack from the other side which lets me data get sent.  if the window
doesnt grow large enough, then you will not be able to get the full
bandwidth of the link.  i believe usually, you hit the window size
limit in rx before anything else though.

there are some problems with using larger window sizes in rx related to
queue management efficiency as i recall.