On Thu, 22 Mar 2012 08:42:16 +0100 Lars Schimmer <l.schim...@cgv.tugraz.at> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2012-03-22 00:53, jukka.tuomi...@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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info