[OpenAFS] Re: Performance problems seem to be coming back

Dale Pontius pontius@btv.ibm.com
Mon, 12 Sep 2011 11:31:56 -0400

On 09/12/2011 10:41 AM, Ken Dreyer wrote:
> On Mon, Sep 12, 2011 at 5:46 AM, Dale Pontius<pontius@btv.ibm.com>  wrote:
>> In this case, I'm wanting something that acts more like normal AFS packets,
>> and I believe that's what rxdebug is doing in this case.  Some people around
>> here have been using ping as an indicator of network latency, and while it
>> can be an indicator, I don't believe it's terribly representative of what is
>> happening to AFS packets.  I believe the current rxdebug is more indicative,
>> though I can accept evidence otherwise.
> A while back I looked into writing an iperf probe for Smokeping, which
> would at least provide the metrics for UDP rather than ICMP, for the
> reason you describe. I got pulled onto other things, but it would be
> nice to have.
Maybe I'm missing what rxdebug really does, but I think it sounds just 
about perfect.  I presume that the OpenAFS clients and servers have 
packet queues for moving data, and rxdebug just drops packets into those 
queues like any other part of afs.  If the other parts of afs queue are 
in "distress" for whatever reason, all of the other packets in that 
queue will share in the distress, including my rxdebug requests.  In 
this case, that's what I want - to be told about "distress" between the 
server and me, and for the first approximation I'm not too concerned 
about the reason, just that it exists.

The specific reason for the distress is the next layer of the onion, and 
the difference between (my interpretation of) the rxping and a UDP ping 
that doesn't go through the afs server could be part of that.

Dale Pontius

Dale Pontius
Senior Engineer
IBM Corporation
Phone: (802) 769-6850
Tie-Line: 446-6850
email: pontius@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.