All S5 WU of a Freq. Not The Same

Idefix
Idefix
Joined: 21 Mar 05
Posts: 11
Credit: 43,293
RAC: 0

Hi JR, RE: the jury is

Message 41814 in response to message 41812

Hi JR,

Quote:
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

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1,205,159
RAC: 0

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

Udo
Udo
Joined: 19 May 05
Posts: 203
Credit: 8,945,570
RAC: 0

RE: Thanks Carsten and

Message 41816 in response to message 41815

Quote:

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'.

Udo

Jayargh
Jayargh
Joined: 9 Feb 05
Posts: 64
Credit: 1,205,159
RAC: 0

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]

Dave Burbank
Dave Burbank
Joined: 30 Jan 06
Posts: 275
Credit: 1,548,376
RAC: 0

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

archae86
archae86
Joined: 6 Dec 05
Posts: 3,066
Credit: 5,917,996,537
RAC: 3,122,018

RE: With a higher cache the

Message 41819 in response to message 41818

Quote:
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.

Tony DeBari
Tony DeBari
Joined: 29 Apr 05
Posts: 30
Credit: 38,576,823
RAC: 0

RE: Hi JR,RE: the jury is

Message 41820 in response to message 41814

Quote:
Hi JR,
Quote:
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.

Regards,

-- Tony

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.