On 9/12/2011 11:31 AM, Dale Pontius wrote: > 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
An ICMP ping (not UDP) is processed by the IP stack of the receiving machine and does not get seen by any applications. A UDP ping such as the "echo" service provides information about the delivery of UDP packets and response after processing by an application on the machine. An rxdebug -ver (version query) is similar to a UDP "echo" service request in that is it processed by an application. The difference between an rx version query and an AFS GetTime RPC is that the rx layer will reply immediately to a version query and will not queue an RPC to be processed by a file server worker thread. The probes performed by the AFS cache manager are AFS RPCs which require processing by the File Server or Volume Location server worker threads. As such, the cache manager will mark down a server that is not responding to RPCs even though the Rx layer is happily responding to version queries. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
