Measure bandwidth utilization in the scroll perf test

Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93%
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656
Committed: https://crrev.com/d5ce2225173ec41804750d3de0211408ba096bb9
Cr-Commit-Position: refs/heads/master@{#418444}

[Sergey Ulanov, 2016-09-13 17:16:49]

Patchset #1 (id:1) has been deleted

[Sergey Ulanov, 2016-09-13 17:35:57]

Description was changed from

==========
Measure bandwidth utilization in the scroll perf test

BUG=645656
==========

to

==========
Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using 
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93% 
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656
==========

[Sergey Ulanov, 2016-09-13 17:35:58]

sergeyu@chromium.org changed reviewers:
+ isheriff@chromium.org

[Irfan, 2016-09-13 20:19:16]

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
File remoting/test/protocol_perftest.cc (right):

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
remoting/test/protocol_perftest.cc:214: EXPECT_GE(frame_stats_.size(),
num_expected_frame_stats_);
should this be EXPECT_EQ ?

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
remoting/test/protocol_perftest.cc:581: VLOG(0) << "Average latency: " <<
latency_sum.InMillisecondsF() / num_frames;
Output units on latency and total size ?

[Sergey Ulanov, 2016-09-13 20:37:39]

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
File remoting/test/protocol_perftest.cc (right):

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
remoting/test/protocol_perftest.cc:214: EXPECT_GE(frame_stats_.size(),
num_expected_frame_stats_);
On 2016/09/13 20:19:15, Irfan wrote:
> should this be EXPECT_EQ ?

No. Potentially multiple VideoFrameStats messages may be received in bulk. We
cannot guarantee that no new FrameStats received after OnVideoFrameStats() calls
RunLoop::Quit() and before RunLoop::Run() returns.

https://codereview.chromium.org/2338693002/diff/40001/remoting/test/protocol_...
remoting/test/protocol_perftest.cc:581: VLOG(0) << "Average latency: " <<
latency_sum.InMillisecondsF() / num_frames;
On 2016/09/13 20:19:15, Irfan wrote:
> Output units on latency and total size ?

Done.

[Irfan, 2016-09-13 21:20:44]

lgtm

[Sergey Ulanov, 2016-09-13 21:47:46]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2016-09-13 21:48:27]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-13 22:25:21]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-13 22:25:22]

Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Sergey Ulanov, 2016-09-14 00:31:55]

The CQ bit was checked by sergeyu@chromium.org

[Sergey Ulanov, 2016-09-14 00:31:55]

The patchset sent to the CQ was uploaded after l-g-t-m from
isheriff@chromium.org
Link to the patchset: https://codereview.chromium.org/2338693002/#ps2 (title:
"header")

[commit-bot: I haz the power, 2016-09-14 00:32:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 01:18:41]

Description was changed from

==========
Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using 
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93% 
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656
==========

to

==========
Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using 
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93% 
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656
==========

[commit-bot: I haz the power, 2016-09-14 01:18:42]

Committed patchset #4 (id:2)

[commit-bot: I haz the power, 2016-09-14 01:20:29]

Description was changed from

==========
Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using 
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93% 
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656
==========

to

==========
Measure bandwidth utilization in the ScrollPerformance test

Now ScrollPerformance also reports network bandwidth utilization.

Also removed two outdated tests: StreamFrameRate and IntermittentChanges.
These tests were intended mainly to evaluate performance of the PseudoTCP
layer and they were using verbatim video codec. They are not applicable
for WebRTC-based protocol. Also the protocol perf tests have been updated
to use SoftwareVideoRenderer which allows to get FrameStats when using
ICE protocol and this approach is not compatible with the old tests.

Bandwidth utilization numbers I get currently with 8Mbps bandwidth:
ICE: 93%
WebRTC: varies from 21 to 25%

The second number also goes to 32 when I change test length and warm-up
time to 5 seconds. This suggests that the problem is partly that the
bandwidth estimate in WebRTC is below the actual bandwidth in the test and
it takes a lot of time to ramp up.

BUG=645656

Committed: https://crrev.com/d5ce2225173ec41804750d3de0211408ba096bb9
Cr-Commit-Position: refs/heads/master@{#418444}
==========

[commit-bot: I haz the power, 2016-09-14 01:20:30]

Patchset 4 (id:??) landed as
https://crrev.com/d5ce2225173ec41804750d3de0211408ba096bb9
Cr-Commit-Position: refs/heads/master@{#418444}