Automatic kvetching about P-1, LL and DC work from GPU72
 

A new feature from GPU72.com ("Not just for GPUs anymore!")...

It is now possible to have your Prime95/mprime clients automatically fetch P-1, LL and DC work from GPU72.com. No longer is it necessary to manually download the work from the web interface.

How this works is I've built a Proxy which "speaks" the Primenet API protocol. All that's needed is to set the following in each client's prime.txt file, under the "[Primenet]" section:

[CODE]ProxyHost=gimps.gpu72.com:80[/CODE]However, before you will be assigned work from GPU72, you need to PM me your Primenet Username -- the name you use to log into Primenet. I don't need, nor want, your associated Password. This knowledge is required by the Primenet API protocol. And, to be explicit, there's nothing I can do with your account knowing your Username.

If you configure the proxy before you send me your Username, communications between your client(s) and Primenet will still work fine, you just won't be assigned work from GPU72 until the system knows your Username. You will instead be assigned work from Primenet through the proxy.

This system is being used by 18 people so far, and it's working fine. If you are not yet a GPU72 user, but want to give this feature a try, please [URL="https://www.gpu72.com/signup/"]Sign Up[/URL] for an account, PM me, and away you go.

For those who are already using GPU72, you'll have noticed some additional columns in the View Assignments and View Completed reports, plus a new "Computers and Notes" page -- this is what that is all about.

Within the next day or so I'll be adding a new page to the system where you can set your Username yourself without needing to PM me. Also, some other new features are planned soon which leverages on this new ability.

Enjoy. :smile:

Quick FAQ...
 

Q1: I already use the Primenet/mprime ProxyHost settings to get through a firewall. Can I still use the GPU72 proxy?

A1: Unfortunately, no. Or at least, not easily.

A1.1: The longer answer... In order to do this your current proxy must have its DNS configured such that v5.mersenne.org resolves to 74.208.185.233 (gimps.gpu72.com) (or CNAMEs to gimps.gpu72.com) instead of what it normally does.


Q2: I do other work types in addition to P-1, LL and DC. Can I still use the proxy?

A2: Yes. The proxy honors the Work Type settings for each CPU. Any requests for Work Types the proxy can't offer are simply passed to Primenet for fulfillment. All updates and results messages simply pass through the proxy to Primenet. ([B]Important: See Q7 and A7 below.[/B])


Q3: I still like to manually fetch work. Can I continue to do so?

A3: Yes. Manual (or worktodo.add) additions to the worktodo.txt file will be handled just the same as if the proxy was not being used. The only real difference is when new work is requested.


Q4: I do some work directly from Primenet, in addition to work from GPU72. Can I continue to do so?

A4: Yes. All Update and Completed messages pass through the proxy to Primenet, so mixing GPU72 and non-GPU72 assignments works fine.


Q5: Do I need to put my GPU72 username and password in the ProxyUser and ProxyPass fields of the Prime95/mprime client?

A5: No. These fields are for proxies which require authentication. The GPU72 proxy doesn't.


Q6: Can I switch back to not using the proxy in the future if I choose to?

A6: For LL and DC assignments, the GPU72 proxy gives you the real Primenet AID, and the assignments will show up in your Primenet Assignment report. So you can switch back to using Primenet directly with no issues.

A6.1: For P-1 assignments it's a little more complicated in that the AID is generated by GPU72, so if you switched back to Primenet directly it wouldn't know about the AIDs and it will complain about an invalid assignment key at the next update. In such cases it's best to either unreserve the P-1 assignments before switching back, or else remove the AIDs from the worktodo.txt file.


Q7: I started using the proxy, but I'm being assigned Double Check work instead of what Prime95/mprime is configured to get. Why?

A7: There appears to be a bug in the Prime95/mprime client such that it doesn't always indicate its work preference before requesting work. The solution is to change the work type (overall if all threads do the same work, or on a per-thread basis if different threads do different work) to something different (like Double Check), manually communicate with the server, then switch the work type back to your preference and manually communicate again. This need only be done once per client.

Thanks chalsall!
:party:

[SIZE=1]Now what we need is GP.... oops, you've done enough already![/SIZE] :smile:

[QUOTE=chalsall;307291]This system is being used by 18 people so far, and it's working fine. [/QUOTE]
Just for confirmation, I am one of the 18 and I am very happy. I still manually fetch the work for some of my computeres, but I had few other which fetched work from PrimeNet automatically, because I wasn't able to run around (inconvenient location of the computers) to give them manual work in time. Now I "proxyed" some of the computers with the inconvenient access through gpu72. They are doing exactly the same type of work (mainly DC) as before, but now i get credit "two times", hehe, on Gimps and on Gpu272 too. :razz:

Agree, everything is working really well and it saves soooo much time! (And it fills the assignemts/results page with a lot more useful information).

@chalsall: A question. Since I use your spider to report results to PrimeNet, what is required to get it to 'talk' to your proxy and what information is required on each line so you know what Computer/GPU and instance reported the results? I know progress won't update, per se, but the completed assignments page will show the details vice just having 'manual'.

Seems like it should be quite easy to make all these changes :ermm:. I know mfakto already supports adding information to the results (though I haven't messed with that function yet).

[QUOTE=flashjh;307431]Seems like it should be quite easy to make all these changes :ermm:. I know mfakto already supports adding information to the results (though I haven't messed with that function yet).[/QUOTE]

The optimal solution is to add the Primenet API communications protocol to mfakt*. That, obviously, is something which is going to take some thought, and co-ordination with George, Scott, Oliver and Bdot (possibly et al).

In the shorter term, I think (don't [B][I][U]know[/U][/I][/B], but am pretty sure) that Primenet will not accept results via its API protocol unless they have the "secret hash" included with each message. The only possible exception to this would be Factor Found results, but even then the user account wouldn't be associated.

A temporary "hack" is to add a parallel channel to my submission spider, such that it talks to both Primenet's manual submission interface (as it does now -- different than the API) and GPU72's new API for each result.

Not difficult, but it's not going to happen this week....

I see... I forgot about the hash.

[QUOTE=chalsall;307434]The optimal solution is to add the Primenet API communications protocol to mfakt*. That, obviously, is something which is going to take some thought, and co-ordination with George, Scott, Oliver and Bdot (possibly et al).

In the shorter term, I think (don't [B][I][U]know[/U][/I][/B], but am pretty sure) that Primenet will not accept results via its API protocol unless they have the "secret hash" included with each message. The only possible exception to this would be Factor Found results, but even then the user account wouldn't be associated.

A temporary "hack" is to add a parallel channel to my submission spider, such that it talks to both Primenet's manual submission interface (as it does now -- different than the API) and GPU72's new API for each result.

Not difficult, but it's not going to happen this week....[/QUOTE]
As I recall, it also required the computer's name and GUID. That part is when I decided that Christenson could take as much time as he needed to automate mfaktc.

[QUOTE=Dubslow;307437]As I recall, it also required the computer's name and GUID. That part is when I decided that Christenson could take as much time as he needed to automate mfaktc.[/QUOTE]

Actually, that part isn't really all that difficult at all. The Computer's name is only used in Update Computer messages. The GUID (what I call CID) is simply a self-generated 32 character MD5 hash.

We are signed up for P-1 work, but we have picked up a few DC assignments.

Even weirder, those DC assignments show up on out GIMPS assignments page. The P-1 work does not.

How do we fix this?

:unsure:

[QUOTE=Xyzzy;307467]
Even weirder, those DC assignments show up on out GIMPS assignments page. The P-1 work does not.[/QUOTE]
That's due to this:
[QUOTE=chalsall;307297]
Q5: Can I switch back to not using the proxy in the future if I choose to?

A5: For LL and DC assignments, the GPU72 proxy gives you the real Primenet AID, and the assignments will show up in your Primenet Assignment report. So you can switch back to using Primenet directly with no issues.

A5.1: For P-1 assignments it's a little more complicated in that the AID is generated by GPU72, so if you switched back to Primenet directly it wouldn't know about the AIDs and it will complain about an invalid assignment key at the next update. In such cases it's best to either unreserve the P-1 assignments before switching back, or else remove the AIDs from the worktodo.txt file.[/QUOTE]
As for this...
[QUOTE=Xyzzy;307467]We are signed up for P-1 work, but we have picked up a few DC assignments.[/quote]
I'm not sure about that.

[QUOTE=Xyzzy;307467]We are signed up for P-1 work, but we have picked up a few DC assignments.[/QUOTE]

Hmmm... Please PM me the computer name(s) involved. I'll go through the logs and see what was communicated and exactly what happened.

The proxy honors work type selections as communicated by the client, but the protocol is such that preferred work type is (supposed to be) sent by the client before requests for work occurs. The default Work Type is DC -- this will soon be settable on a per-user and per-computer basis.

[QUOTE=Xyzzy;307467]Even weirder, those DC assignments show up on out GIMPS assignments page. The P-1 work does not.[/QUOTE]

That's not weird.

LL/DC assignments are "true" Primenet assignments. P-1 assignments are local to GPU72.

[QUOTE=chalsall;307470]The proxy honors work type selections as communicated by the client, but the protocol is such that preferred work type is (supposed to be) sent by the client before requests for work occurs. The default Work Type is DC -- this will soon be settable on a per-user and per-computer basis.[/QUOTE]

OK. Mike has found a bug in my proxy.

I missed the case where the client asks Primenet for what work type should be done for each CPU. I had assumed ("Makes an ASS out of U and ME") that a "Program Options" (PO) message would never be sent by the client requesting the information from Primenet without it first sending a PO message giving the CPU's preference.

Further, if a computer's CPU was known but its work type was 0 ("What makes sense") the proxy didn't then refer to the computer's default work type before falling back to the system-wide default.

Sorry about that. This has now been fixed.

Have I mentioned that software is hard? :wink:

GPU72 now automatically submits all results to James...
 

At the excellent suggestion of Mike (Xyzzy), and with a little bit of work by James and myself, all results which pass through the new GPU72 proxy are now automatically submitted to James' [URL="http://mersenne-aries.sili.net/"]Mersenne-aries stats[/URL] site in real-time.

No longer is it necessary to manually submit the results files for James to know all of the particulars about P-1, DC and LL efforts. This includes the B1, B2 and E values (if used) for P-1 work, even in the case where a factor is found.

All historical traffic which has already passed through the proxy has been submitted, with the time-stamp of when the results were seen.

Thanks to Mike for the suggestion, and to James for building and making available a light-weight API in order for the data submissions to be easy.

Excellent work!

Something fishy here...
 

Grabbed 2 LLs and 4 DCs earlier. Didn't take note of the AIDs for either set.

Regenerated worktodo.txt from my assignments page - oldest assignments first. Dropped the worktodo.txt into Prime95's folder and communicated new end dates to proxy.

Net result as per my assignments page: 4 DCs assigned to correct CPU. 2 LLs still "Manual". Of course, my Prime95 did send ETAs for those 2 LLs as well...

It looks like I'm still getting way too many DC tests regardless of my settings. 2 of my machines are set to "whatever makes sense" so I'd expect occasional DCs but not the 100% I'm seeing. But on 2 others (e.g. Workstation, core 1) it is set to P-1. It's strange, because that system looks to have received a dozen or so P-1 assignments and then got a DC one early this morning (02:xx 8/11/2012).

[QUOTE=ckdo;307643]Net result as per my assignments page: 4 DCs assigned to correct CPU. 2 LLs still "Manual". Of course, my Prime95 did send ETAs for those 2 LLs as well...[/QUOTE]

Thanks for pointing that out -- a SPE on the LL manual assignments page. It wasn't correctly filling out the AID in the Assignment record; the Primenet API protocol never refers to the Exponent, only it's AID, so when your client sent the ETAs to Primenet the Proxy didn't know which candidate to apply the knowledge to.

I set the AIDs to be correct for the two LL assignments, and then re-ran the API messages through the proxy. The assignments were set to the correct CID, and the ETA dates updated.

[QUOTE=kjaget;307652]It looks like I'm still getting way too many DC tests regardless of my settings. 2 of my machines are set to "whatever makes sense" so I'd expect occasional DCs but not the 100% I'm seeing.[/QUOTE]

The system-wide default is DC. So if a machine's default is set to WMS, it will get DCs. Note that if one or more of a machine's CPUs is set to WMS, but the machine itself is set to something else, the CPU will be assigned according to the machine's default.

I *really* need to get the Account Settings page finished, where people will be able to set their own default assignment preference. Hopefully today.

[QUOTE=kjaget;307652]But on 2 others (e.g. Workstation, core 1) it is set to P-1. It's strange, because that system looks to have received a dozen or so P-1 assignments and then got a DC one early this morning (02:xx 8/11/2012).[/QUOTE]

I'll drill down on the API messages sent by that machine, and see what I can see. The work type preference exchanges through the API are a bit tricky. Possibly I've missed something.

But for anyone who's received a DC assignment when they really wanted a P-1, just make sure your machine's default work type is P-1 and then unreserve the DC assignment through the client -- GPU72 and Primenet will both recognize this and it will disappear from your assignments lists at both.

[QUOTE=chalsall;307601]...
No longer is it necessary to manually submit the results files for James to know all of the particulars about P-1, DC and LL efforts. This includes the B1, B2 and [B]E values[/B] (if used) for P-1 work, even in the case where a factor is found.
...
[/QUOTE]
I checked on a few of my P-1 submissions on James' site, the E value still wasn't there. I submitted one manually and then it showed up... don't know if the E value is working?

Everything else seems great though, thanks for the hard work on all this!

I've set up a separate instance of P95-64 with 2 workers, set for manual communication, DC (at the moment), with short days reserved for amount of work. When I want more work for CL, I fire up this setup and tell it to call home. It then downloads 2 DC assignments: one for each worker. I then move these to worktodo for CL.

I'm doing this because I currently don't have a P95 worker running LL or DC on my main instance of the program. Is it possible to have P95 launch without attempting to start processing?

PauseWhileRunning=* along with PauseCheckInterval=1 will only allow 1 second of processing (maximum).

Is there a reason why this is preferable to the manual assignment page?
Edit: Nevermind; you can use the GPU72 proxy this way...

[QUOTE=kladner;307773]Is it possible to have P95 launch without attempting to start processing?[/QUOTE]

Unfortunately, no. While such a command line option exists on *nix, it does not for Windows. (I just checked the source to verify this. Windows accepts the -a (ini file names), -t (torture test) and -w (working dir) options.) You might ask George to include such a switch in the next build. (Edit: While I was sourcing, an alternate solution was posted :smile:)

[QUOTE=flashjh;307770]I checked on a few of my P-1 submissions on James' site, the E value still wasn't there. I submitted one manually and then it showed up... don't know if the E value is working?[/QUOTE]

It should be -- it's being sent. But I just check several submissions over the night, and they didn't have the E value. I've instructed Spidy to re-submit to James all results which had an E value.

James, any ideas?

Jerry, please let us know if you see this again. And rather than submitting the result manually, please just let us know what the exponent(s) involved are.

[QUOTE=sdbardwick;307776]PauseWhileRunning=* along with PauseCheckInterval=1 will only allow 1 second of processing (maximum).
[/QUOTE]

Thanks sdbardwick and Dubslow for giving some thought to the matter. Much appreciated!

[QUOTE=chalsall;307800]It should be -- it's being sent. But I just check several submissions over the night, and they didn't have the E value. I've instructed Spidy to re-submit to James all results which had an E value.

James, any ideas?

Jerry, please let us know if you see this again. And rather than submitting the result manually, please just let us know what the exponent(s) involved are.[/QUOTE]
Ok, the first time I did a random sampling. Tonight I checked everything since the time you manually submitted (~13 Aug 12 / 1429z). Since your manual submission, my E values still don't show up. Also, the exponents with factors don't show b1/b2/e value.

I attached a txt file with all the P-1 exponents I've submitted since just before the time mentioned above. I still have the reuslts files, so I can submit manually, if you need me to.

Some bug reports :

In my assignement report, I see exponents assigned that are not in the worktodo files. For example, M57057041. In prime.log, looks like I got the exponent :

[CODE]Getting assignment from server
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=6bbacb98b1159fd192da1a7e8eeae88e&c=0&ss=31322&sh=03E363A14A10CD622603E5431ABE9C5E
RESPONSE:
pnErrorResult=0
pnErrorDetail=GPU72 assigned P-1 factoring work.
g=6bbacb98b1159fd192da1a7e8eeae88e
k=8d264aee6a9b01dcf37013d8d421c5a0
A=1
b=2
n=57057041
c=-1
w=4
sf=73
saved=2
==END==

PrimeNet success code with additional info:
GPU72 assigned P-1 factoring work.
Got assignment 8d264aee6a9b01dcf37013d8d421c5a0: P-1 M57057041
Sending expected completion date for M57057041: Sep 21 2012
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=6bbacb98b1159fd192da1a7e8eeae88e&k=8d264aee6a9b01dcf37013d8d421c5a0&c=0&p=0.0000&d=86400&e=3757310&ss=30333&sh=2618CB841745D7EB4192B2E3C4FDCDE5
RESPONSE:
pnErrorResult=43
pnErrorDetail=ap: no such assignment key, GUID: 6bbacb98b1159fd192da1a7e8eeae88e, key: 8d264aee6a9b01dcf37013d8d421c5a0
==END==
[/CODE]

Followed by an error when updating completion dates :

[CODE]
Sending expected completion date for M57057041: Sep 21 2012
URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=6bbacb98b1159fd192da1a7e8eeae88e&k=8d264aee6a9b01dcf37013d8d421c5a0&c=0&p=0.0000&d=86400&e=3753270&ss=19912&sh=AC5EA1ACFF0A63C23F67F5935DE8336B
RESPONSE:
pnErrorResult=43
pnErrorDetail=ap: no such assignment key, GUID: 6bbacb98b1159fd192da1a7e8eeae88e, key: 8d264aee6a9b01dcf37013d8d421c5a0
[/CODE]

And that's the last I saw of it on my side, but it's still listed in the GPU272 assignments page. A number of these exponents are there assigned to Workstation rather than Workstation (1) as I'd expect.

Next up, I can get exponents on some but not all of my machines. "Laptop" in particular is not working at all. I see "GPU72_Proxy -- Need Program Options" followed by "Updating computer information on the server", but no actual GPU72 assignments in the logs. And doing a quick unreserve of a high LL or P-1 test gets me that same exponent back rather than a low one from GPU272. Since I get the GPU72 proxy response in some cases I think it's set up correctly (same as the machines which do work) so I'm not sure where to go from here.

Finally, on my other P-1 machine, I get a mix of GPU72 and Primenet P-1 assignments. Looks to be about 50-50 but I don't have exact numbers. I can send logs if you need them.

Sorry dump so much on you, but this has the potential to be a big time saver. Plus the nerd in me has the need to figure out what I've managed to break. Thanks in advance for the help.

[QUOTE=kjaget;308037]Sorry dump so much on you, but this has the potential to be a big time saver. Plus the nerd in me has the need to figure out what I've managed to break. Thanks in advance for the help.[/QUOTE]

Thank you for the very detailed bug report.

Unfortunately I've been a little busy the last few days on "other stuff", so haven't had a chance to drill down on this. But I keep logs of all proxy activity, so with what you've provided it should fairly easy to figure out what's going on. I'll try to take care of this today.

Thanks. I appreciate the hard work on what's really just a hobby for all of us.

Two of my assignments were completed earlier this month but they're still showing up on my assignments page:

[B][URL="http://www.mersenne.org/report_exponent/?exp_lo=58748471"][COLOR=#0066cc]58748471[/COLOR][/URL] & [URL="http://www.mersenne.org/report_exponent/?exp_lo=58750213"][COLOR=#0066cc]58750213[/COLOR][/URL][/B]

Edit: On the Assignments page, can you make the other columns sortable so it's easier to find these guys earlier? Thanks.

[QUOTE=flashjh;308002]Since your manual submission, my E values still don't show up. Also, the exponents with factors don't show b1/b2/e value.[/QUOTE]My first guess is that my primenet spider is noticing these results (without B1/B2/E data) and clobbering the good values already submitted by GPU72. That's an unsubstantiated guess, I haven't actually investigated yet. Would you mind emailing me the affected results.txt to remind me to look into it, please?

[QUOTE=James Heinrich;308701]My first guess is that my primenet spider is noticing these results (without B1/B2/E data) and clobbering the good values already submitted by GPU72. That's an unsubstantiated guess, I haven't actually investigated yet. Would you mind emailing me the affected results.txt to remind me to look into it, please?[/QUOTE]
Email sent, thanks for the help.

[QUOTE=flashjh;308707]Email sent, thanks for the help.[/QUOTE]From what I can see, you've re-submitted these results so my site now shows the correct B1/B2/E values for those exponents. I took a look through the P-1 results parsing functions and it seems to have all the appropriate checks in place to not clobber B1/B2/E with empty values. If you notice that the problem is still happening, please let me know a specific exponent that's affected (and don't manually submit results.txt to overwrite the broken data).

[QUOTE=James Heinrich;308780]If you notice that the problem is still happening, please let me know a specific exponent that's affected (and don't manually submit results.txt to overwrite the broken data).[/QUOTE]

OK, I've just resubmitted all results which had an "E" value to James, so everything should now be fully populated (if it wasn't already).

So everyone knows, the GPU72 system submits to James all results (nominally once) within a minute of them being observed. For P-1-NF results, this is as soon as they pass through the proxy. For P-1-F results this is within twenty minutes (yes, they pass through the proxy, but I don't yet have all the extra code which handles factor-found cases in the proxy code).

So, Jerry -- if you see this again, please report it to James and myself, but don't manually submit the results yourself.

[QUOTE=chalsall;308783]So, Jerry -- if you see this again, please report it to James and myself, but don't manually submit the results yourself.[/QUOTE]
Thought it had been addressed and wasn't working. Sorry for the imaptience :blush:. I'll give it a few days and then I'll check everything. If the E values don't show up, I'll submit the files to you and James.

Did someone change the thread title as a joke?

[QUOTE=bcp19;308939]Did someone change the thread title as a joke?[/QUOTE]
No.

[QUOTE=garo;308949]No.[/QUOTE]

I swear it was.

The thread title [i]was[/i] "fetching" on Aug 20 and Aug 21. It's not now (Aug 22). Whether as a joke or otherwise, I cannot say.

[QUOTE=bcp19;308939]Did someone change the thread title as a joke?[/QUOTE]One of the perks of the unpaid job of admin is the ability to change thread titles.

As James says, whether it was done as a joke, or with some other motivation (such as making it more relevant to thread content -- in the admin's view, that is -- or making some obscure commentary on contemporary life), we cannot know.

Several of my computers have changed their work type to 'what makes sense', on the GPU72 webpage it shows WMS while the client want a specific work type. I noticed this when DC work was assigned to a computer wanting LL work.

[QUOTE=BigBrother;310654]Several of my computers have changed their work type to 'what makes sense', on the GPU72 webpage it shows WMS while the client want a specific work type. I noticed this when DC work was assigned to a computer wanting LL work.[/QUOTE]Checking my account, I see one of three of my computers (all configured to want P-1 work) now says "WMS" (presumably = "Whatever Makes Sense").

In the past week or so, I was changing my P95 setup and adding workers. I missed checking the Work Type setting in the program and ended up getting DC's when I was looking for P-1. When I saw what happened, I changed the local settings and tried again. I think I got one of each that time. I eventually remembered the server side settings and went there.

In any case, I ended up with 3-4 more DCs than I had planned. I did not want to dump them, and can finish them in good time. My only real concern is that having more in the bin makes me more vulnerable to poaching.

Then again, it's only the one I'm actively working on that really concerns me. Except for that one exponent, Chris's warnings on the Assignments page of GPU72 will head off wasted work. :tu::tu:[COLOR=Blue][B]!!![/B][/COLOR]

Do we need to put our gpu72 password and username into the ProxyUser and ProxyPass entries when we change ProxyHost?

[QUOTE=Aramis Wyler;334360]Do we need to put our gpu72 password and username into the ProxyUser and ProxyPass entries when we change ProxyHost?[/QUOTE]

Nope.

And good question -- I'll add that to the FAQ post.

Ok, I can't figure out the work assignment rules.
The default for my PrimeNet account is LL, and all of my AVX capable boxes are set so all threads' worktypes are LL.
GPU72 shows all but one as being set to WMS; I am getting DC assignments.
I wonder what my non-AVX (currently ECM) boxes will get?

Is there some setting I don't know about?

[QUOTE=sdbardwick;337979]Is there some setting I don't know about?[/QUOTE]

Please see Q7 and A7 (which I just added) in the FAQ post above.

This has been talked about before elsewhere, but it should have been there as well.

Apparently you need to either individually set all worker windows to the same worktype or use the "All Workers" setting for the change to be effective. After the change is recorded on GPU72, you can then restore the threads to different worktypes which will be respected for assignments (at least for the LL/DC types I tested).

[QUOTE=sdbardwick;338024]Apparently you need to either individually set all worker windows to the same worktype or use the "All Workers" setting for the change to be effective. After the change is recorded on GPU72, you can then restore the threads to different worktypes which will be respected for assignments (at least for the LL/DC types I tested).[/QUOTE]

OK, thanks for that report.

I'll go through the logs (all Proxy messages are recorded for analysis) and see if there's a bug in my code, or if this is simply the nominal behavior in the API exchanges between Prime95/mprime and Primenet.

Edit: Just saw your edit... It will be the same behavior for all worktypes.

Damn, one really needs to wrangle with the worker settings to get the correct type of work (LL vs. DC), even when GPU72 says LL, and all worker threads are set to LL. I kept getting DCs until I changed workers to different types, communicated, changed types again, communicated, and finally set to same type and communicated.

For reference in the logs look at computers i7-2600K and Jupiter-3570K.
i5-2500k-test logs probably show the quickest resolution: Change a worker to DC, communicate, change the other worker to DC, communicate, use All Workers to change both to LL.

Edt: Forgot to mention that the CPUs with only one worker window behave better, IIRC.

[QUOTE=sdbardwick;338056]Damn, one really needs to wrangle with the worker settings to get the correct type of work (LL vs. DC), even when GPU72 says LL, and all worker threads are set to LL. I kept getting DCs until I changed workers to different types, communicated, changed types again, communicated, and finally set to same type and communicated.[/QUOTE]

Same thing happened to me a few months back when I set up a new laptop. It seemed mysterious until I changed worktypes as you described.

I'm done. Keep getting DCs rather than LL on random machines despite the same machines getting LL assignments previously. This just adds administrative overhead...

I'm almost afraid to mention this and tempt fate, but I think I've finally gotten away from unwanted DC assignments. For the longest time I had been doing a work around on my third P-1 worker: moving assignments from other workers to avoid automatic assignments on #3. A few weeks back I went through a hardware shakeup which included a CPU change from a PhenomII x6 to an FX-8350 x8. That setup has run long enough for a number of automatic fetches through GPU72, and worker 3 has received only P-1's (so far.) :smile:

A minor observation: I noticed that gimps.gpu72.com formats assignment keys differently (uppercase vs lowercase) for GPU72-owned assignments vs passthrough requests. Assignments that GPU72 is interested in are returned in all-lowercase, and requests that are passed through to PrimeNet get all-uppercase assignment keys. For example:[code]Pfactor=bb266817ed297ce1e1fbb1079b0df7__,1,2,61559999,-1,73,2
Pfactor=741879D85394BC94352CE0C5EA0E50__,1,2,80015017,-1,73,2[/code]Not that it really makes any difference, just an observation.

GPU on a Mac
 

Is there anyone running a gpu on a Mac at present at GPU72?

Could do with a hand getting mine set up

Thanks

I have a 4 core cpu which used to fetch P-1 work from gpu72 with all cores for ages. For a while I switched one core to a different work type (one curve ECM-F) and switched back to P-1 immediately after the curve was assigned. Now the curve finished, but THAT CORE is taking P-1 assignments from PrimeNet.

Which is freaky! I reset all the things, work type, proxy, both on my computer and PrimeNet, I even edited all config files by hand, this freaking core continues to get P-1 assignments from PrimeNet directly (which appear in my PrimeNet page, and they are in the 69M), in the same time the other 3 cores are getting assignments from GPU72 (which are on 64M, and do not appear in my PrimeNet assignment list, but they do appear on gpu72).

Very skittish! I am getting nervous. Right now I solved very rudely, exited P95, went to PrimeNet and [U]unreserved all P-1[/U] (in the 69M, except the first which was started already by that core and is at the end of stage1), went to worktodo with a text editor and deleted all assignments for that core (except the first), then [U]moved all the other assignements from all the other cores to this core[/U] then started P95, which got 3 cores worth of P-1 assignments from gpu72 (about 10 for each core, total ~30), and now everything is ok.

Crunching happily...

But it still freaks mo off, I thing one of Chris' minions is drunk... :smile:

[QUOTE=LaurV;361190]But it still freaks mo off, I thing one of Chris' minions is drunk... :smile:[/QUOTE]

Spidy never drinks. His author, on the other hand, sometimes does... :wink:

Can you PM me the name of the machine which did this? I'll drill down on the logs (everything passing through the proxy is logged for reasons like this) and try to figure out what happened.

Is it related to my problem? When changing work types G72 tends to give me work of the 2nd last type changed to. Making 3 changes with the 3rd as the preferred type seems to work. And it seems you need to send end dates with each change.

[QUOTE=petrw1;361193]Is it related to my problem? When changing work types G72 tends to give me work of the 2nd last type changed to. Making 3 changes with the 3rd as the preferred type seems to work. And it seems you need to send end dates with each change.[/QUOTE]

It very well might be.

The communications between Prime95 and Primenet for work-type preferences seems to be a little unstable. When one changes the settings, it seems to help to be very explicit about having Prime95 communicate with Primenet immediately after each change.

When LaurV gives me the machine's name, I can drill down on the logs and see if I've made yet another SPE.

The machine name is "pinch" and the third core is the one with drinking problem. If you look to my assignments report (on GPU72, I would give the link, but it can't be accessed without password, you can do it locally), you can see that all the assignments to pinch are on cores 1, 2, and 4. Nothing on core 3. There are 17 assignments to each core, for a total of 51. In reality, I have here 7 assignments on core 1, 2, 4 (totally 21) and the rest of 30 are (manually moved) on core 3

[edit: this because I made some "[B][U]stock[/U][/B]" by repeating the algorithm described in the post above: "(A) stop p95; (B) add all assignments from core 1, 2,4 to core 3; (C) delete them from cores 1,2,4; (D) restart p95". Every time when I restart, P95 will get new assignments on core 1,2,4 (6 or 7 each) from gpu72, in 64M range. Move them to core 3, repeat. If I do this for core 3 (move its worktodo somewhere else) [U]this drunk core will get assignments in 69M, directly from PrimeNet[/U]. Your proxy is ignoring it. Now, the things are "under control" for the next 10-15 days when the "stock" will be depleted and I would need to do the "algorithm" again... grrrr]

What I did to cause this problem, in case I wasn't very clear in the first post, was changing the work type to ECM-F for 30 seconds, and this was weeks ago, and it was [URL="http://www.mersenneforum.org/showthread.php?p=359080"]related to this problem[/URL] (which by the way, will be fixed with the new web page, for the people who don't know, James is designing a new web page for GIMPS - I don't know if I am allowed to give the link public but I tested it, [U]it looks much MUCH better and it is much faster![/U] you don't need to wait ages when logging in like it is now, the new page will substitute the actual page soon, but please understand that such work is voluntarily done, and people also have real life).

After getting "my 1 curve to test", I switched back to P-1, it didn't took longer than [U]30 seconds[/U] for all the process. The curve ran for a week, is finished, and now the problem described in the other thread is "solved", i.e. I don't appear racing alone and arriving the second :smile: anymore, but after the curve finished, days ago, this core resumed taking P-1 assignments, but started taking them [B][U]from PrimeNet[/U][/B].:shock:

Which I don't like, first because of the range, which is higher and not factored enough, and second because I don't get GPU72 credit for it, I like to see that lines on the graph rising... (otherwise I will never overtake kracker!) :razz:

Down to the last 2 DC assignments.... Spidey... where are you?