[RFC] simulating network properties for benchmarks
Carl Friedrich Bolz
cfbolz at gmx.de
Fri Jul 21 15:29:30 BST 2006
Martin Pool wrote:
> On 21 Jul 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
>> Robert Collins wrote:
>>
>>> Heres a prototype of what I was referring to. The decorator in it was
>>> quick-coded, if the future directions I mention in it are to be done, it
>>> would deserve unit tests, as high layer tests could no longer test it at
>>> that point.
>>>
>>> I'm pushing this up to
>>> sftp://bazaar.launchpad.net/~bzr/bzr/test-sftp-latency now.
>> This is the approach seems pretty natural to me. But an interesting
>> alternative would be for the transport to not sleep, but instead, move
>> the clock ahead. That would mean we could simulate slow operations
>> quickly, which would make such tests easier to run.
>>
>> Obviously we can't change the system clock, but we could have the
>> transport update a global variable, and have the bench suite use that
>> for its calculations.
>
> And then basically show it as e.g. "4.2s real time, 123.2s simulated
> IO". It could be nice.
Now that I think of it, this also has the advantage that it is much
easier to test that the proxy socket does the right thing. When using
time.sleep the tests could randomly fail (as the tests in
SFTPLatencyKnob are doing for me from time to time right now) because of
time.sleep taking more or less time than the argument specifies. Whereas
with the simulated times this would always be exact.
>
>> The disadvantage is that lsprof won't understand what's going on-- but
>> does sleep show up in lsprof, or does it measure CPU time?
>
> I'm not sure. I thought it was wall time.
>
Cheers,
Carl Friedrich Bolz
More information about the bazaar
mailing list