On 30.09.10 13:19, Jeremya wrote:
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.
Any wireshark traces? Is SEMS really sending re-transmissions within a
very short interval? How short is this interval?
Have you tried with 1.3.0?
-Raphael.
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
