3 years, 9 months ago
(2017-03-13 10:30:36 UTC)
#16
Dry run: This issue passed the CQ dry run.
tommi
lgtm
3 years, 9 months ago
(2017-03-13 10:35:08 UTC)
#17
lgtm
ilnik
On 2017/03/13 10:35:08, tommi (webrtc) wrote: > lgtm Tommi, I have added little fix for ...
3 years, 9 months ago
(2017-03-13 17:00:24 UTC)
#18
On 2017/03/13 10:35:08, tommi (webrtc) wrote:
> lgtm
Tommi, I have added little fix for TaskQueue on windows. Please, take a look.
The issue is: if queue is starved, then delayed tasks may be delayed
indefinitely. Problem is that it's a different behavior from another platforms
and it causes some tests to fail.
More specifically, It may break overuse detection (and
CallPerfTest.ReceivesCpuOveruseAndUnderuse fails) on Windows. Overuse checks are
posted to EncoderQueue as delayed tasks. However, since we are overusing CPU
there always are posted tasks to execute and therefore there always are
WM_RUN_TASK messages in the working thread queue. I still don't get why WM_TIMER
messages are not sent. In the end CheckOveruse task is not executed until frame
generator is stopped at the end of the test then it already failed.
I believe it would be more fair if queue tried to run scheduled tasks first, as
they were posted earlier. It also will make behavior uniform across different
platforms.
tommi
On 2017/03/13 17:00:24, ilnik wrote: > On 2017/03/13 10:35:08, tommi (webrtc) wrote: > > lgtm ...
3 years, 9 months ago
(2017-03-13 20:03:39 UTC)
#19
On 2017/03/13 17:00:24, ilnik wrote:
> On 2017/03/13 10:35:08, tommi (webrtc) wrote:
> > lgtm
>
> Tommi, I have added little fix for TaskQueue on windows. Please, take a look.
> The issue is: if queue is starved, then delayed tasks may be delayed
> indefinitely. Problem is that it's a different behavior from another platforms
> and it causes some tests to fail.
> More specifically, It may break overuse detection (and
> CallPerfTest.ReceivesCpuOveruseAndUnderuse fails) on Windows. Overuse checks
are
> posted to EncoderQueue as delayed tasks. However, since we are overusing CPU
> there always are posted tasks to execute and therefore there always are
> WM_RUN_TASK messages in the working thread queue. I still don't get why
WM_TIMER
> messages are not sent. In the end CheckOveruse task is not executed until
frame
> generator is stopped at the end of the test then it already failed.
>
> I believe it would be more fair if queue tried to run scheduled tasks first,
as
> they were posted earlier. It also will make behavior uniform across different
> platforms.
I don't understand exactly what you mean by 'starved'. Can you ping me when you
have time so that we can chat?
ilnik
On 2017/03/13 20:03:39, tommi (webrtc) wrote: > On 2017/03/13 17:00:24, ilnik wrote: > > On ...
3 years, 9 months ago
(2017-03-15 14:09:28 UTC)
#20
On 2017/03/13 20:03:39, tommi (webrtc) wrote:
> On 2017/03/13 17:00:24, ilnik wrote:
> > On 2017/03/13 10:35:08, tommi (webrtc) wrote:
> > > lgtm
> >
> > Tommi, I have added little fix for TaskQueue on windows. Please, take a
look.
> > The issue is: if queue is starved, then delayed tasks may be delayed
> > indefinitely. Problem is that it's a different behavior from another
platforms
> > and it causes some tests to fail.
> > More specifically, It may break overuse detection (and
> > CallPerfTest.ReceivesCpuOveruseAndUnderuse fails) on Windows. Overuse checks
> are
> > posted to EncoderQueue as delayed tasks. However, since we are overusing CPU
> > there always are posted tasks to execute and therefore there always are
> > WM_RUN_TASK messages in the working thread queue. I still don't get why
> WM_TIMER
> > messages are not sent. In the end CheckOveruse task is not executed until
> frame
> > generator is stopped at the end of the test then it already failed.
> >
> > I believe it would be more fair if queue tried to run scheduled tasks first,
> as
> > they were posted earlier. It also will make behavior uniform across
different
> > platforms.
>
> I don't understand exactly what you mean by 'starved'. Can you ping me when
you
> have time so that we can chat?
All changes after LGTM from Tommi@ are reverted. Queue issues are resolved in
https://codereview.webrtc.org/2750853002 .
ilnik
The CQ bit was checked by ilnik@webrtc.org
3 years, 9 months ago
(2017-03-15 14:09:38 UTC)
#21
A revert of this CL (patchset #11 id:300001) has been created in https://codereview.webrtc.org/2751063005/ by ilnik@webrtc.org. ...
3 years, 9 months ago
(2017-03-16 15:52:20 UTC)
#27
Message was sent while issue was closed.
A revert of this CL (patchset #11 id:300001) has been created in
https://codereview.webrtc.org/2751063005/ by ilnik@webrtc.org.
The reason for reverting is: Changes to frame-generator resulted in reduced fps
on android and Mac on all tests..
ilnik
A revert of this CL (patchset #11 id:300001) has been created in https://codereview.webrtc.org/2759623002/ by ilnik@webrtc.org. ...
3 years, 9 months ago
(2017-03-17 10:47:10 UTC)
#28
Issue 2750473002: Reland of write frame generator capturer to use TaskQueue instead of EventTimeWrapper
(Closed)
Created 3 years, 9 months ago by ilnik
Modified 3 years, 9 months ago
Reviewers: sprang_webrtc, tommi, stefan-webrtc
Base URL:
Comments: 0