Raphael Coeffic wrote: > On 30.09.10 10:10, Jeremya wrote: >> In 1.2.1 I've noticed that the nanosleep call in wheeltimer.cpp does not >> check for EINTR return code and retry the sleep if it has been >> interrupted with EINTR. This potentially makes the wall_clock go faster? >> > No, because it is always recomputed based on the theoritical value and > gettimeofday(). > This mean that if we wanted to wait 20 ms, and have been interrupted > after 10 ms, the next time interval computed will be 30 ms. > >> Is this an issue? > Only if SEMS gets flooded with signals, which should actually not happen. > > Cheers > Raphael.
Thanks Raphael. Thanks for your help. I'm trying to resolve a problem where the timing of many events in SEMS appears to be faulty. My application dials out to 5 different targets (they auto answer) in a very short period. The intention is to join them in a conference. I see all sorts of errors occurring - such as some INVITE requests being repeated after a (very) short period, as well as many client responses being 'held in the system' for a period - sometimes seconds. I see the clients retry on timeout, but eventually all traffic has a handshake. I suspect the problem is event management / timing in SEMS. The only other thing I see is that these problems are much reduced on a single core low speed processor, but are very obvious on a dual CPU dual core Xeon. Any advice appreciated. _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
