Michael Meffie wrote: > The number of spares is reduced to 2 integers by this change, > but since this is not an RX call, but rather the payload of an > rx debug packet, I believe addtional integers could be added > up to the limit imposed on the packet size. There is not method of negotiating the size of the rx_debugStats structure used in the RX_DEBUGI_GETSTATS debug call. As a result it is not possible to increase the length of this structure and ensure that a peer with the new structure can send a RX_DEBUGI_GETSTATS response to a peer that only knows the old structure.
If we run out of space we will have to implement RX_DEBUGI_GETSTATS2. As for whether or not "the number of ack packets that have been delayed due to excessive aborts" should be sent or not, I wonder if that number is really a useful number from the perspective of debugging the server state. From my perspective the question that one is trying to answer is whether or not a particular rx_connection or rx_peer is being throttled. I don't think reporting the number of delays will help address that question. To address the question I have posed statistics would have to be collected per connection and reported in the rx_debugConn structure which currently has 9 spares. The rx_debugPeer structure currently has 10 spares. I am currently opposed to modifying the rx_debugStats because I do not understand what question it could solve that would be worth asking. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
