Hi,
Does anyone know, how boinc decides, when to run the benchmark test?
I do not need all details, just a rough idea.
regards
Rasputin42

Every 5 days, since the last benchmark. Newer clients (7.3) do every 5 days, but only after a client restart. If no restart, no benchmarks.

---

We're in the middle of some changes. The theory is

1) On restart, any time the installed version of BOINC has changed (upwards or downwards)
2) On restart, if more than five days since benchmarks were run.

In practice, also

3) Five days after benchmarks were last run, if they weren't run at the start of the current session.

Case (3) is in process of being removed - I think it's gone from the latest alpha builds.

Thanks, Guys.
regards
Rasputin42

What about , if i do a manual benchmark.
Case 3) would interest me.

What about , if i do a manual benchmark.
Case 3) would interest me.

You can do a manual benchmark any time you want.

Case 3) is undefined - it was a bug, and the devs didn't believe it would happen (there's a thread about that someplace here). Feel free to try it out.

http://boinc.berkeley.edu/dev/forum_thread.php?id=8943

So, if i leave boinc running forever(no up/downgrade), it will never do a benchmark, if the last benchmark was less than 5 days, before i started the endless boinc?

So, if i leave boinc running forever(no up/downgrade), it will never do a benchmark, if the last benchmark was less than 5 days, before i started the endless boinc?

No, I don't think that's how it works (worked) - have a read of that old thread, there are some example logs.

I think BOINC would run benchmarks once per session, however long that session was (see my reference to a static variable, not saved and restored between sessions).

If there are more than five days between restarts, BOINC will do that one automatic benchmark at the start of the session.

If you restart BOINC after less than five days, it won't do a benchmark at the start of the new session, but it will do a benchmark on the 5-day anniversary of the previous one, whether the timing is convenient or not (beware long-running jobs which don't checkpoint).

To make sure BOINC doesn't run benchmarks use <skip_cpu_benchmarks> option in Client configuration.

It's listed under command-line options but works in cc_config.xml too.

Thanks,Richard.
The conclusion is, that no matter what, there would never be a period longer than 5 days without a benchmark, unless boinc is not running at the due time.In that case it would do a benchmark at start up.
Is this correctly phrased?

Thanks Josh,
It would just keep whatever benchmark values it had, before it was disabled?

Sorry Juha,
my mistake.

Thanks,Richard.
The conclusion is, that no matter what, there would never be a period longer than 5 days without a benchmark, unless boinc is not running at the due time.In that case it would do a benchmark at start up.
Is this correctly phrased?

No, still not quite what I said. BOINC (the current buggy code, not the alpha) will do a benchmark in every session of five days or longer. It might do it right at the beginning, or it might do it later, but within five days.

If your BOINC sessions last for ten days or longer, the second half (after the benchmark) could well - in fact, will always - be a stretch of longer than five days without a benchmark.

You'll just have to find a way of turning down your "overclock the living daylights out of the system" without restarting BOINC... ;)

I've had it set for ages and the values still look ok so, yes.

Richard,
Do not get upset.
I am just trying to highlight a possible loophole for cheating on credits.
It is nice, that you are checking on other projects threads about this.
regards Rasputin42

Richard,
Do not get upset.
I am just trying to highlight a possible loophole for cheating on credits.
It is nice, that you are checking on other projects threads about this.
regards Rasputin42

LOL - I'm not upset (see the wink) - and I wasn't checking the other projects deliberately, NumberFields just happens to be one that I follow closely anyway.

And your basic premise is quite correct - from what I'm told (by people who have walked the code), benchmarks continue to have a much greater influence than you would expect from a cursory reading of CreditNew.

But I invite you to read the third occurrence of "benchmark" in that document. It would be interesting if you could report, as your experiment continues, whether (and over what time scale) host_app_version.pfc_avg kicks in as described.

Oh, I thought you wanted to disable the benchmarks.

Cheating is almost as easy. Since BOINC is open source just grab the source, hardcode the benchmarks to whatever you want, compile and done.

I guess that's one of the reasons why runtime*benchmarks isn't used (directly) anymore for credits.

edit: Oh right, there's more to the story. I try to keep my knowledge of credits at the level "yes, we have credits".

On an other matter:
Is there a simple explanation, why finished tasks are uploaded, and then need to be reported, speratly?
Why is the successful upload not the same as reporting it?

On an other matter:
Is there a simple explanation, why finished tasks are uploaded, and then need to be reported, speratly?
Why is the successful upload not the same as reporting it?

'Uploading' is a simple file transfer, from one hard disk (yours) to another hard disk (theirs). It's going to take the same length of time whenever you do it, so you might as well get it over and done with quickly.

'Reporting' involves connecting to a database, finding the records for the user and her computer, and updating several fields in them. In days of yore, when servers were expensive and slow, it was found that 'connecting to a database' was computationally expensive, taking - oooooh, milliseconds, at least. By comparison, once the connection is open, database engines are optimised to do the searching and updating quickly.

So, save up the reports for later, and send them all in together. One report, one database connection, but lots of work done during the time it's open. Result - one happy (unstressed) server.

Understood.
Thanks, Richard.