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

[Rainer Toebbicke]

chas williams - CONTRACTOR wrote:


> 
> i dont know much about rxi_TrimDataBufs().  it looks like its trying
> to get empty rx buffers (due to a "short" read i guess) into the queue
> faster.  that's going to happen anyway.  benchmark it but i dont
> think i have every seen any traces showing significant time being
> spent in this code path.

Well, it does: the point is that the trim also applies to ACKs 
received. While releasing the excess buffers, the code actually *does* 
take locks often enough to delay the ACK where rule number one would 
be to process asap it in order to keep the queues short and the window 
open. I've seen 1ms delays through RX tracing, enough to close the window.

By commenting out this call I got a performance boost of almost 50% on 
an RX transfer with disk I/O - i.e. the one that suffers most of long 
queues: >90 MB/s instead of 65 MB/s on the same switch. Admittedly, 
that's not more yet than a smoking gun. In particular the tracing has 
it's own weaknesses.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155