I did some testing last night on this, from home. On a Gentoo system which has seldom connected to work, I did an update including kernel and openconnect. Because it was a new kernel (3.0.3) I rebuilt the openafs-1.6.0_pre7 kernel module as well. Connection to work went fine, though because I was running openconnect through my script instead of init.d I ended up using my /etc/vpnc/vpnc-script. (There were only minor differences between vpnc-script and openconnect.sh.) Upon connection my MTU was either 1402 or 1420 - I forget which, now. Then I started openafs-client, klogged, and verified that I had a token. First I ran a simple "ls" against my home directory, giving the full path instead of any of the symlink shortcuts. That took 47 seconds to return the listing. (Ick!) Next I ran a simple "ls" against the top-level of our department shared space, again giving the full path. This time it took 18 seconds to return the listing. Then I listed another shared space, and it took just under 10 seconds. Every listing after that took under 5 seconds, typically 3 or 4 seconds. I'm not sure what was getting "primed" there, perhaps much of it was simply getting from the top of the company tree to my home cell. Since this system hadn't been used to connect to work in some time, I considered the afs cache to be empty. (Maybe I should have done that explicitly, I guess.) Anyway, after getting rolling, I would not be dissatisfied with 3 or 4 seconds for first touch, from home. I guess I should verify also that second touch is much faster, and that cache interrogation traffic isn't as slow as that 3 or 4 seconds. Dale Pontius On 08/17/2011 03:47 PM, David Woodhouse wrote: > On Wed, 2011-08-17 at 12:25 -0700, er0ck wrote: >> i'm a user, not an admin. i don't have shell access to the afs >> servers, don't think i can run tcpdump on that end. > ISTR it's distinctly non-trivial to set up your own AFS server that you > can test with, right? > >> however, this is silly, but it looks like reducing the MTU has made >> afs MUCH more snappy. >> the vpn server was giving me an MTU of 1602. my gig ethernet sans >> jumbo frames is set to 1500. 1602 seems pretty big. >> i asked another user what his MTU was set to on AT&T client 1362. i >> used that and it seems snappy. > If you're at home or something, the odds are *very* low that you > actually have an MTU of 1602 (+VPN overhead) all the way to the VPN > server. If you're *lucky*, each packet is fragmented into two and > reassembled at the other end. If you're unlucky, the big packets are > just going missing and you're eventually falling back to smaller packets > which works, and that's why it's slow. > >> any advice on theory of how to optimize this? > Let's assume you're using DTLS (VPN over UDP between you and the VPN > server). > > The overhead on a VPN packet is: > IP header: 20 bytes > UDP header: 8 bytes > DTLS header: 13 bytes > Cisco VPN packet type: 1 byte > > Total: 42 bytes. > > So, if you're on a normal Internet link with 1500-byte MTU, your optimum > packet size will be 1458 bytes. If you're using PPPoE, your Internet MTU > will be 1492 and your optimum packet size will be 1450 bytes. > > For some reason the default MTU in OpenConnect is set to 1406; I don't > quite know why. Perhaps that was calculated based on overhead in TCP > mode, or maybe I just pulled a number out of my arse. > > I *thought* that the server would return only a *smaller* MTU than the > one we requested, but if you're getting 1602 then that seems to be > incorrect. Can you show the MTU-related output of 'openconnect -v' when > you connect to the server? > >> thanks again for all your help. >> ______________________________________________ >> Too brief? Here's why: http://emailcharter.org > Not too brief at all. Far from it, in fact. You quoted far *more* of the > previous message than you should have done... you should only repeat > parts of the previous message that are absolutely needed for context. > -- Dale Pontius Senior Engineer IBM Corporation Phone: (802) 769-6850 Tie-Line: 446-6850 email: pontius at us.ibm.com This e-mail and its attachments, if any, may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message from your system without copying it and notify sender of the misdirection by reply e-mail.
