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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
