This seems excessive to me. It is normal to have many
iterations through the process loop to send the messages, receive their
responses and deal with the timers. Are you using a debug or release (optimized)
build? What level/type of logging do you have enabled? What is the
speed of your processor?
From: Subramanian Kasi
Subramanian [mailto:subbu.subramanian@xxxxxxxxx]
Sent: Thursday, January 31, 2008 10:16 AM
To: Scott Godin
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
Thank you Scott.
I send out a registration and publish and a bunch of subscribes when I login.
The CPU usage goes up to 65-70% due to this process loop. Even though it blocks
for 25ms in periods of inactivity.
Is this normal?
Thanks you
Subbu
----- Original Message ----
From: Scott Godin <slgodin@xxxxxxxxxxxx>
To: Subramanian Kasi Subramanian <subbu.subramanian@xxxxxxxxx>
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Sent: Thursday, January 31, 2008 8:01:36 AM
Subject: RE: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
StackThread should not spin a tight loop – during periods
of inactivity it should block for 25ms (see StackThread::getTimeTillNextProcessMS).
Note: there is a more efficient implementation of StackThread
that removes this 25ms loop during periods of inactivity. It is called:
InterruptableStackThread – it requires you to create a SelectInterruptor
and to pass to both InterruptableStackThread and SipStack constructors.
Scott
From:
resiprocate-users-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxx] On Behalf Of Subramanian
Kasi Subramanian
Sent: Wednesday, January 30, 2008 9:26 PM
To: Byron Campen; Ali Ziad
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
Hi guys
I'am having a similar problem. The main problem
for me seems to be the CPU usage when I run the Stackthread.
The only reason I used to stack thread is because the process loop(like the one
used in the basic call example) hogged cpu
since it was continuously spinning
How did you guys handle this problem.?
Thanks
Subbu
----- Original Message ----
From: Byron Campen <bcampen@xxxxxxxxxxxx>
To: Ali Ziad <aziad@xxxxxxxxxxxxxx>
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Sent: Wednesday, January 9, 2008 2:50:47 PM
Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
Yeah, that's it, just make sure to call run after your stack
is
configured.
Best regards,
Byron Campen
> Thanks Byron.
>
> Since my application has a lot going on in the main thread, a separate
> StackThread sounds like a good idea.
>
> Is this how it would work:
>
> On startup:
> :
> StackThread st(myStack);
> St.run();
>
>
> Then in my main application idle loop, I would call dumUac->Process
> () ?
>
>
> Thanks,
> Ali Ziad
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> Sent: Wednesday, January 09, 2008 1:11 PM
> To: Ali Ziad
> Cc: resiprocate-users@xxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
Alive"
>
> StackThread will give the stack its own thread, and
this is
> generally the recommended way to use the stack. Since all
> communication into and out-of the stack is threadsafe, this should
> not upset the thread-safety of your app.
>
> Best regards,
> Byron Campen
>
>
>> I am integrating ReSIProcate into an existing application which
>> has to
>> attend to other functions and cannot be held up for a long time
>> waiting for
>> SIP events.
>>
>> So, In my global application idle loop, I call the stack processing
>> sequence
>> with the minimal timeout of 1ms for the select, assuming I will
>> revisit it
>> within the second for the next avail message.
>>
>> int someInt=0;
>>
>> if (!uacShutdownHandler->dumShutDown)
>> {
>> FdSet fdset;
>> stackUac->buildFdSet(fdset);
>> int err =
fdset.selectMilliSeconds(resipMin((int)
>> stackUac->getTimeTillNextProcessMS(), 1));
>> assert ( err != -1 );
>> stackUac->process(fdset);
>> while(dumUac->process());
>> }
>>
>> Spending too much time waiting here (50ms) was interfering with the
>> RTP
>> media timing.
>>
>> Is using StackThread a reliable/recommended approach? How does it
>> interact
>> with my DUM and Event handler classes?
>>
>> -ali
>>
>>
>> -----Original Message-----
>> From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
>> Sent: Wednesday, January 09, 2008 11:08 AM
>> To: Ali Ziad
>> Cc: resiprocate-users@xxxxxxxxxxxxxxx
>> Subject: Re: [reSIProcate-users] SIP Registration Renewal/"Keep
>> Alive"
>>
>> It looks like the stack thread is being
cycle-starved. Note the very
>>
>> long time between the sending of the second REGISTER request from DUM
>> (at 10:00:33), and the next time the transaction state machine fires
>> up (10:00:40), in the logs below.
>>
>> Are you using a StackThread to give cycles to the
stack? Or are you
>>
>> using some other method?
>>
>> Best regards,
>> Byron Campen
>>
>>
>>> DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 |
>>> DialogUsageManager.cxx:832 | SEND:
>>>
>>> REGISTER sip:192.168.10.212 SIP/2.0
>>>
>>> Via: SIP/2.0/ ;branch=z9hG4bK-d8754z-216c1c5d9e22083a-1---
>>> d8754z-;rport
>>>
>>> Max-Forwards: 70
>>>
>>> Contact: <sip:ali_pc;rinstance=e5646707bb14480b>
>>>
>>> To: <sip:ali_pc@xxxxxxxxxxxxxx>
>>>
>>> From: <sip:ali_pc@xxxxxxxxxxxxxx>;tag=a70cf259
>>>
>>> Call-ID: ZTM4NjgwYWQ3M2VlOTQxNDE2MmU1YTU5ZjExOWRjZDY.
>>>
>>> CSeq: 3 REGISTER
>>>
>>> Expires: 70
>>>
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
>>>
>>> Proxy-Authorization: Digest
>>>
username="ali_pc",realm="192.168.10.212",nonce="12844364358:7c2c4f86
>>> 6
>>> e
>>> 569c98
>>> c2cf13c15744fb03",uri="sip:
>>> 192.168.10.212",response="e2831ec987ad218b7774b20
>>> ae402516f",cnonce="04756c683133255f",nc=00000002,qop=auth-
>>> int,algorithm=MD5
>>>
>>> Content-Length: 0
>>>
>>>
>>>
>>>
>>> DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 |
>>> DialogId.cxx:50 | DialogId::DialogId:
>>> ZTM4NjgwYWQ3M2VlOTQxNDE2MmU1YTU5ZjExOWRjZDY.-a70cf259-
>>> DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP:DUM | 2704 |
>>> DialogUsageManager.cxx:963 | Send: SipReq: REGISTER
192.168.10.212
>>> tid=216c1c5d9e22083a cseq=REGISTER contact=ali_pc / 3 from(tu)
>>> DEBUG | 20080109-100033.000 | Sytech:ResipLib | RESIP | 2704 |
>>> SipStack.cxx:307 | SEND: SipReq: REGISTER 192.168.10.212
>>> tid=216c1c5d9e22083a cseq=REGISTER contact=ali_pc / 3 from(tu)
>>> DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:TRANSACTION
|
>>> 2704 |
>>> TimerQueue.cxx:85 | Adding timer: Timer F tid=216c1c5d9e22083a
>>> ms=32000
>>> DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:TRANSPORT |
>>> 2704 |
>>> TransportSelector.cxx:275 | Looking up dns entries for sip:
>>> 192.168.10.212
>>> DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:DNS | 2704 |
>>> DnsResult.cxx:221 | DnsResult::lookup sip:192.168.10.212
>>> DEBUG | 20080109-100040.437 | Sytech:ResipLib | RESIP:DNS | 2704 |
>>> DnsResult.cxx:405 | Numeric result so return immediately: [ V4
>>>
>>
>
>
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try it now.
Be a better friend, newshound, and know-it-all with Yahoo!
Mobile. Try
it now.
|