[QUOTE=chalsall;302514]Stupid human error...

The transition to AnonSpidy for candidates below 45M is done manually. Unfortunately, I transitioned from Spidy to Spidy, instead of to AnonSpidy.

I've done the transition properly, updated the DB, and have PMed you the correct AIDs.[/QUOTE]
Ya know chalsall, you'd halve your workload if it weren't for you.

I guess this is as good a place as any to note that a DC I had in progress was finished by[CODE]25838287No factors below2^69
P-1B1=285000, B2=3633750
Verified LL232B4614879A8803 by "Anthony Lieuallen"
Verified LL232B4614879A8803 by "jg5" on 2012-08-28
AssignedDouble-checking to "ktony" on 2012-08-21
Historyno factor for M25838287 from 2^67 to 2^68 [mfaktc 0.19 barrett76_mul32] by "GIMPS Visualization" on 2012-08-21
Historyno factor for M25838287 from 2^68 to 2^69 [mfaktc 0.19 barrett76_mul32] by "Carsten Kossendey" on 2012-08-21
History232B4614879A88__ by "jg5" on 2012-08-28[/CODE]I'm not sure what motivates someone to poach DCs.:no:

EDIT: My thanks again to chalsall for the refinements on the Assignments page of GPU72. The warning of a completed assignment at least allowed me to cut my losses.

[QUOTE=kladner;309538]I guess this is as good a place as any to note that a DC I had in progress was finished by[CODE]25838287No factors below2^69
P-1B1=285000, B2=3633750
Verified LL232B4614879A8803 by "Anthony Lieuallen"
Verified LL232B4614879A8803 by "jg5" on 2012-08-28
AssignedDouble-checking to "ktony" on 2012-08-21
Historyno factor for M25838287 from 2^67 to 2^68 [mfaktc 0.19 barrett76_mul32] by "GIMPS Visualization" on 2012-08-21
Historyno factor for M25838287 from 2^68 to 2^69 [mfaktc 0.19 barrett76_mul32] by "Carsten Kossendey" on 2012-08-21
History232B4614879A88__ by "jg5" on 2012-08-28[/CODE]I'm not sure what motivates someone to poach DCs.:no:

EDIT: My thanks again to chalsall for the refinements on the Assignments page of GPU72. The warning of a completed assignment at least allowed me to cut my losses.[/QUOTE]
Yes, yours and dozens more in the 24-25M range. He's been busy.

DC count discrepancy
 

