[S5R3/R4] How to check Performance when Testing new Apps

To Bikeman's list of frequencies for a work unit, I'd add the numbers shown in col 1 of the 10000-line result zipped result file.

For example, for a result file named:
h1_0905.20_S5R3__423_S5R3b_0_0

Col 1 contains values ranging from:
905.3934422 to
905.4095811

Assuming 2303 distinct, with a nearly uniform step of 0.0000067105 or 0.0000067106 between distinct value, though a few cases of double and still fewer of triple that.

It is tempting to suppose that these are the "real" frequencies for which computation was done for the Work Unit, in which case the range of frequencies would span from about .1934 above that implied by the task name to .2096 above for the specific case cited.

That amount is not constant across all the results I've looked at, though so far they seem pretty similar to this.

Ah, that explains it, thanks!

As to the idea of a reference unit that would perform an all-sky search with a coarse grid in standalone mode, I think this is a very interesting idea.

This could be used for:

-Benchmarking new app-versions
-Benchmarking computers
-As an extreme overclocking-test tool (run until it fails, but avoid submitting error results as the test would run stand-alone and not under BOINC)
-A tool to reproduce errors encountered on a particular platform ...)

The only problem I see currently that would prevent the immediate construction of such a reference test suite is that I know of no easy way to determine the CPU seconds used by a process under Windows. Under Linux and other UNIX like OSes you would just use time, but there is nothing comparable under windows, right?

Maybe a future version of the E@H app should log this itself in stderr.txt before completing the task in standalone mode?

CU

Bikeman

[url=http://msdn2.microsoft.com/en-us/library/ms683223(VS.85).aspx]GetProcessTimes Function[/url]

Says it's good for 2K forward, probably NT4 as well.

Alinator

Yup, that's the one! :-)

The deal with pre-emptive systems ( Windows 3.x was 'co-operative' multitasking ) is that the threads in the outer/lower privilege rings ( non-kernel ie. users ) can't by themselves determine their own timings - simply because they may be interrupted at any moment ( stop/start/sleep/switch .... ). They can refer to system timers to get elapsed ( real ) times from some earlier point, like seconds since system startup, but this doesn't yield summated time spent within a thread. Only a ring zero function can accurately do that by knowing the time per slice as allocated by the task scheduler, adding all the slices up for you, and then handing/serving up a summary via GetProcessTimes say.

One can estimate the actual total time spent by a CPU running one's code by multiplying real-time ( wall clock if you like ) by CPU usage ( a fraction often quoted as a percent ) but you're assuming other system behaviours now. Windows Task Manager ( Processes pane ) will give you this, or even fuller reporting with Process Explorer say : my dual core has two einstein_S5R3_XXXX 's at present, both @ 48 - 50 % each when unmolested, but that's the rub - it's only reliable for long times when undisturbed for those long times. Avoiding this by setting a thread priority to realtime is never a good idea - dependencies within the operating system will scupper this [ and your system ].

Cheers, Mike

The 'co-operative' expectation of Windows 3.x quickly became an utter joke too - the MS recommendation at the time was for third party applications to politely release/yield their own thread to others - like that ever happened, much!! :-)

Cheers, Mike.