[OpenAFS] Re: Openafs vs Red Hat's Netkey

Andrew Deason adeason@sinenomine.net
Mon, 9 Dec 2013 10:51:16 -0600


On Mon, 9 Dec 2013 11:24:55 -0500 (EST)
Steve Gaarder <gaarder1@math.cornell.edu> wrote:

> Then try copying a large file from AFS to the client's local storage,
> e.g. with rsync --progress.  You will see performance steadily drop to
> miserable levels.

Could you specifically say what the before/after rates are, for what
you're seeing? These terms are really subjective; some people would call
the normal performance you get already "miserable".

> If you switch the client to the KLIPS stack (by using the kernel
> module that comes with the Openswan source), things run fine.  It does
> not seem to matter which stack is on the server.
> 
> Any ideas about what is going on?

A guess would be that something is causing packets to get dropped
somewhere along the line. Do you have any idea if you're using
jumbograms? You could also just try testing iperf UDP and see if this
seems to impact the results similarly.

One way to check for packet drops is to check the number of rx resends
using 'rxdebug -rxstat -noconn' for the client and server. (specify
'rxdebug <hostname> <port> -rxstat -nocoon'; port 7001 for client, 7000
for server). You can see a "resends" counter in there, and if it's going
up significantly during a transfer, packets are getting lost. (replace
'-rxstat' with '-peer' to get that stat for individual peers)

You can also look at a tcpdump for the two endpoints, but I'm not clear
on how much you actually get to see unencrypted. But if you're able to
identify some packets leaving the client but not making it to the
server, you don't really need to know what's in the packets to know
that's a problem :)


-- 
Andrew Deason
adeason@sinenomine.net