368 on the Overall DC workers report
398 on my personal stats page (I.e. When I click on my name on the Overall chart.
The list of completions shows 368.

I checked a few others; some match, some don't including yours, though I have the biggest difference.

Aha! I feel happy others have this problem too :razz: Chalsall has me on ignore list (:smile: methink :whistle:)

[QUOTE=petrw1;314751]368 on the Overall DC workers report
398 on my personal stats page (I.e. When I click on my name on the Overall chart.
The list of completions shows 368.

I checked a few others; some match, some don't including yours, though I have the biggest difference.[/QUOTE]

:bump:

[QUOTE=petrw1;315531]:bump:[/QUOTE]

OK, OK... I'll look into it.

It will be a Stupid Programmer Error.

I am running P95 with three workers, all set for P-1. This worked fine when I had two workers, but now I keep getting DC assignments on the third worker. Since I am minus a GPU right now (RMA), I am not doing any LL or DC work.

This continued accumulation of DCs is troubling. I have not unreserved any, since I don't want them lost to GPU72 (I'm using the proxy to get assignments.) I now have seven of them, and I expect it to be two to three weeks before I can hope to get the other GPU back.

My GIMPS account has two CPUs listed, though they are the same machine. The second instance of P95 is set for DCs as it is only used to get CUDALucas assignments. The primary instance is set for all P-1.

This would not be a problem if I were at full crunching strength. As it is, I would really like for it to stop. Any suggestions would be welcome!

Have you opened the workers configuration and set that worker to P-1?

[QUOTE=flashjh;317299]Have you opened the workers configuration and set that worker to P-1?[/QUOTE]

Yes. On the main instance of P95 all three workers are set to P-1, as they are on PrimeNet. As mentioned, I only fire up the other instance to get CuLu assignments. It is set for DC both locally and on PrimeNet.

[QUOTE=kladner;317301]Yes. On the main instance of P95 all three workers are set to P-1, as they are on PrimeNet. As mentioned, I only fire up the other instance to get CuLu assignments. It is set for DC both locally and on PrimeNet.[/QUOTE]

It's strange you'd get assignments for a worker that isn't doing anything. In your worker windows, how many do you have it set for?

[QUOTE=flashjh;317302]It's strange you'd get assignments for a worker that isn't doing anything. In your worker windows, how many do you have it set for?[/QUOTE]

The main instance (P-1) has three worker threads set accordingly. The "slave" instance has one worker set for DC.

[QUOTE=kladner;317304]The main instance (P-1) has three worker threads set accordingly. The "slave" instance has one worker set for DC.[/QUOTE]
Can you post a screen shot? Is there a reason you can't just not run the DC instance until you want more exponents?

[QUOTE=flashjh;317347]Can you post a screen shot? Is there a reason you can't just not run the DC instance until you want more exponents?[/QUOTE]

I could post a screen shot, on the next occasion. The thing is, I haven't run the "slaved" (DC) instance in over a month. It is the full-time, P-1 [U]3rd worker[/U] which has acquired DC assignments. I most recently moved the DC assignments to my CuLu worktodo, and manually balanced P-1 assignments among the three workers. It will take a day or so to see how things happen next.

(However, those CuLu assignments are going to languish for quite a while.)

I find that if you have two instances on the same CPU but with different work preferences, the Primenet server gets confused sometimes.

[QUOTE=garo;317397]I find that if you have two instances on the same CPU but with different work preferences, the Primenet server gets confused sometimes.[/QUOTE]

It has occurred to me that perhaps I should use a different machine name for the second instance. I can see how that might cause confusion.

I am not sure that even that would work. Prime95/net generates a CPUID for each machine and if ID is the same for both instances they will essentially be the same machine in Prime95's eye. One thing you could do is manually check that those IDs in the prime.txt (or local.txt) file are NOT the same and if they are, delete the ID from one instance file and see if that helps.

ATM, I have followed a suggestion from chalsall, which was to change the work type for the thread which was getting DCs instead of P-1. Specifically, I changed it from P-1 to DC, then had P95 phone home to update the information. I then immediately changed it back to P-1, and forced another update with the server. Since the worktodo sections for each worker were filled and balanced (manually), no assignments were gotten during this exercise.

However, as assignments have completed, a few more have been obtained and they have all been correct P-1s so far. I'm going to observe for a while before I consider anything else.

[QUOTE=kladner;317609]ATM, I have followed a suggestion from chalsall, which was to change the work type for the thread which was getting DCs instead of P-1. Specifically, I changed it from P-1 to DC, then had P95 phone home to update the information. I then immediately changed it back to P-1, and forced another update with the server. Since the worktodo sections for each worker were filled and balanced (manually), no assignments were gotten during this exercise.

However, as assignments have completed, a few more have been obtained and they have all been correct P-1s so far. I'm going to observe for a while before I consider anything else.[/QUOTE]

[OT]
Happy 1000'th post b'day btw!
[/OT]

[QUOTE=kracker;317610][OT]
Happy 1000'th post b'day btw!
[/OT][/QUOTE]

Thanks! I hadn't noticed.

[QUOTE=kladner;317609]ATM, I have followed a suggestion from chalsall, which was to change the work type for the thread which was getting DCs instead of P-1. Specifically, I changed it from P-1 to DC, then had P95 phone home to update the information. I then immediately changed it back to P-1, and forced another update with the server. Since the worktodo sections for each worker were filled and balanced (manually), no assignments were gotten during this exercise.

However, as assignments have completed, a few more have been obtained and they have all been correct P-1s so far. I'm going to observe for a while before I consider anything else.[/QUOTE]

A subsequent assignment run (manual, so I can watch it) turned up another DC on the 3rd worker. Checking the CPU settings on my PrimeNet account showed that the 3rd worker had not switched back to P-1 when I changed the setting in P95. I changed that and am waiting to see what happens with further assignment runs.

I just noticed that the charts for Overall Worker Progress and LLTF progress do not agree as to how many assignments I have out. The Overall line agrees with all the other pages I have checked, such as "View Assignments" and Individual Overall Statistics."

[QUOTE=chalsall;315696]OK, OK... I'll look into it.

It will be a Stupid Programmer Error.[/QUOTE]

Getting worse . . .
Workers Double Check Testing Progress: reports 29 out and 532 done
If I click on me for my personal report is shows 9 out and 600 done.
9 out is correct. I'm not sure what is correct for done.

Could it be related to when or how I unreserve GPU72 assignments? I tend to do that. Lately I either unreserve directly from the client so that the proxy will catch it OR if I have to unreserve from the server I will also unreserve from GPU72. I didn't always do it this way.

[QUOTE=petrw1;323402]Could it be related to when or how I unreserve GPU72 assignments? I tend to do that. Lately I either unreserve directly from the client so that the proxy will catch it OR if I have to unreserve from the server I will also unreserve from GPU72. I didn't always do it this way.[/QUOTE]

Thanks -- that was (part) of the problem. If you unreserved the candidate from the server, but not from GPU72 nor your client, it would set a status code in the Assignment record which some of the other reports didn't recognize. Note that this was only for those using the Proxy. And only you were effected by this.

I'm having to go through about 50 records by hand to reverse out of this mix-up. Everything should be nominal in a few hours.

(The other part had to do with a quick-and-dirty fix I made to one of the back-end scripts to ignore LMH work until a more scaleable solution was implemented. Naturely, it was late and I didn't test it, so for the last couple of days the Workers report was not being updated for DC and LL...)

Further to this...
 

While digging down on the code, I realized that the overall Worker's report was not counting TF and P-1 work as being completed in the case where a factor was found (for the Count columns -- the GHz Days column was).

This has been fixed.

If anyone sees any further inconsistencies, please let me know.

[QUOTE=chalsall;323417]If anyone sees any further inconsistencies, please let me know.[/QUOTE]
I know you will hate me for this :razz:
[URL="http://www.gpu72.com/reports/worker/2423ae6e8f696d5e7d1447de91ca35a6/"]Here[/URL] my DC/LL numbers show an "inconsistency" with [URL="http://www.gpu72.com/reports/workers/dc/"]here[/URL] and [URL="http://www.gpu72.com/reports/workers/ll/"]here[/URL]. There are those 60 GHzDays messed since one year... longer... The overall report is correct. The top lists are wrong (some work appears as LL, but it was pledged as DC, if ye're in doubt, I can look for the discussion at that time, here on the forum). I don't understand why those two (three) reports do not take the data from the same source. In fact, that was the point in time when I stopped being so eager to route all my DC/LL work through gpu72, did not like the "inconsistency" :razz: You know the story...

TF assignments partially poached?
 

Today May 6, and yesterday, when I submitted TF results (for 60M, 71-73) I got a number of Error 40 -Not needed messages. When I checked the exponents, all in question had been taken from 71-72 by [B]rduerr[/B]. I did not take notes yesterday, but today the exponents are[INDENT]60871597
60871411
60871367
60871361
[/INDENT]This is doubly irritating since I'm running only ~1/3 of my usual throughput while a GPU is on medical leave. I am reasonably certain that I was in legitimate possession of the assignments.

[QUOTE=kladner;339472]This is doubly irritating since I'm running only ~1/3 of my usual throughput while a GPU is on medical leave. I am reasonably certain that I was in legitimate possession of the assignments.[/QUOTE]

All I can say is according to GPU72, you were solely assigned these (no reassignment happened), and you got the credit on GPU72 for the work completed.

"Can't we all just get along?" - Rodney King

Thanks, Chris. Not much to be said, really. I was just venting. :sad:

Why do my 4 P-1 assignments not show up in GPU72
 

These 4, which I am almost certain were assigned from GPU72:

[CODE]Hamm 1 62601277 PM1-L
Hamm 1 62601353 PM1-L
Hamm 1 62604397 PM1-L
Hamm 1 62604511 PM1-L [/CODE]

Thx

It gets weirder
 

[QUOTE=petrw1;341310]These 4, which I am almost certain were assigned from GPU72:

[CODE]Hamm 1 62601277 PM1-L
Hamm 1 62601353 PM1-L
Hamm 1 62604397 PM1-L
Hamm 1 62604511 PM1-L [/CODE]

Thx[/QUOTE]

The 4 above are still in PrimeNet but NOT in GPU72
And now I have these 2 that show up in GPU72 but NOT in Primenet.
There they both still show as belonging to GPU Factoring

BUT...on my PC Client they do show up as belonging to me ....
I just did a "Send new end dates..."
All 6 were successfully sent (i.e. none got an error that they weren't mine)

[CODE]Hamm (1) 62155721 LL P-1 74
Hamm (1) 62316607 LL P-1 74 [/CODE]

OK.

I'm not ignoring you; I'm just [I]really[/I] busy with "real work".

The reason for the first four is because the proxy for some reason was not able to satisfy your requests from the GPU72 pool, so it passed the request onto Primenet for fullfillment. When I have a moment I'll add these to GPU72's database so you'll get the credit there.

The second two are probably because the proxy [I]was[/I] able to fulfill the requests. Thus
Primenet doesn't know you have been sub-assigned them.

Will drill down further when I have some cycles.

[QUOTE=petrw1;342198]The 4 above are still in PrimeNet but NOT in GPU72
And now I have these 2 that show up in GPU72 but NOT in Primenet.
There they both still show as belonging to GPU Factoring

BUT...on my PC Client they do show up as belonging to me ....
I just did a "Send new end dates..."
All 6 were successfully sent (i.e. none got an error that they weren't mine)

[CODE]Hamm (1) 62155721 LL P-1 74
Hamm (1) 62316607 LL P-1 74 [/CODE][/QUOTE]

[url]http://xkcd.com/327/[/url]

[QUOTE=LaurV;342236][URL]http://xkcd.com/327/[/URL][/QUOTE]

Heheheh!

Who is this Wayne Beardsley and what does he want with my assignments?
 

At least 5 of my GPU72 LL assignments have been flagged as completed by another user in the last few months .... and in every case it is the same person.

To be fair to him it is possible he had them on a PC; the PC was lost; the assignments were recycled; the PC was resurrected and started them again.

But why always me?
Or are others seeing the same thing?

I'd hate to think that someone with such a fine first name could consider poaching?

:down::down::down::down:

[QUOTE=petrw1;344595]I'd hate to think that someone with such a fine first name could consider poaching?[/QUOTE]

Can you please PM me the assignments in question? I can do some "drill-down" on the historical data. (I could figure them out myself, but it would be quicker if you just tell me; I'm *really* busy at the moment.)

Hey Chris, your proxy got some dysentery too! :razz: (related to the new thread's title). Please check my assignment report, I just got a couple of LL tests which are already done by other people, and reported in the same day I got them, therefore they appear as "poached" in the report (one by Bdot, and one by George Woltman :razz: :razz: no joke, hahaha.... I am fighting giants here...)

I am not going to do DC in this range, if I do DC, i prefer to do it under 50M... So, should I reserve them by myself or you do some magic voodoo? I did not start working on them fortunately, but this would be within today or tomorrow (the previous expos in queue are like 93-98% done).

edit: grrr, 50253187 is the one I got two days ago, already done by Bdot at the time, this i will cancel. For the second, 50803043, that was reported by George on June 11, and I already did 98% of the work... I guess I have to live with a DC report this time... I will take the proxy off till this kind of problems are fixed, and go to PrimeNet directly for getting assignments...

[QUOTE=LaurV;344722]Hey Chris, your proxy got some dysentery too! :razz: (related to the new thread's title). Please check my assignment report, I just got a couple of LL tests which are already done by other people, and reported in the same day I got them, therefore they appear as "poached" in the report (one by Bdot, and one by George Woltman :razz: :razz: no joke, hahaha.... I am fighting giants here...)

I am not going to do DC in this range, if I do DC, i prefer to do it under 50M... So, should I reserve them by myself or you do some magic voodoo? I did not start working on them fortunately, but this would be within today or tomorrow (the previous expos in queue are like 93-98% done).

edit: grrr, 50253187 is the one I got two days ago, already done by Bdot at the time, this i will cancel. For the second, 50803043, that was reported by George on June 11, and I already did 98% of the work... I guess I have to live with a DC report this time... I will take the proxy off till this kind of problems are fixed, and go to PrimeNet directly for getting assignments...[/QUOTE]

This happened to me too...I have had two LL tests assigned by the GPU72 proxy which were turned in as first-time LLs by George before I started on them. I didn't worry about it and just considered them DCs.

[QUOTE=Chuck;344811]This happened to me too...I have had two LL tests assigned by the GPU72 proxy which were turned in as first-time LLs by George before I started on them. I didn't worry about it and just considered them DCs.[/QUOTE]

I have had a few DC's completed by others as well, hilariously doing a triple check... and no, they were not expired.

On 2013-10-01 between 14:55 and 15:00 I reserved 1027 LLTF-to-71 assignments on GPU72. Reporting in the first 642 results, I get the following:

[code]
Processing result: no factor for M68020567 from 2^70 to 2^71 [mfaktc 0.20 barrett76_mul32_gs]
Error code: 40, error text: TF result for M68020567 was not needed
[/code]Turns out said result was reported in by @rduerr, 3 days ago. Also turns out, a list of my assignments taken prior to reporting results lists only 1026 LLTF assignments with exactly the one in question missing.

A few questions here:

- Why is @rduerr processing an assignment that is supposedly mine?
- Is GPU72 handing out assignments to multiple participants, again?
- Why are assignments silently being removed from my account?

Just wondering. :huh:

[QUOTE=ckdo;355912]A few questions here:

- Why is @rduerr processing an assignment that is supposedly mine?
- Is GPU72 handing out assignments to multiple participants, again?
- Why are assignments silently being removed from my account?

Just wondering. :huh:[/QUOTE]

1. I don't know. According to my SQL records you were assigned these to TF from 70 to 71. And, at least for 68020567, you got the credit on GPU72.

2. No.

3. Could you provide examples of assignments silently being removed from your account (public, PM or email is fine)?

I have not done anything with the GPU72 system nor your account which would explain what you are claiming. So either I have a bug I need to deal with (documentation welcome), or something else is going on (documentation welcome).

(Hint: A likely scenario of what you are reporting is that someone's "Poached" you. GPU72, nor PrimeNet, can't stop that.)

(Hint 2: Take less work at a time, less chances of "poaching".)

Look one page back in this thread for a very similar report from yours truly in [URL="http://www.mersenneforum.org/showpost.php?p=339472&postcount=124"]Message 124.[/URL] :kladner: The response from Chris is pretty much the same, too.

As far as 3. is concerned, I cannot provide an actual example. However my assignment count certainly goes down at times without me reporting in any results whatsoever. I didn't get the idea of checking whether I was actually credited, yet.

At times my assignment count will go down less than I expected when reporting results, but in the long run I don't seem to end up with leftover assignments. I have no idea whether someone else is credited for these.

It just happened again yesterday btw:

[code]
Manual testing 40009553 NF 2013-10-19 18:14 0.0 no factor for M40009553 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4942
Manual testing 40008413 NF 2013-10-19 18:14 0.0 no factor for M40008413 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4942
Manual testing 40007659 NF 2013-10-19 18:14 0.0 no factor for M40007659 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40007507 NF 2013-10-19 18:14 0.0 no factor for M40007507 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40007167 NF 2013-10-19 18:14 0.0 no factor for M40007167 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40006961 NF 2013-10-19 18:14 0.0 no factor for M40006961 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40006739 NF 2013-10-19 18:14 0.0 no factor for M40006739 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40006121 NF 2013-10-19 18:14 0.0 no factor for M40006121 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40005871 NF 2013-10-19 18:14 0.0 no factor for M40005871 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4943
Manual testing 40004827 NF 2013-10-19 18:14 0.0 no factor for M40004827 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40003913 NF 2013-10-19 18:14 0.0 no factor for M40003913 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40003819 NF 2013-10-19 18:14 0.0 no factor for M40003819 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40003559 NF 2013-10-19 18:14 0.0 no factor for M40003559 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40003177 NF 2013-10-19 18:14 0.0 no factor for M40003177 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40003027 NF 2013-10-19 18:14 0.0 no factor for M40003027 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40002653 NF 2013-10-19 18:14 0.0 no factor for M40002653 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4944
Manual testing 40001249 NF 2013-10-19 18:14 0.0 no factor for M40001249 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4945
Manual testing 40001057 NF 2013-10-19 18:14 0.0 no factor for M40001057 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4945
Manual testing 40000853 NF 2013-10-19 18:14 0.0 no factor for M40000853 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4945
Manual testing 40000837 NF 2013-10-19 18:14 0.0 no factor for M40000837 from 2^68 to 2^69 [mfaktc 0.20 barrett76_mul32_gs] 1.4945
[/code]All still assigned to me as per GPU72. For any potential bug hunting: These are all the results from the 40M range that I reported. All results from the 47M range were accounted for, it appears.

[QUOTE=ckdo;356842]All still assigned to me as per GPU72. For any potential bug hunting: These are all the results from the 40M range that I reported. All results from the 47M range were accounted for, it appears.[/QUOTE]

Sorry... I might have too many balls up in the air...

When I brought in the 40M range I forgot to tell Spidy to watch it. I manually limit what Spidy watches to lessen the impact on PrimeNet.

My apologies everyone. I try to do my best, but when busy Stupid Humans often make stupid mistakes.

Please keep pointing out the mistakes. I'll do my best to minimize them, and will try to deal with them as they are documented.

On a similar note, I have two stuck assignments that Spidey seems to be blind for.
[URL]http://www.mersenne.org/report_exponent/?exp_lo=30970483[/URL]
[URL]http://www.mersenne.org/report_exponent/?exp_lo=30970501[/URL]

I have done them twice, first when I was assigned them and second when I thought I had missed to run them. :smile:

Three times a charm, but I think I stop after two times and ask for help.

Göran

I have an odd situation.

My worktodo, P95 Status, and PrimeNet say I have 9 DC assignments. GPU72 is holding out at 8 DCs, even after repeated Manual Communication attempts. This may, somehow, be the result of the gyrations I went through to get P95 lined up to do all DC work after having done P-1 for some time. There were many instances of making changes, running Manual Comm., and un-reserving unwanted assignments.

Fortunately, or unfortunately, the missing assignment is about 15% complete. Is there some way to get things reconciled?

EDIT: ".....or am I just j*rking off?"

[QUOTE=kladner;365429]I have an odd situation.[/QUOTE]

PM me the candidate in question, and I'll try to answer.