[RFC] simulating network properties for benchmarks

Carl Friedrich Bolz cfbolz at gmx.de
Fri Jul 21 14:46:28 BST 2006


Martin Pool wrote:
> On 21 Jul 2006, Robert Collins <robertc at robertcollins.net> wrote:
[snip]
>> +class SocketDelay(object):
>> +    """A socket decorator to make TCP appear slower.
>> +
>> +    This changes recv, send, and sendall to add a fixed latency to each
>> +    python call. It will therefore behave differently to the real
underlying
>> +    TCP stack which may only pay the latency price on each actual
roundtrip
>> +    rather than each packet initiated. We can come closer to the real
>> +    behaviour by only charging latency for each roundtrip we detect
- that is
>> +    when recv is called, toggle a flag, and insert latency again
only when
>> +    send has been called in the middle. For now though, showing more
latency
>> +    than we have is probably acceptable.
>> +
>
> It may also help to insert a bandwidth cost proportional to the amount
> of data sent, which will tend to reduce the penalty on small reads or
> writes without complicating things too much.

makes sense, I think.

> We could spend any amount of time (heh) on getting packet-accurate
> delay simulation but I think just sleeping per transmission and per byte
> will be enough.  So let's go with something like this, and tune it later
> if it looks unrepresentative.

If at one point there is the need to evaluate how sensible the results
of the proxy socket are, we can use netem to compare the timings we get
for some various sleeping times/netem settings. If the proxy socket is
somewhat realistic, the results should be similar (quite the physicist's
approach :-) ).

Cheers,

Carl Friedrich




More information about the bazaar mailing list