GPU to 72 status...

[Bdot]

Originally Posted by chalsall

It's a little convoluted, but it can be done in SQL. For one side of the equation:

select User, if(sum(DCTF) > sum(LLTF), sum(DCTF), sum(LLTF)) ... from Assigned group by User;

And SQL will return NULL in the case of division by zero.

Good to know. I haven't been using if in SQL yet, but maybe it'll be useful some day ...
Given your example, and

Originally Posted by Dubslow

with total CPU and GPU work as lines

it probably should be something like:

select User, (sum(DCTF) + sum(LLTF)) / (sum(P1) + sum(DC) + sum(LL)) as GPU-to-CPU-Ratio from Assigned group by User;

Results will range from 0 to NULL (as I learned ), meaning zero to infinity. But the question remains: What does that tell us?

[Dubslow]

Originally Posted by chalsall

IMHO, unless you can take the raw data I provided to you above from the SQL database (import it into a spreadsheet, or filter it through a RegEx and import it into a two dimensional array) and tell me how this can be used to improve the graphs for everyone, this particular suggestion doesn't make sense to me.

No, after James posted, I've just been interested in the actual raw data, not in changing the site, which is perfectly fine as is. I'm just curious what the ratios are for everybody, or rather what the ratios would be if all CPU work was one line and ditto GPU. I just am curious about the data, not changing the site.

Currently, you have some functions that take (in pseudo code)

var-a = MAX_OF(P1, LL, DC)

and

var-b = MAX_OF(DCTF, LLTF)

and then somehow the site's code chooses the best axis left axis scale based on var-b, and the best right axis scale based on var-a. Say (again in pcode)

lscale = FUNC(var-a); rscale = FUNC(var-b);

where again FUNC takes var-[ab] and chooses the next highest multiple of 100 or whatever the case may be. In my case,

MAX_OF(LLTF,DCTF) == 5380.1917250156 && MAX_OF(P1, DC, LL) ==  217.5624618530

(The second value is my LL work, soon to be surpassed by P-1.) Your FUNC equivalent (however you do it) takes these and turns them into 7500 and 250, in my case, and their quotient is 30.

FUNC(5380.1917250156) == 7500 && FUNC(217.5624618530) == 250 && 7500/250 == 30

As best as I can tell, what Bdot suggested was the same, except before running var-[ab] through FUNC (or whatever equivalent), so he would get 5380.1917250156/217.5624618530 =~ 25.

So in pcode the whole process might be (again pcode with C bias)

for each user do {
           lscale = FUNC( MAX_OF(DCTF, LLTF) );
           rscale = FUNC( MAX_OF(P1, DC, LL) );
           ratio = lscale/rscale;
           printf("%d,", ratio);         // Each ratio value for each user is separated by a comma
}

