Performance Adjustments: Silly Frames and poll() timeout

I have done some benchmarking, and found that silly frames sap 40% of the 
throughput I get in transferring large messages (in other words, 
eliminating silly frames improves throughput by 60%).  So eliminating 
silly frames is not just an academic exercise.

I also noticed that I was seeing rather long latencies, up to 700+ msec,
as if everything was getting batched up and sent once about every 3/4 sec.  
I noticed a poll() call in
threaded_os/transport/bp_fpollmgr.c:IW_fpollmgr_fds() with a number of
milliseconds that was set to "3 * pn->size" (pn is the POLL NODE pointer).  
This seems to be a rather strange assumption, and I found that it was
translating to 768 milliseconds.  When I cut this down to just a few
milliseconds, the latency of small messages drops by more than an order of
magnitude, down to a few tens of milliseconds.  It seems to me something
is going wrong here, or the poll() call would not even need to reach its
timeout.  Any ideas?  Also oddly, my silly frame cure combined with a
short poll() interval sometimes causes stalls.

I wonder whether perhaps something else is waiting to happen and cannot
because the pn->lock is locked during the poll() call.  Like something 
that is trying to set some pollfds, perhaps, as a new message is being 
worked with.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click