[OpenAFS-devel] .35 sec rx delay bug?

[Derrick J Brashear]

On Mon, 6 Nov 2006, Rainer Toebbicke wrote:

> . There are a few more places in the protocol that need a "dpf" macro in 
> order to make the RX trace useful. A lock (...), the current thread ID in the 
> output and microsecond resolution in rx_debugPrint are a must for any serious 
> work.
>
[]
>
> . With bigger windows, and a routed network, the windows of 350 ms for ACKs 
> is actually low, the price for retransmits is high. Here is makes sense to 
> increase the timeout.
>
> . Allocating new packets is done under a lock. As a result incoming ACKs get 
> processed late and contribute to keeping the queue size high. I introduced a 
> "hint" in the call which causes the alloc to release and re-grab the lock 
> between packets. That helped quite a lot.

[]

> . I'm currently trying to understand another puzzling case of ACKs being 
> received but processed only about a millisecond later. Probably yet another 
> locking problem.

I have a vague recollection of something where we looked only at the most 
recent ack we were looking for and if it wasn't it, we queued it for 
"later" processing, or something similarly weird, but at this point it's 
been like 4 years since I touched that code.

Do you have a patch of what you have so far?

Derrick