Re: [Ccrtp-devel] SchedulingTimeout problem

[David Sugar]

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:
>
>                         controlReceptionService();
>                         controlTransmissionService();
>                         dispatchDataPacket();
>                         takeInDataPacket();
>
> 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:
>
> > Hi,
> >
> > why can't we use to threads : one for receiving packets, one for
> > managing scheduled packets sending?
> > regards,
> >
> > 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:
> > >
> > > > Hi,
> > > >
> > > > 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?
> > > > Regards,
> > > >
> > > > Guillaume Glodas
>
>
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel