OFFICIAL "SERVER PROBLEMS" THREAD

[kladner]

Originally Posted by Mark Rose

2 x 580, 2 x 430, 2 x 520, and 1 x 760. The 760 gets stopped when I'm using the machine it's in. The rest do nothing but trial factoring 24 hours a day.

Ay yi yi!

[Mark Rose]

Originally Posted by kladner

Ay yi yi!

I borged a couple of idle machines for the lesser cards. They won't be idle forever though.

One 580 does more a little more than the 430's, 520's, and the 760 combined.

[James Heinrich]

Originally Posted by Mark Rose

It just seems odd that those two expired on the exact day that I submitted factors. I know the manual results submission page has been getting recent work, so perhaps there's a bug in that page.

It's not a coincidence, nor is it really a bug.
GPU72 reserves (for reasons I don't remember at the moment) work as LL even though the intent is to run TF on it. Finding a factor obviates the need to run any LL test so any outstanding LL assignment is flagged as "expired".

It's a quirk of reserving as LL, running TF, then finding a factor.

[Mark Rose]

Originally Posted by James Heinrich

It's not a coincidence, nor is it really a bug.
GPU72 reserves (for reasons I don't remember at the moment) work as LL even though the intent is to run TF on it. Finding a factor obviates the need to run any LL test so any outstanding LL assignment is flagged as "expired".

It's a quirk of reserving as LL, running TF, then finding a factor.

Okay :)

[Prime95]

Originally Posted by Mark Rose

It just seems odd that those two expired on the exact day that I submitted factors. I know the manual results submission page has been getting recent work, so perhaps there's a bug in that page.

The problem is that one user, GPU computing, reserved the exponent and another user reported a result. In that case, the exponent is marked as "expired due to poaching". The reason this was done was so that if the original user got around to report a result, he'd be given CPU credit for his work.

At some point I might revisit the whole expired assignments stuff as it is a bit of a mess. In some cases keeping the expired assignment history has proven useful in tracking down issues.

[LaurV]

Originally Posted by James Heinrich

(for reasons I don't remember at the moment)

The reason is that PrimeNet is not GPU-aware, and for him, TF-ing 3 or 4 bits behind the optimum (CPU TF) limit is considered an immense waste of (CPU LL/DC) time. Therefore one could not (easy) get assignments for TF to so high bits, at LL front, but it was forced to take higher exponents to low bits (65 or so), when requesting TF work (manual or automatic). Because PrimeNet assumes you do this on a CPU. He doesn't know (yet) that the GPU was invented.

I don't know the status now, but since the GPUs are running circles around CPUs at TF jobs, the work around was to reserve those exponents as LL, and do TF for them, then, when TF is finish, report the results and unreserve the LL assignment. This was done to "protect" other people who might reserve them "for real", start and do some LL work for days, then a TF guy finds a factor, and the honest assignee wasted the LL time. Worse, he doesn't know, and he continue to LL a known composite until finish, for weeks.

Before GPU72 was invented, we (the GPU owners) used to do TF without reservation, because it was too much a headache to reserve exponents for TF to high bit levels, and this phenomenon (of wasted LL work by a third person) was common, because there was no way for PrimeNet to know that I was TF-ing one exponent, therefore he assigned that exponent for LL to other users. When I found a factor, those "other users" wasted the time.

If you look in your LL report, at the end of it (you need to select your user name in the box, the link is for all users), you may find a section of exponents for which you did LL or DC, and a factor was found later (I have plenty!). For those exponents, you wasted the CPU time to do LL or DC.

Now, GPU72 (and Misfit) do our life much easier, but the process (of assigning the exponents as LL work) remained. So, GPU72 gets LL assignments, and it gives them to us as TF assignments. When we complete our work and report the results (to PrimeNet), the GPU72 spider detects the reports and unreserves the LL work for those exponents, if they are "properly" TF-ed (otherwise they get reassigned to other TF-ers, until they are TF-ed to the right bit level). So, ideally, there should be no exponent assigned for LL or DC which is not "properly TF-ed". (only if we would have enough TF power... )


When a factor is found, the reservation automagically expires. No harm done. The rest was explained already.

I don't thing is necessary to take any action in this direction.

[chalsall]

Originally Posted by LaurV

...but the process (of assigning the exponents as LL work) remained. So, GPU72 gets LL assignments, and it gives them to us as TF assignments.
[snip]
When a factor is found, the reservation automagically expires. No harm done. The rest was explained already.

I don't thing is necessary to take any action in this direction.

Just for additional clarification...

Originally GPU72 reserved all candidates as LLs, and handed them out for TF'ing as described above. Then I figured out a way to actually get and/or reregister the assignments as true TFs (even though Primenet normally wouldn't allow it), which was the case for about a year or so.

Then the new assignment rules came into effect, and we started running /right/ at the edge for Cat 4s, so a new spider was created which would try to "recover" (read: reclaim) candidates which are sub-optimally TF'ed as they expire (if and when we have the available firepower; it ebs and flows).

So, executive summary: This is not actually a problem.

And I see that most of the candidates you (Mark) linked to are no longer showing the Expired notice. This suggests to me that the Primenet admins / programmers have done something for this "special case"; I don't know if it was a "one off", or a scheduled script.

To the Primenet wizards, 68626783 IS still showing the expiry notice.

So you know, GPU72 mostly reserves candidates as true TFs under the account of "GPU Factoring", but sometimes will oportunistically reserve candidates as either LL _or_ P-1 under the account of "For Research" (aka "wabbit").

Thus, if you have a special script for cleaning up this aboration you should look for both LL and P-1 "poaching" (read: factor found) against the latter account.

[Madpoo]

Originally Posted by chalsall

So you know, GPU72 mostly reserves candidates as true TFs under the account of "GPU Factoring", but sometimes will oportunistically reserve candidates as either LL _or_ P-1 under the account of "For Research" (aka "wabbit").

Thus, if you have a special script for cleaning up this aboration you should look for both LL and P-1 "poaching" (read: factor found) against the latter account.

I'm tossing this idea out for George and James, mostly... but I wonder if there needs to be a new work type added for GPU TF or something.

It might avoid some of this confusion... admittedly, what's in place seems to work but it it seems confusing to me anyway. Not that it matters... I don't get fancy GPU's to work with.

[apocalypse]

I seem to be unable to use the manual_result page to submit my latest round of TF results today, but I had no problem last night. Has anything changed there?

Skimming the source, it looks like the submit button is defined outside the form which should enclose it, but I Am Not A Web Developer.

[James Heinrich]

Originally Posted by apocalypse

I seem to be unable to use the manual_result page...
the submit button is defined outside the form which should enclose it

That is precisely what inadvertently happened in a (supposed-to-be) minor update to the page, and it broke. But it's fixed now.

[apocalypse]

Thanks!