IpcSocketFactory pending packet limit is too small

IpcSocketFactory pending packet limit is too small

Refactoring is underway to notify client of P2P socket that network is
congested. In the mean time pending packet limit is too small and causes
huge amount of packet loss, this makes WebRTC unusable.

This is a temporary fix to increase this pre-defined value to 32 pending
packets which accomodates 720p streams up to 5Mb/s.

BUG=228956, 229737
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=193389

[commit-bot: I haz the power, 2013-04-10 01:27:47]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hclam@chromium.org/13992004/1

[Sergey Ulanov, 2013-04-10 01:29:09]

Why is this TBR?

[Alpha Left Google, 2013-04-10 01:30:51]

Sure let's not TBR it. But we need to resolve this problem quickly as there's
regression with webrtc currently.

[Sergey Ulanov, 2013-04-10 01:35:46]

LBTM
I don't see how the numbers in the description are connected. Did you test it
with Ronghua's libjingle change? Also, you need to test it with
SignalReadyToSend hooked up it. Any numbers you get without it will not make
sense.

[Alpha Left Google, 2013-04-10 01:41:50]

Are we going to leave Canary broken? Ronghua's change is not going to land soon
and it requires rolling to Canary as well.

This change is tested with current version of libjingle without the signal for
SignalReadyToSend, which is intend to solve the immediate problem. Justin and
Patrick agreed that they will fine tune these values when Ronghua's change is
rolled to Chrome.

[Sergey Ulanov, 2013-04-10 01:46:48]

Ah, I see. If this is just a short-term solution until Ronghua's change lands,
then LGTM.

On 2013/04/10 01:41:50, Alpha wrote:
> Are we going to leave Canary broken? Ronghua's change is not going to land
soon
> and it requires rolling to Canary as well.
> 
> This change is tested with current version of libjingle without the signal for
> SignalReadyToSend, which is intend to solve the immediate problem. Justin and
> Patrick agreed that they will fine tune these values when Ronghua's change is
> rolled to Chrome.

[commit-bot: I haz the power, 2013-04-10 01:48:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hclam@chromium.org/13992004/1

[Alpha Left Google, 2013-04-10 01:49:12]

Yes this is to unbreak Chrome Canary. :)

Next step is Ronghua's change will land and then adjust this value as well. Next
next step is the pacer Patrick is working on will set a buffer size to Chrome's
p2p socket layer.

[commit-bot: I haz the power, 2013-04-10 04:08:15]

Retried try job too often on linux_chromeos for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-04-10 04:40:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hclam@chromium.org/13992004/1

[commit-bot: I haz the power, 2013-04-10 06:20:31]

Retried try job too often on linux_chromeos for step(s) browser_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_chro...

[commit-bot: I haz the power, 2013-04-10 15:16:22]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/hclam@chromium.org/13992004/1

[Alpha Left Google, 2013-04-10 15:26:39]

Committed patchset #1 manually as r193389 (presubmit successful).