[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ccrtp-devel] SchedulingTimeout problem

From: David Sugar
Subject: Re: [Ccrtp-devel] SchedulingTimeout problem
Date: Thu, 25 Nov 2004 08:11:22 -0500
User-agent: Mozilla Thunderbird 0.9 (Macintosh/20041103)

The idea behind threading the rtp stack in the first place was to offer smoother smp performance when perhaps hundreds of stacks are running concurrently, such as in some form of media streaming or voip server. Certainly there are many applications where only one stack instance will be running (client applications generally fall into this category), and with the future commonness of multi-core cpu's, they too could potentially benefit from spreading functionality over multiple threads as well as reducing windows where delay may occur in trying to manage both send and receive. However, when building larger collections, such as streaming servers, we do not want to have so many threads that we reach system scheduling limits. If we could support both a 1 for 1 thread/stack model, and a 2 or 4 for 1, that would be okay. If we can't do both, I think we should stay with the 1 for 1 model and see if we can improve how we process to reduce or eliminate any bottlenecks.

Federico Montesino Pouzols wrote:
In principle we could, and apart from doubling the number of threads I
see no drawback. The idea is that the run method(s) must execute the
following 4 methods:


and these could be distributed between two threads, in a say
'DualThreadRTPSession' template. In the extreme case you could even
have 4 threads. I'm curious, have you find any scenario where having
just one thread downgrades performance?

On Tue, Nov 23, 2004 at 06:59:57PM +0100, Guillaume Glodas wrote:


why can't we use to threads : one for receiving packets, one for
managing scheduled packets sending?

Guillaume Glodas

Le mar 21/09/2004 à 14:49, Federico Montesino Pouzols a écrit :

  Looks interesting, however, the new run method waits for WAIT_DATA_TIMEOUT.
would it block the reception service when there are no outgoing packets? After a first look I got that impression.

On Tue, Sep 14, 2004 at 01:55:16PM +0200, Guillaume Glodas wrote:


When there is no data to send, the ccrtp thread waits until
defaultSchedulingTimeout is reached even if data are pushed in the
queue. When defaultSchedulingTimeout is too high it can cause packet to
be sent too late, when defaultSchedulingTimeout is too small it can
increase the load of the computer.
That's why we propose to replace this timeout with a
OutgoingDataQueue::waitData method which waits until the queue is no
more empty or a timeout is reached. It seems to dicrease computer load.
What do you think about this modification?

Guillaume Glodas

Ccrtp-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]