util.PerformanceCounter: execution beyond window triggers Exception

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Execute the testBenchmark test case on a low-performance machine

What is the expected output? What do you see instead?

When the computation is not completed within the timeout window, perhaps a 
special Exception indicating this could be raised. This is the current result 
of a timeout, it doesn't really tell you what went wrong:

======================================================================
ERROR: testBenchmark (__main__.FilesystemTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_pyrit.py", line 444, in testBenchmark
    self.cli.benchmark(timeout=3)
  File "/build/buildd-pyrit_0.4.0-1-mipsel-8SKhk0/pyrit-0.4.0/build/lib.linux-mips-2.5/pyrit_cli.py", line 1195, in benchmark
    self.tell("\nComputed %.2f PMKs/s total." % perfcounter.avg)
  File "/build/buildd-pyrit_0.4.0-1-mipsel-8SKhk0/pyrit-0.4.0/build/lib.linux-mips-2.5/cpyrit/util.py", line 382, in getAvg
    self.__purge()
  File "/build/buildd-pyrit_0.4.0-1-mipsel-8SKhk0/pyrit-0.4.0/build/lib.linux-mips-2.5/cpyrit/util.py", line 377, in __purge
    if t - self.datapoints[0][0] > self.window:
IndexError: list index out of range

What version of the product are you using? On what operating system?

0.4.0 on Debian; the error so far has occurred only on mipsel and sparc64 
architectures (low-end, performance-wise). The error was not seen in 0.3.0.

Please provide any additional information below.

The error is reproducible. Simply increasing the timeout resolves the issue 
(tested in mipsel qemu instance).

For reference, here is the Debian bug:
http://bugs.debian.org/620991

We would also welcome some guidance regarding the timeout (in testBenchmark): 
is the current timeout=3 a "hard" one, or would it be OK for us to patch our 
version to something higher, to be more tolerant to the slower archs? We're 
aware that pyrit is about number-crunching and it probably does not make much 
sense to run on eg: mipsel, but we would like to support as many arches as 
possible.

Original issue reported on code.google.com by debian.k...@gmail.com on 6 Apr 2011 at 9:38

[GoogleCodeExporter]

thanks for reporting, I'll look into it soon

Original comment by lukas.l...@gmail.com on 7 Apr 2011 at 7:30

• Changed state: Accepted

[GoogleCodeExporter]

It's a stupid bug caused by the PerformanceCounter-class. It will be fixed in 
next upstream-version.

The test "testBenchmark" runs the benchmark for three seconds normally executed 
by the client for sixty seconds. The test triggers a bug in 
PerformanceCounter-class because there are no results after three seconds of 
execution (due to the slow mipsel-system).
You can increase the timeout to e.g. 10 seconds which should fix the situation 
but increase cpu-consumption for running the test. You can also simply patch 
the line

"if t - self.datapoints[0][0] > self.window"

to read

"if len(self.datapoints) > 0 and t - self.datapoints[0][0] > self.window"

Original comment by lukas.l...@gmail.com on 11 Apr 2011 at 7:34

[GoogleCodeExporter]

Makes sense -- I guess we'll just increase the timeout for our build runs then.

Thanks for the quick explanation!

Original comment by debian.k...@gmail.com on 12 Apr 2011 at 9:56