the jury is still out on whether a fixed system is the better choice over counting flops to alleviate a situation where a wu takes longer.
Einstein does flops counting. The credit claims of Einstein are based on flops counting (as long as you are using Boinc client 5.2.6 and younger). If two results are claiming the same credit they needed the same amount of operations. If one of these results took longer it needed more time to do the same amount of operations.
Thanks Carsten and archae86 for the answers but since on the subject perhaps someone can explain why this has happenned...ie: 2 results consecutively ,same frequency,single core processor both taking about the same time of 72k secs claim 154.98 here and this 1 claims 176.13 here
Now we have taken all(or most)of the variables out discussed in this thread and the run times are all about the same but I have 2 results claiming the lower number and 3 the higher number. Still seems that more tweaking and adjustment needs to be done by project management ...but perhaps someone knows why this is happenning...? Thanks JR
Thanks Carsten and archae86 for the answers but since on the subject perhaps someone can explain why this has happenned...ie: 2 results consecutively ,same frequency,single core processor both taking about the same time of 72k secs claim 154.98 here and this 1 claims 176.13 here
Now we have taken all(or most)of the variables out discussed in this thread and the run times are all about the same but I have 2 results claiming the lower number and 3 the higher number. Still seems that more tweaking and adjustment needs to be done by project management ...but perhaps someone knows why this is happenning...? Thanks JR
JR,
you are talking about h1_0997.5_S5R1__1339_S5R1a_1 and h1_0997.5_S5R1__1243_S5R1a_1.
They use different grid* files and therefore have a different amount of computations.
1339 and 1243 are definitively NOT 'consecutively'.
I altready noticed that the 'credits granted' value changes inside a 'frequency file'.
Thanks Udo that explains it nicely.....my consecutive comment was misleading as it was the next result to run and complete on this host but NOT a consecutive result projectwise...I stand corrected...but they still took about the same amount of time so why the difference in credit? Thanks JR
hmmm[edit]This situation of 10-20% difference in credit in datasets might cause "credit hunting" where users dump a low scoring dataset,reset the project and try for a "higher scoring" dataset not unlike those that used to dump results in S4 that scored to low due to using an optimized app but not an optimized client claiming 8 credits when most results claimed in the 30s. If they can tweak this better it might prevent a lot of that [edit]
As a test, you can probably increase your chances of getting consecutive WUs (h1_xxxx.x_S5R1__1111_S5R1a_1 and h1_xxxx.x_S5R1__1110_S5R1a_1) by increasing your work cache to a larger number.
With a smaller cache, the scheduler sends you work infrequently, this means that an other host was probably sent the WU preceding the one you just crunched.
With a higher cache the scheduler is more likely to send multiple WUs at a time, and it only makes sense to send WUs with consecutive numbers. As soon as you see 'back-to-back' WUs in your cache, you can set your cache level to whatever it was before.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
With a higher cache the scheduler is more likely to send multiple WUs at a time, and it only makes sense to send WUs with consecutive numbers. As soon as you see 'back-to-back' WUs in your cache, you can set your cache level to whatever it was before.
I think you'll find this most likely to work on the first fetch after you bump up the cache number. I'd be cautious in bumping it up by more than a few expected WU's worth, especially if you share your PC with other BOINC projects. Some of the clients out there rather seriously mis-estimate how much work to request on bumps.
In stable state, I've seen mine fetch single WU's quite often even with a large cache, though with large caches a disturbing event, such as temporary server downtime, a change in DCF, etc. often leads to groups.
I agree with Dave that in my observation big cache gulps often give sequential results.
the jury is still out on whether a fixed system is the better choice over counting flops to alleviate a situation where a wu takes longer.
Einstein does flops counting. The credit claims of Einstein are based on flops counting (as long as you are using Boinc client 5.2.6 and younger). If two results are claiming the same credit they needed the same amount of operations. If one of these results took longer it needed more time to do the same amount of operations.
Regards,
Carsten
Just a quick clarification...
Einstein S5 does not do FpOps counting in the science app (as is done at SETI). The number of necessary FpOps is determined at the server and passed to the app in the work unit. BOINC core clients 5.2.6 and later use this number in order to provide a credit claim that closely approximates the predetermined credit value. (Core clients earlier than 5.2.6 ignore the FpOps value and claim credit using time*benchmark.) Upon successful validation, the predetermined credit value will be granted regardless of the credit claim. This is true even if both results in the quorum are from pre-5.2.6 core clients and have claimed the wrong amount of credit.
Hi JR, RE: the jury is
)
Hi JR,
Einstein does flops counting. The credit claims of Einstein are based on flops counting (as long as you are using Boinc client 5.2.6 and younger). If two results are claiming the same credit they needed the same amount of operations. If one of these results took longer it needed more time to do the same amount of operations.
Regards,
Carsten
Thanks Carsten and archae86
)
Thanks Carsten and archae86 for the answers but since on the subject perhaps someone can explain why this has happenned...ie: 2 results consecutively ,same frequency,single core processor both taking about the same time of 72k secs claim 154.98 here and this 1 claims 176.13 here
Now we have taken all(or most)of the variables out discussed in this thread and the run times are all about the same but I have 2 results claiming the lower number and 3 the higher number. Still seems that more tweaking and adjustment needs to be done by project management ...but perhaps someone knows why this is happenning...? Thanks JR
RE: Thanks Carsten and
)
JR,
you are talking about h1_0997.5_S5R1__1339_S5R1a_1 and h1_0997.5_S5R1__1243_S5R1a_1.
They use different grid* files and therefore have a different amount of computations.
1339 and 1243 are definitively NOT 'consecutively'.
I altready noticed that the 'credits granted' value changes inside a 'frequency file'.
Udo
Thanks Udo that explains it
)
Thanks Udo that explains it nicely.....my consecutive comment was misleading as it was the next result to run and complete on this host but NOT a consecutive result projectwise...I stand corrected...but they still took about the same amount of time so why the difference in credit? Thanks JR
hmmm[edit]This situation of 10-20% difference in credit in datasets might cause "credit hunting" where users dump a low scoring dataset,reset the project and try for a "higher scoring" dataset not unlike those that used to dump results in S4 that scored to low due to using an optimized app but not an optimized client claiming 8 credits when most results claimed in the 30s. If they can tweak this better it might prevent a lot of that [edit]
As a test, you can probably
)
As a test, you can probably increase your chances of getting consecutive WUs (h1_xxxx.x_S5R1__1111_S5R1a_1 and h1_xxxx.x_S5R1__1110_S5R1a_1) by increasing your work cache to a larger number.
With a smaller cache, the scheduler sends you work infrequently, this means that an other host was probably sent the WU preceding the one you just crunched.
With a higher cache the scheduler is more likely to send multiple WUs at a time, and it only makes sense to send WUs with consecutive numbers. As soon as you see 'back-to-back' WUs in your cache, you can set your cache level to whatever it was before.
There are 10^11 stars in the galaxy. That used to be a huge number. But it's only a hundred billion. It's less than the national deficit! We used to call them astronomical numbers. Now we should call them economical numbers. - Richard Feynman
RE: With a higher cache the
)
I think you'll find this most likely to work on the first fetch after you bump up the cache number. I'd be cautious in bumping it up by more than a few expected WU's worth, especially if you share your PC with other BOINC projects. Some of the clients out there rather seriously mis-estimate how much work to request on bumps.
In stable state, I've seen mine fetch single WU's quite often even with a large cache, though with large caches a disturbing event, such as temporary server downtime, a change in DCF, etc. often leads to groups.
I agree with Dave that in my observation big cache gulps often give sequential results.
RE: Hi JR,RE: the jury is
)
Just a quick clarification...
Einstein S5 does not do FpOps counting in the science app (as is done at SETI). The number of necessary FpOps is determined at the server and passed to the app in the work unit. BOINC core clients 5.2.6 and later use this number in order to provide a credit claim that closely approximates the predetermined credit value. (Core clients earlier than 5.2.6 ignore the FpOps value and claim credit using time*benchmark.) Upon successful validation, the predetermined credit value will be granted regardless of the credit claim. This is true even if both results in the quorum are from pre-5.2.6 core clients and have claimed the wrong amount of credit.
Regards,
-- Tony