Of course, the modification that would be necessary to make it more accurate is (see post #400, as quoted by post #401)

for each user do {
           lscale = FUNC( SUM(DCTF, LLTF) );
           rscale = FUNC( SUM(P1, DC, LL) );
           ratio = lscale/rscale;
           printf("%d,", ratio);         // Each ratio value for each user is separated by a comma
}

Thus we get a bunch of comma separated values for each user that describes their particular ratio of GPU to CPU GD. Of course, an even more accurate value would be to skip the FUNC step, which just rounds up the values.

for each user do {
           lscale = ( SUM(DCTF, LLTF) );
           rscale = ( SUM(P1, DC, LL) );
           ratio = lscale/rscale;
           printf("%d,", ratio);         // Each ratio value for each user is separated by a comma
}

(The first block was my initial idea, the second block is the modified idea [after I realized that you'd need to sum the worktypes] and the third block is the modified idea with Bdot's variation, that is, simply a ratio of the total work done, as opposed to a ratio of graph scales. The only reason I considered the graph scales at all is because those are what gave me the original idea.)

Of course, you'd need to translate this to SQL/whatever-can-write-CSVs, but hopefully this is a lot more explicit.

Edit: After cross posting, Bdot has hit the nail on the head, I think. To answer the question: this would be (roughly) the "normalization factor" that was talked about for so long. Or rather, taking a statistical analysis of the collection of ratios for each user might be interesting. (Note: We should probably exclude those who haven't done one or the other of GPU/CPU work.)

[chalsall]

Originally Posted by Dubslow

No, after James posted, I've just been interested in the actual raw data, not in changing the site, which is perfectly fine as is. I'm just curious what the ratios are for everybody, or rather what the ratios would be if all CPU work was one line and ditto GPU. I just am curious about the data, not changing the site.

OK, fair enough. And I expect other requests for raw data. So let me please give you (and everyone) this: Work done by all workers (in real-time) in CSV format.

With a little bit of work in a spreadsheet (or the programming language of your choice) you should be able to answer any question you might have on comparative performance.

Is this what you are after?

[Dubslow]

Excel! Calc!
I'll do it later. Gonna go do some C right now (and my HW shall be posted as soon as I hit this here enter button).

[Dubslow]

Originally Posted by Dubslow

Jeesis, who took a 45M expo to 76 bits?

Well, at least the P-1 will be easy

LOL

[Worker #1 Jan 28 20:51:14] Optimal P-1 factoring of M45143689 using up to 10000MB of memory.
[Worker #1 Jan 28 20:51:14] Assuming no factors below 2^76 and 2 primality tests saved if a factor is found.
[Worker #1 Jan 28 20:51:14] Optimal bounds are B1=315000, B2=5118750
[Worker #1 Jan 28 20:51:14] Chance of finding a factor is an estimated 2%
[Worker #1 Jan 28 20:51:14] Using Core2 type-3 FFT length 2400K, Pass1=640, Pass2=3840

Edit: WHOA, WHOA, WHOA. This expo has already had a test completed, over a year ago.
http://www.mersenne.org/report_expon...&B1=Get+status
Why the hell was it assigned to GPU272? How many others are there? chalsall, is there an easy way for you to check?

[oswald]

Originally Posted by Dubslow

WHOA, WHOA, WHOA. This expo has already had a test completed, over a year ago.
http://www.mersenne.org/report_expon...&B1=Get+status
Why the hell was it assigned to GPU272? How many others are there? chalsall, is there an easy way for you to check?

Is because it was an Unverified LL?

[Dubslow]

All first time LLs are classified as 'Unverified'. Those with error codes are classified as 'Suspect'.

Addendum: Those 'Suspect' tests are immediately re-handed out to LL testers, however, no one has yet been able to figure out why GPU272 has gotten exponents >40M with one test completed, and previously we thought that was only >40M but <45M. This appears to be a counter example to that theory. There is no good hypothesis yet, much less actual answer.

[oswald]

Thanks, I'm afraid I don't know how this part works. Time to read up on it.

[bcp19]

Originally Posted by Dubslow

All first time LLs are classified as 'Unverified'. Those with error codes are classified as 'Suspect'.

Addendum: Those 'Suspect' tests are immediately re-handed out to LL testers, however, no one has yet been able to figure out why GPU272 has gotten exponents >40M with one test completed, and previously we thought that was only >40M but <45M. This appears to be a counter example to that theory. There is no good hypothesis yet, much less actual answer.

Probably because it had no P-1 done?

[chalsall]

Originally Posted by bcp19

Probably because it had no P-1 done?

Yeah... This was a mistake I made a while back trying to get "prefered" assignments. Before I realized my error all of the candidates were already assigned.

The good news is no work is being duplicated, and it was only a few hundred candidates.

[flashjh]

Just noticed that GPU to 72 is now #3 for TF and #4 for P1

#7 overall...

Shouldn't take too long to get #2 for TF from Primenet, #1 on the other hand, maybe a few months.