RE: Transport change in MS Proposal

Ganesh,

Sorry, it should have been 60ms (10ms is lost in my slow brain).

Thanks,
Li

-----Original Message-----
From: Venkatesan, Ganesh [mailto:ganesh.venkatesan@intel.com] 
Sent: Friday, August 31, 2012 5:14 PM
To: Li Li; Martin Thomson
Cc: public-webrtc@w3.org
Subject: RE: Transport change in MS Proposal

> At t: register a callback to listen on bandwidth change;
>
> At t+10ms: the callback fires, but is queued as the thread is executing another function;
> 
> At t+70ms: the function finishes and the callback is executed;
> 
> So there is a 50ms delay. Would such unbound delay cause any problem in practice or do we have to force the use of worker threads?

I get your point about unbounded delays due to the processing of events queued up in a "queue".  However, I am not sure how the delay computed to be 50ms? It is 60ms (t+70ms - (t+10ms)). Am I missing something?

Cheers --
ganesh
 
-----Original Message-----
From: Li Li [mailto:Li.NJ.Li@huawei.com] 
Sent: Friday, August 31, 2012 9:05 AM
To: Martin Thomson
Cc: public-webrtc@w3.org
Subject: RE: Transport change in MS Proposal

Martin,

My concern is on whether the Javascript callbacks can be executed in timely fashion. Based on this analysis [1], it seems a callback is queued like timer events.
For a contrived example, in a JS thread:

At t: register a callback to listen on bandwidth change;

At t+10ms: the callback fires, but is queued as the thread is executing another function;

At t+70ms: the function finishes and the callback is executed;

So there is a 50ms delay. Would such unbound delay cause any problem in practice or do we have to force the use of worker threads? 

Thanks,
Li

[1] http://blogs.msdn.com/b/davrous/archive/2011/07/15/introduction-to-the-html5-web-workers-the-javascript-multithreading-approach.aspx


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Wednesday, August 29, 2012 5:36 PM
To: Li Li
Cc: public-webrtc@w3.org
Subject: Re: Transport change in MS Proposal

On 29 August 2012 12:35, Li Li <Li.NJ.Li@huawei.com> wrote:
> Martin,
>
> In the MS proposal [1], a JS application has the ability to change the transport for a RealtimeMediaStream object, when detecting the transport bandwidth is too low through JS callback.
> Since JS execution cannot be interrupted by callbacks, what happens if the callback is delayed by a long running JS block?

Javascript should not block in this way.  If your javascript does not return control to the browser at least 60 times a second, people are going to notice some performance degradation.  Even assuming that you are operating slower than this, I'm not sure what you imagine would be so time-sensitive as to require this sort of reaction time.

--Martin

Received on Friday, 31 August 2012 21:42:50 UTC