[tor-dev] Quickly testing TOR using Chutney and Fluxcapacitor

[Marek Majkowski]

On Sun, Sep 8, 2013 at 10:12 PM, Nick Mathewson <nickm at alum.mit.edu> wrote:
>> $ time /tmp/fluxcapacitor/fluxcapacitor ./go.sh
>>
>> real    0m11.450s
>> user    0m2.340s
>> sys     0m2.120s
>>
>> Running stuff under fluxcapacitor is not deterministic, sometimes it
>> takes 8 seconds, sometimes 15 but it generally works and should go
>> pretty quick.
>
> Thanks, Marek!  This looks quite useful.  Can you talk a bit more
> about under what circumstances (if any) the fluxcapacitor code there
> might give incorrect results?

Depends how you define "incorrect results". In a single-process
scenario fluxcapacitor, of course, will always work correctly and
predictably. When running in multi-process setup (as with Chutney) the
"results" are somewhat dependent on the kernel scheduling order.

In the worst case fluxcapacitor might "speed up" a wrong process and
cause a timeout to fire when it shouldn't. This is caused by kernel
giving CPU to FC rather than a child process that has more immediate
work to do. This is generally a hard problem on busy systems and I'm
still trying to find a right balance between FC speed and stability.
In normal circumstances this problem shouldn't show up, it occurs only
when the host is very busy and there is a heavy deficit of cpu power.

In theory the running time of a script under FC should be a constant -
it should be purely CPU bound. In reality it varies due to
indeterminism of kernel scheduling (and _plenty_ of context switches
and page misses).

Fortunately, as I have shown in the example, it's possible to run
exactly the same testing script with and without FC. If there is a
suspicion FC is malfunctioning, you can always run the tests without
it.

> Also, I had thought the quick-and-dirty chutney test we shipped (via
> ./src/test/test-network.sh)  bootstrapped in faster than 5 minutes.
> Am I wrong there? Does it use any tricks that might be helpful in
> combination with fluxcapacitor?

I was not aware of this script. I'll take a look.

Marek