Harald Barth wrote: >>Longer trace of all rx traffic around the time is in >>/afs/pdc.kth.se/home/h/haba/Public/openafs14-rx.cap.gz >>It contrains more than one of these hickups. > > > Sorry, I meant trace _15_: > /afs/pdc.kth.se/home/h/haba/Public/openafs15-rx.cap.gz > > It contains a bunch of ack packets with reason=delay. > But what is the reason for the delay? > > Frame 119,125,126 call #49 has a > request: fetch-status > reply: fetch-status > and then the client sends a delayed ack. > > Call 2972 has a delay packet as an answer to the > request fetch-status and the reply. > > Harald.
Just some background on how Delayed Acks should work: Delayed Acks are used to consolidate the number of ack packets sent when there isn't any data to send in the ack direction. There is a guarrantee that a hard ack is sent for every rxi_HardAckRate+1 incoming rx packets. Otherwise a delayed ack is scheduled. delayed acks are to be sent either when the call is ended, the connection is destroyed, or after the rx_hardAckDelay period (100 ms) expires. However, delayed ack events are really only sent when the event_handler() thread (rx_pthread.c) calls rxevent_RaiseEvents(). rxevent_RaiseEvents() will sleep for 30 seconds if there are no scheduled events or can take a very long time to cycle through its list if it takes a long time to process the events that are scheduled to be completed. In order for rxi_SendDelayedAck() to complete it must be able to obtain the mutex on the call->lock. If that lock is being held by another thread, there could be long delays in the processing of the rxevent_RaiseEvents() queue. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
