Don't bother guys. It doesn't work.

It won't start new cuda tasks, they just sit there with a "waiting to run" status. No good for GPUgrid, but might be okay for cpu-only users.

Don't bother guys. It doesn't work.

It won't start new cuda tasks, they just sit there with a "waiting to run" status. No good for GPUgrid, but might be okay for cpu-only users.

Will be fixed in the next version ;)

Don't bother guys. It doesn't work.

It won't start new cuda tasks, they just sit there with a "waiting to run" status. No good for GPUgrid, but might be okay for cpu-only users.

Changes for 6.6.27

- removed outdated translation files; updated template
- client: view 2 GPUs as equivalent if their memory differs by <30%. (maybe their memory differed slightly from the most capable one)
- client: simplify enforce_schedule(), and maybe fix bugs.
New approach: take the "ordered_schedule_results" list, add running jobs that haven't finished their time slice, and order the result appropriately. Then run jobs in order until CPUs are filled. Simpler and clearer than the old way.

= client: fix compiler warning

=============
I lso noted that the limits on the memory are 1.4 * and 0.7 * the other systems. Sounds to me like a 40% leeway one way and 30% the other. Someone explained that those are something to do with sqquare root of 2 which is all well and good but has nothing to do with the setting of a 30% limit ...

Yes, well, now I am told that 1/0.7 is 1.42 ... which is true ... but when I went to math class I could have sworn that 130% of something was found by multiplying it by 1.3 ...

Are they making fun of you? Telling you how the rules of math have changed since you visited this establishment?

In the change set 17987 there is a new "loose" definition which is 1.4
and .7 of each other. If the definition is 30% should that not be 1.3
and 0.7?

Those numbers are approximations to sqrt(2) and 1/sqrt(2) respectively.

Well, if I read the notes correctly the range was intended to be 30%,

Not sure how the square root of two got in there ...

But the way I read the tolerances it is/ or was based on this code 40%
in one direction and 30% in the other. If that is what is intended
that is fine but then the comment is wrong. Either way, the way *I*
was trained if the comments don't match the code and/or the code does
not match the comment there is an issue. Maintainability if nothing
else ...

1/0.7 is 1.42

Yes, and somehow that is related to the square root of two. Someone
already said that too.

But, being simple minded and all that I sat down with my pocket
calculator and the memory allocation for one of my cards:

That card has:

939,261,952 bytes of RAM

939,261,952 * 1.4 = 1,314,966,732.8
1,314,966,732.8 - 939,261,952 = 375,704,780.8

939,261,952 * 0.7 = 657,483,366.4
939,196,416 - 657,483,366.4 = 281,778,585.6

I don't know clever math like you guys, but what I see is that the
limits are not at all equal.

But if i multiply by 1.3

939,261,952 * 1.3 = 1221040537.6
1221040537.6 - 939,261,952 = 281,778,585.6

Which strangely enough looks like the same as when I multiply by 0.7

If unequal margins are what is desired, fine, then the documentation
should say so.

How about :
939,261,952 * 1.4 * 0.7. the answer is not quite back to the same, but
it is close.

I imagine so, 70% of 140% is close ...

But that is not what we are trying to do...

Try this,

70% of 100 = 70
100 - 70 = 30

100 + 30 = 130
100 * 1.3 = 130

100% minus 30% = 70%
100% plus 30% = 130%

If you want the limit to be 30% plus or minus then you multiply by 1.3
and 0.7
if you want it to be plus 40% and minus 30% then you use the limits
chosen.

But then you cannot say that the limit is plus or minus 30% ...

If our limits are exact, then the numbers will be exact.

Should IsEquivalent( x, y) return the same result as IsEquivalent(y,x)? If
you use .7 and 1.4 they do most of the time, if you use .7 and 1.3, they
don't.

Paul,

For the record...I am on your side as I firmly think that the BOINC developers really don't care for critical input, especially yours which is always worth considering and mostly correct.

That said, in this case, they are correct. The logic that you are using would work if we are dealing with a completely symmetrical system. Proportions (percentages, odds, etc.) are, however, asymmetrical because of differential bounding. One cannot have negative proportions since proportions are bounded by zero, but in the positive direction, the bound is infinity. A simple example can demonstrate how this works:

Assume 512mb of memory. A 30% lower bound would equal 512 multiplied by 0.7 = 358.4. But to get the same bound when starting from 358.4, one cannot multiply by 1.3 (yields about 465), but rather one must multiply by the 1.42 (rounded) figure which will yield the 512 needed.


Scott

For the record...I am on your side as I firmly think that the BOINC developers really don't care for critical input, especially yours which is always worth considering and mostly correct.

That said, in this case, they are correct. The logic that you are using would work if we are dealing with a completely symmetrical system. Proportions (percentages, odds, etc.) are, however, asymmetrical because of differential bounding. One cannot have negative proportions since proportions are bounded by zero, but in the positive direction, the bound is infinity. A simple example can demonstrate how this works:

Assume 512mb of memory. A 30% lower bound would equal 512 multiplied by 0.7 = 358.4. But to get the same bound when starting from 358.4, one cannot multiply by 1.3 (yields about 465), but rather one must multiply by the 1.42 (rounded) figure which will yield the 512 needed.

...But I do see your point, if you swap viewpoints is card 2 within 30% of card 1 and is card 1 in 140% of card 2 ... but that is not supposed to be the question. It is supposed to be is card 2 in plus or minus of card 1 ...

All of this ignores the issues when attempting to use 3 or more cards. If one had three cards such that each has different memory (say 9600GSO's with 384mb, 512mb, and 1GB--the first would have 96 shaders, the other two would have 48 shaders each), the current logic would exclude the 384mb card despite the fact that it is the best cruncher of the three. Even the 2 card scenario could produce equally ridiculous logic (e.g., a 512mb 9800GT being excluded when a 1GB 9800GT is added to the system, etc.).

Basically, (as you and others have stated in various forms previously) this is really just a dumb idea.