[EMAIL PROTECTED] wrote on Thu, 21 Dec 2006 16:26 -0500: > On Dec 21, 2006, at 3:59 PM, Pete Wyckoff wrote: > >[EMAIL PROTECTED] wrote on Thu, 21 Dec 2006 15:50 -0500: > >>Client posts a receive with op_id 5, bmi tag 1 and length 32808 > >>Client posts an unexpected send with op_id 7, bmi tag 1 and length 24 [..] > >>Server receives unexpected recv with bmi tag 1 and length 24 > >>Server posts an expected send with op_id 79, bmi tag 1 and length 816 [..] > >>On the Client: > >>[E 15:40:10.538206] job_time_mgr_expire: job time out: cancelling bmi > >>operation, job_id: 4. > >>[E 15:40:10.538421] job_time_mgr_expire: job time out: cancelling bmi > >>operation, job_id: 6. [..] > >>On the Server: > >>[E 12/21 15:40] job_time_mgr_expire: job time out: cancelling bmi > >>operation, job_id: 78. [..] > I did not think the op_ids would match, but bmi_mx does not see the > timed out ops in any post_send or post_recv functions. Are these > operations passing through bmi_mx (possibly via other BMI_meth_* > functions) or are these unrelated to bmi_mx?
IDs are assigned to jobs. IDs are also assigned to BMI operations. They share the same number space but are different things. A job may require a few BMI operations to go to completion, and perhaps a few disk operations. Job id 78 seems to require BMI id 79, for instance. > Also, the client posts a receive with bmi tag 1 for a length of 32808 > but the server posts a send with bmi tag 1 and a length of 816. Is > that normal? It is known in the protocol that the maximum size of the response is 32k-ish. But, the server rarely needs to construct a response of the maximum size. It's normal. -- Pete _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers