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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig50F48A3424F64DD3D099B1FE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 thos=
e
> 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.
>=20
> The specific reason for the distress is the next layer of the onion, an=
d
> 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.
>=20
> 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



--------------enig50F48A3424F64DD3D099B1FE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJObi91AAoJENxm1CNJffh4HfcH/3SGNvOYSMnipNfTkEmdPwYB
HLcoi80ekc1INIWEKI7Ll+OYP4KxRkClNWjh7enje1A17lHB2dN9GPQNtB4Tp1Dg
XCfduv35lg7RZmo1WJ/SffHDt/zX2RfOsjtCoTSHAyHJeTsDUaiKwb6n35X5J93+
McH/Rn8JfQDU+VicrVxWofF/uzkmbONqTh9KIMopd10UQMFT8bBLsnSVlmWTOgSP
5PSNqSwxKZ/uXkN6Z/8EVyH01y2rUC1A6o8BlGRn4CPv8FXEWLsyJxJ+qcYRYJFi
ffsGoXXZVAUl3LCLOvGMCa5shPQShiDiJU6z+vva0lTx0fJQE0GIP3m06jO3TxA=
=14TN
-----END PGP SIGNATURE-----

--------------enig50F48A3424F64DD3D099B1FE--