All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=621019

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggvfEswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggre_ogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggpCmsgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggvi_tQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggrfIqAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggvj1uQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_Mml4wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggomZowoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggvjcoAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggty4ugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggpyBvAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_NmArgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_JmbtwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggqDxtwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_M_tuAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_N7ErAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgguynuAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_LfatgkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_PiVpwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvN_M-QgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggsClvQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgvN_MuQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg_M-WsAkM


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus5
webrtc-android-tests-nexus72
webrtc-android-tests-nexus9
webrtc-linux-large-tests
webrtc-win-large-tests

Hi Per, looks like your CL caused some impressive perf improvements all around (nice!), could you have a look at the changes in bitrate_stats_min_transmit_bitrate/bitrate_kbps? I don't know enough about it to tell if it's an improvement or regression. Thanks.

Oops, forgot to include a link to your CL, it's this one: https://codereview.webrtc.org/1993113003.

I will try to understand what have happened.

If I understand this correctly, ramp up times are unaffected and also the total number of packets are unaffected. 
What have changed in the number of rtx packets that we sent. I don't understand really how my cl could affect that but considering that the the total number of packets are the same and the ramp up times are the same I think we can wait until stefan come back and can maybe take a look?  

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Perf sheriff ping.

Sorry, I assigned the wrong Stefan. 

We definitely seem to be sending less padding in these tests now. I can't
really say why, which worries me.

Per, could you investigate a bit to see if the padding calculations are any
different when running simulcast? Are we at all sending padding packets
when using simulcast now?

Yes- we send padding and the set max padding bitrate is 1.3Mbit/s. 

See the attached log:
I added logging to where we set the padding limits and where we actually send padding.

Deleted: RampUpTest_AbsSendTimeSimulcastByRedWithRtx.txt 70.2 KB

RampUpTest_AbsSendTimeSimulcastByRedWithRtx.txt 70.2 KB View Download

Might just be a timing issue then. It's a huge difference between your example and the perf bot:
Your example: 
RESULT ramp-up-rtx-total-sent: AbsSendTimeSimulcastByRedWithRtx= 297965 bytes
RESULT ramp-up-rtx-padding-sent: AbsSendTimeSimulcastByRedWithRtx= 15456 bytes

Perf bot: 
Padding on rtx stream went from 224 bytes (a single padding packet) to 0 bytes.
Total on rtx stream went from about 8000 bytes to 3000 bytes.

I think we can conclude that we're sending a bit less on the rtx stream, but ramping up as quickly. I won't investigate it more since it doesn't have any negative side effects and the bugs that come to mind have been investigated.