On Sun, Sep 8, 2013 at 10:12 PM, Nick Mathewson nickm@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