Re: [Ccrtp-devel] SchedulingTimeout problem

[Scott Lowrey]

I'm new to ccrtp but this issue might be of concern to me.  My 
application will require hundreds and, if the hardware and software 
supports it, thousands of two-way media streams on a single server.  
Whether or not my implementation would require multiple instances is a 
design issue I haven't come to yet.

I'm suspicious of doubling the thread count, so I'll ask this question: 
if I have a single instance, can I still run many concurrent streams?  
Or does each two-way connection require a separate instance?

David Sugar wrote:

> 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
>
>
>
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel