Implement network performance simulation for remoting perf tests.

Implement network performance simulation for remoting perf tests.

The new FakePacketSocketFactory allows to simulate fake 
network with given latency/bandwidth parameters.

BUG=394067
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=290128

[Sergey Ulanov, 2014-08-12 16:50:16]

Renato: ping

[rmsousa, 2014-08-12 20:42:11]

lgtm

but please fix variance->stddev before submitting.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_netwo...
File remoting/test/fake_network_dispatcher.cc (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_netwo...
remoting/test/fake_network_dispatcher.cc:89: 
nit: extra line break

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
File remoting/test/fake_socket_factory.cc (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:25: variance * sqrt(-2.0 * log(1.0 -
base::RandDouble())) *
This should be named stddev. variance is stddev^2 (that is, it would go inside
the sqrt, above, and would be a terribly inconvenient API, since its unit would
be TimeDelta^2).

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:160: next_port_(1000),
nit: 1024 (if the intention is to emulate unix "high" (non-root) ports).

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:209: next_port_ = (next_port_ == 65535) ?
1000 : next_port_ + 1;
nit: 1024 here as well (probably should define a constant for the high port
boundary)

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:285:
base::Bind(&FakePacketSocketFactory::DoReceivePacket,
This is a bit weird - since delay has a random component, above, one could post
packet1 with 100ms delay, then packet2 with 80ms delay, then we'd dequeue
packet1 at 80ms then packet2 at 100ms (because we always dequeue from the front)

I guess in the end it's probably best this way (otherwise we would get an
out-of-order rate much higher than any realistic network), but it's worth
explaining this behavior in a comment.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
File remoting/test/fake_socket_factory.h (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.h:31: // bundwidth is unlimited.
typo: bandwidth

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.h:108: base::TimeDelta latency_variance_;
fix variance->stddev here as well.

[Sergey Ulanov, 2014-08-16 00:03:35]

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_netwo...
File remoting/test/fake_network_dispatcher.cc (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_netwo...
remoting/test/fake_network_dispatcher.cc:89: 
On 2014/08/12 20:42:10, rmsousa wrote:
> nit: extra line break

Done.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
File remoting/test/fake_socket_factory.cc (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:25: variance * sqrt(-2.0 * log(1.0 -
base::RandDouble())) *
On 2014/08/12 20:42:10, rmsousa wrote:
> This should be named stddev. variance is stddev^2 (that is, it would go inside
> the sqrt, above, and would be a terribly inconvenient API, since its unit
would
> be TimeDelta^2).

Done.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:160: next_port_(1000),
On 2014/08/12 20:42:10, rmsousa wrote:
> nit: 1024 (if the intention is to emulate unix "high" (non-root) ports).

Done.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:209: next_port_ = (next_port_ == 65535) ?
1000 : next_port_ + 1;
On 2014/08/12 20:42:10, rmsousa wrote:
> nit: 1024 here as well (probably should define a constant for the high port
> boundary)

Done.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.cc:285:
base::Bind(&FakePacketSocketFactory::DoReceivePacket,
On 2014/08/12 20:42:10, rmsousa wrote:
> This is a bit weird - since delay has a random component, above, one could
post
> packet1 with 100ms delay, then packet2 with 80ms delay, then we'd dequeue
> packet1 at 80ms then packet2 at 100ms (because we always dequeue from the
front)
> 
> I guess in the end it's probably best this way (otherwise we would get an
> out-of-order rate much higher than any realistic network), but it's worth
> explaining this behavior in a comment.

Yes, that's by design. I actually implemented it without the queue first. That
unintentionally introduced out-of-order delivery which affects PseudoTCP
performance very badly. So I added the queue to decouple out-of-order packets
from latency. Let me know if you have ideas for a cleaner implementation.

Added more comments now.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
File remoting/test/fake_socket_factory.h (right):

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.h:31: // bundwidth is unlimited.
On 2014/08/12 20:42:11, rmsousa wrote:
> typo: bandwidth

Done.

https://codereview.chromium.org/427613005/diff/60001/remoting/test/fake_socke...
remoting/test/fake_socket_factory.h:108: base::TimeDelta latency_variance_;
On 2014/08/12 20:42:11, rmsousa wrote:
> fix variance->stddev here as well.

Done.

[Sergey Ulanov, 2014-08-16 00:03:43]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2014-08-16 00:06:09]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sergeyu@chromium.org/427613005/80001

[Sergey Ulanov, 2014-08-16 00:29:03]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2014-08-16 00:30:38]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sergeyu@chromium.org/427613005/120001

[commit-bot: I haz the power, 2014-08-16 02:25:05]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  android_chromium_gn_compile_rel on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/android_chromiu...)
  win_chromium_rel_swarming on tryserver.chromium.win
(http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Sergey Ulanov, 2014-08-16 02:40:38]

The CQ bit was unchecked by sergeyu@chromium.org

[Sergey Ulanov, 2014-08-16 02:40:38]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2014-08-16 02:40:54]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/sergeyu@chromium.org/427613005/120001

[commit-bot: I haz the power, 2014-08-16 08:12:52]

Committed patchset #4 (120001) as 290128