|
From: Lei Z. <lz...@ju...> - 2004-04-06 19:18:15
|
David C Niemi wrote: >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. > So you have 768 /3 = 256 sessions in a single process? Can you make your application host smaller number of sessions? I played a little with the timeout value of poll() a little a while ago, my purpose then was to see if that helps reduce the CPU usage of my beepcore-c based application - and noticed the problem you described in this thread. > 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. > Assume I understand your question, here is an answer: this poll() usally does not have the WRITE mask set, some other thread will make the WRITE mask set. However, the mask change won't take effect until poll() times out, hence any outgoing message may have to wait as long as the poll timeout value before they get sent out. "3 * pn->size" seems to be a good timeout value: not too much latency, not too hard on CPU usage. Otherwise, we need a way to let poll() return whenver a mask for any fd is changed. Lei |