[OpenAFS] Re: Performance problems seem to be coming back
Thu, 15 Sep 2011 11:28:35 -0500
On Thu, 15 Sep 2011 08:05:07 -0400
Dale Pontius <firstname.lastname@example.org> wrote:
> Then I kept reading man pages and suggestions here, and came up with
> "rxdebug -servers localhost -port 7001 -rxstats", which appeared to
> give round-trip times. This sounded like a better option. Of course
> since I first did this at work, all of the rtt's were zero.
Those rtts are only computed for certain packet types, and depending on
the version in use may be way off. You can try looking at the rxdebug
information on the _other_ end of the connection for another rtt
estimate, but I tend to not really trust those numbers.
> There's obviously a little bit of distress there I presume, because 2
> packets were resent. Also, on my first run of this code, my timeout was
> 2 sec, and here it has increased to 3 sec. but the "rtt" and "rtt_dev"
> fields are still 0.
The peer "timeout" changes due to a variety of things, not just the rtt
fields. (I think a resend may be one of those things)
> Is there some other flag I should be feeding rxdebug, or a different way
> I should be trying to make this measurment?
I'm not clear on what you're trying to measure. If you want to get an
rtt for a single transmission, then use rxdebug -version and throw away
any run that takes longer than 1 second, because that means it retried
the request. If you want something to tell you the rtt for a bunch of
transmissions and say when it dropped packets and such... that's the rx
ping-like tool I mentioned before, which doesn't exist but could.
If you want "performance" like just "how long does it take to transfer
data", there's a tool called rxperf that is supposed to be somewhat like
iperf. It's not the most intuitive thing in the world, but it will shove
a bunch of bits over the wire over Rx, if that's all you want.
> On the same note, the "afsio" and "afscp" appear to be missing from my
> installation. When you talk about "one-shot read-the-file" do you
> mean that those commands bypass the cache?
Yes. They are completely standalone programs that don't deal with the
"normal" client in any way (er, iirc one of them uses the kernel for the
filename lookup and auth, but the actual data transfer doesn't involve
the kernel). afsio is in src/venus and afscp is in src/tests; just 'make
afsio' or 'make afscp' in those dirs I think will get you them.