Assignments Completed by Another User
 

On August 3, 2014, I was autoassigned two double checks from PrimeNet, M32295581 and M32295713. Today, I noticed that when I did a query on Active Assignments, these two assignments do not show up. I then queried Exponent Status and it appears that another user completed these assignments on 2014-08-07. Am I misreading something?

Also, when I check the assignments on line in my account, these two assignments do not show up. However, they are still in my worktodo.txt file.

Seeing that these numbers are not in an area where one would think that poaching would be occurring, I wonder what is happening.

Should I abort my double check? If so, how do I do that?

Those are both Category 1 DC assignments:
[quote]
First 1500 assignments
Exponents below 32983430
Assigned to users that promise to complete assignments quickly. Computer must be proven reliable, returned at least 2 results in the last 90 days for each LL worker thread, and "days of work to queue" <= 10
Must be completed in 60 days
Assignments are recycled when assignment is more than 60 days old.[/quote]Your computer should have had 60 days to complete the assignment before it should have been recycled. Did you queue a lot of work (and so failed to meet the "days of work to queue <= 10" criteria) ??

He said he was assigned them on August 3rd, 2014. That's closer to 6 days ago than 60.

Is it possible that the original assignee completed the work just past the deadline?

Went to see if the poacher wasn't me :wink:

It wasn't.

Looking to the status for these exponents, it seems like a PrimeNet blunder, or poaching. The original assignee never completed the assignments (or changed her name/assignment key, both [URL="http://www.mersenne.org/report_exponent/default.php?exp_lo=32295713&exp_hi=&full=1"]assignments[/URL] were [URL="http://www.mersenne.org/report_exponent/default.php?exp_lo=32295581&exp_hi=&full=1"]anonymous[/URL]), and the expiration was not over, that was "old fashion" assignment (December 2013?). The "expiration time" which you see (Aug 7) is the reporting date (when the results were reported, by a third party, or poacher, the exponents were done, so they were automatically "expired"). So, the date you see there is not the expiration day, but the completion day.

@OP: you can continue your assignment, especially if you have done some good part of it, so the work won't be wasted, it will count as TC and you will get your DC credit when reporting.

Thanks for coming here with this. There have been a few minor issues with the relatively newly implemented assignment recycling and distribution rules and feedback like yours is essential to finding and fixing any possible issues.

I don't know how to determine whether an assignment was "recycled" by Primenet. In this case, I am quite sure the assignment was rightfully yours, but the individual who had it before you (and ran out of time to finish it, or gave it up, or whatever) completed it despite it no longer "belonging" to him.

At any rate, nothing wrong was done on your end, so you have nothing to worry about. If it was assigned to you, it was supposed to be yours to do. The triple check is somewhat valuable and you will be credited for finishing it if you decide to do so.

[QUOTE=TheMawn;380200]I don't know how to determine whether an assignment was "recycled" by Primenet. In this case, I am quite sure the assignment was rightfully yours, but the individual who had it before you (and ran out of time to finish it, or gave it up, or whatever) completed it despite it no longer "belonging" to him.[/QUOTE]

Yup, this is what appears to have happened. Not much Primenet can do about such situations.

[CODE]20140223/32290000_32300000.txt: 32295581 D 58 -32 2014-01-22 2013-12-28 2013-12-27 2013-12-27 ANONYMOUS
20140604/32290000_32300000.txt: 32295581 D 0 23 2014-06-27 2014-06-05 2014-06-04 2014-06-04 spradlin compute-0-31
20140613/32290000_32300000.txt: 32295581 D 9 22 2014-07-05 2014-06-14 2014-06-13 2014-06-04 spradlin compute-0-31
20140623/32290000_32300000.txt: 32295581 D 19 30 2014-07-23 2014-06-21 2014-06-20 2014-06-04 spradlin
20140702/32290000_32300000.txt: 32295581 D 28 30 2014-08-01 2014-06-30 2014-06-29 2014-06-04 spradlin
20140717/32290000_32300000.txt: 32295581 D 43 36 2014-08-22 2014-07-17 2014-07-16 2014-06-04 spradlin
20140804/32290000_32300000.txt: 32295581 D 0 19 2014-08-23 2014-08-11 2014-08-04 2014-08-04 linament Micron733

20140202/32290000_32300000.txt: 32295713 D 54 -43 2013-12-21 2013-12-11 2013-12-10 2013-12-10 ANONYMOUS
20140604/32290000_32300000.txt: 32295713 D 0 23 2014-06-27 2014-06-05 2014-06-04 2014-06-04 spradlin compute-0-31
20140613/32290000_32300000.txt: 32295713 D 9 22 2014-07-05 2014-06-14 2014-06-13 2014-06-04 spradlin compute-0-31
20140623/32290000_32300000.txt: 32295713 D 19 30 2014-07-23 2014-06-21 2014-06-20 2014-06-04 spradlin
20140702/32290000_32300000.txt: 32295713 D 28 30 2014-08-01 2014-06-30 2014-06-29 2014-06-04 spradlin
20140717/32290000_32300000.txt: 32295713 D 43 37 2014-08-23 2014-07-17 2014-07-16 2014-06-04 spradlin
20140804/32290000_32300000.txt: 32295713 D 0 19 2014-08-23 2014-08-11 2014-08-04 2014-08-04 linament Micron733[/CODE]

Hmm, I was assigned 32272943 for double check:

2014-07-29 Tha D expired on 2014-08-18

I have no idea why it expired. The machine reported daily about the three dc assignments it had. The machine meets all the criteria for cat 1. The triple check will be checked in in a few hours time.

For the record, on the 12th and 13th of August I completed an extra P-1 job on this exponent and another exponent the machine was doing a DC on. I was using another core of the processor to do that and had added the job by hand to the worktodo file. Nothing went wrong with the other exponent.

The "expiry date" you see there is actually the completion date by user spradlin. See [url]http://mersenne.org/report_exponent/default.php?exp_lo=32272943&exp_hi=32272943&full=1[/url]


I would like to bring the attention of the powers that be to the fact that it also expired for ANONYMOUS at the same time. It was assigned on January 19 2014.

Could spradlin have been an anonymous user at the time of them being assigned the work?

EDIT: Tha got the assigned just a touch over 180 days after ANONYMOUS got it assigned to themself. If ANONYMOUS never started it, it would have been recycled just shortly before being assigned to Tha.

[QUOTE=tha;380929]I have no idea why it expired. The machine reported daily about the three dc assignments it had. The machine meets all the criteria for cat 1. The triple check will be checked in in a few hours time.[/QUOTE]

Something a little strange seems to be going on with the spradlin user, and/or Primenet's recycling rules.

I only spider the overall current status a couple of times a month, but this is what I have:

[CODE]20140315/32270000_32280000.txt: 32272943 D 55 -12 2014-03-03 2014-01-20 2014-01-19 2014-01-19 ANONYMOUS
20140318/32270000_32280000.txt: 32272943 D 58 -15 2014-03-03 2014-01-20 2014-01-19 2014-01-19 ANONYMOUS
20140604/32270000_32280000.txt: 32272943 D 6 15 2014-06-19 2014-06-05 2014-06-04 2014-05-29 spradlin compute-0-35
20140613/32270000_32280000.txt: 32272943 D 15 16 2014-06-29 2014-06-14 2014-06-13 2014-05-29 spradlin compute-0-35
20140623/32270000_32280000.txt: 32272943 D LL, 5.50% 25 20 2014-07-13 2014-06-21 2014-06-20 2014-05-29 spradlin
20140702/32270000_32280000.txt: 32272943 D LL, 10.70% 34 20 2014-07-22 2014-06-30 2014-06-29 2014-05-29 spradlin
20140717/32270000_32280000.txt: 32272943 D LL, 20.80% 49 22 2014-08-08 2014-07-16 2014-07-15 2014-05-29 spradlin
20140804/32270000_32280000.txt: 32272943 D LL, 14.30% 6 19 2014-08-23 2014-08-04 2014-08-03 2014-07-29 Tha Riet-Ubuntu
20140813/32270000_32280000.txt: 32272943 D LL, 55.70% 15 9 2014-08-22 2014-08-13 2014-08-12 2014-07-29 Tha Riet-Ubuntu[/CODE]

[QUOTE=TheMawn;380936]The "expiry date" you see there is actually the completion date by user spradlin. See [url]http://mersenne.org/report_exponent/default.php?exp_lo=32272943&exp_hi=32272943&full=1[/url]


I would like to bring the attention of the powers that be to the fact that it also expired for ANONYMOUS at the same time. It was assigned on January 19 2014.

Could spradlin have been an anonymous user at the time of them being assigned the work?

EDIT: Tha got the assigned just a touch over 180 days after ANONYMOUS got it assigned to themself. If ANONYMOUS never started it, it would have been recycled just shortly before being assigned to Tha.[/QUOTE]

I was familiarizing myself with the DB structure so checked into this a bit as a learning exercise... I'm still not totally familiar with how it's all organized, but I can see this:

- 32295581 was assigned to an anon user on 2013-12-27 and that was actually the last time the client reported anything for that exponent.

- User "spradlin" was assigned the exponent (or started work on it at any rate) on 2014-06-04 @ 1:46 UTC

- User "linament" was assigned the exponent (or started work on it) on 2014-08-04 @ 2:52 UTC

- User "spradlin" checked in a DC result at 2014-08-07 @ 14:10 UTC

- It was expired from that anon user on 2014-08-07 at 14:11 UTC probably because of the check-in from a different user that just happened a minute prior. The expiration reason entered in the database was that it was "expired/poached", because it had been checked in by someone else.

- User "linament" checked in the result at 2014-08-22 @ 2:39 UTC which was actually a triple check.

I don't know more than that as to why "spradlin" started working on it... I think maybe the assignments table where I could see that initial one back in December might not actually be a full history of assignments made by the server itself. It *seems* like it is, but I only ever saw the one assignment listed in there for that first anon user.

There was less than 180 days from that initial assignment and when 'spradlin' first got it. Close... more like 159 days or so.

It just makes it seem like for some reason the system didn't record that the exponent had been checked out to other users. Odd thing is, we have some old IIS logs from the old server going back to the beginning of August, and I didn't see any API activity related to exponent 32295581 until "spradlin" checked it in on Aug 7, and then some web activity a few days later to look up that exponent's status... probably "linament" trying to figure out what happened.

Someone else might have more insight on how a user could get an assignment without it showing up even in the IIS logs, much less an entry in the database. I doubt "linament" did anything wrong, I think something weird just happened along the way.

[QUOTE=Madpoo;381150]Someone else might have more insight on how a user could get an assignment without it showing up even in the IIS logs, much less an entry in the database. I doubt "linament" did anything wrong, I think something weird just happened along the way.[/QUOTE]

Oh, I'll answer my own question now that I thought about it. IIS logs the request URL which would include a check-in for an exponent, but it wouldn't record the server's response that includes an exponent being assigned.

Derp... I knew that, just didn't get my brain up to speed before my last message.

It seems like somehow the server just lost track of some assignments, maybe, or something else I'm just not aware of.

[QUOTE=Madpoo;381153]Oh, I'll answer my own question now that I thought about it. IIS logs the request URL which would include a check-in for an exponent, but it wouldn't record the server's response that includes an exponent being assigned.[/QUOTE]

Grep through the logs for "t=ga". Then subgrep for the CID in question.

[QUOTE=Madpoo;381150]
- 32295581 was assigned to an anon user on 2013-12-27 and that was actually the last time the client reported anything for that exponent.

- User "spradlin" was assigned the exponent (or started work on it at any rate) on 2014-06-04 @ 1:46 UTC

- User "linament" was assigned the exponent (or started work on it) on 2014-08-04 @ 2:52 UTC

- User "spradlin" checked in a DC result at 2014-08-07 @ 14:10 UTC
[/QUOTE]

Looks normal.

Anonymous was assigned under (modified) old rules -- given 6 months to start the assignment and one year to complete it. At 6 months, exponent recycled.

Spradlin assigned under new rules, given 60 days to complete. He failed, assignment recycled.

Linament gets the assignment.

Spradlin, unfortunately completes exponent on day 63.

This kind of thing will be more common under the new assignment rules.

[QUOTE=Prime95;381163]Looks normal.

Anonymous was assigned under (modified) old rules -- given 6 months to start the assignment and one year to complete it. At 6 months, exponent recycled.

Spradlin assigned under new rules, given 60 days to complete. He failed, assignment recycled.

Linament gets the assignment.

Spradlin, unfortunately completes exponent on day 63.

This kind of thing will be more common under the new assignment rules.[/QUOTE]

ANONYMOUS was assigned this exponent in late December, yet it was reassigned in early June. That is less than six months, or am I missing something?

[QUOTE=Prime95;381163]Spradlin assigned under new rules, given 60 days to complete. He failed, assignment recycled.[/QUOTE]

This assumes that this exponent was, in fact, a Cat 1 exponent at the time. It appears to me that the Cat 1/Cat 2 boundary was somewhere between 32.06M and 32.56M at that time. That leads me to think perhaps it (and the other 2 exponents mentioned) was a borderline Cat 2 at the time and should have had 100 days to complete it, rather than only 60. This would at least explain why an apparently not-so-fast machine was processing these DC assignments.

This assignment happens to have been made around the same time I had an assignment that got recycled on me. I believed my exponent was a Cat 2, but it got recycled after 60 days. Several days later George said he thought he fixed the problem, but this is now making me wonder.

[QUOTE=cuBerBruce;381187]This assumes that this exponent was, in fact, a Cat 1 exponent at the time. It appears to me that the Cat 1/Cat 2 boundary was somewhere between 32.06M and 32.56M at that time.[/QUOTE]

On June 3rd, the cat 1 / cat 2 boundary was 32.35M. That makes the spradlin assignment a cat 1.

[QUOTE=NBtarheel_33;381165]ANONYMOUS was assigned this exponent in late December, yet it was reassigned in early June. That is less than six months, or am I missing something?[/QUOTE]

No, my bad. As a grandfathered assignment ANONYMOUS is allowed a year (or more). The only possible explanation is ANONYMOUS' computer did not report in for 60 days.

I have all this year's internet log files on my laptop if you think further investigation is warranted.

[QUOTE=Prime95;381163]Looks normal.

Anonymous was assigned under (modified) old rules -- given 6 months to start the assignment and one year to complete it. At 6 months, exponent recycled.

Spradlin assigned under new rules, given 60 days to complete. He failed, assignment recycled.

Linament gets the assignment.

Spradlin, unfortunately completes exponent on day 63.

This kind of thing will be more common under the new assignment rules.[/QUOTE]

Hi everybody! Just come back after a long "vacation" from GIMPS... Many things had changed...
Minor question: in my cpu page personal page I may see an exponent (M63667837) that is expired few days ago. Recentely I've manually extended it since the job is almost done and manually update from the client the new ECD to the server but the exp above does not compare between my actual assignements yet... Am I wasting time with this job?
Kind regards from Italy
Guido

[QUOTE=guido72;393699]Hi everybody! Just come back after a long "vacation" from GIMPS... Many things had changed...
Minor question: in my cpu page personal page I may see an exponent (M63667837) that is expired few days ago. Recentely I've manually extended it since the job is almost done and manually update from the client the new ECD to the server but the exp above does not compare between my actual assignements yet... Am I wasting time with this job?
Kind regards from Italy
Guido[/QUOTE]

Welcome back...

PrimeNet has no record of your assignment...here:

[url]http://www.mersenne.org/report_exponent/?exp_lo=63667837&exp_hi=[/url]

Once it is expired under the new rules you lose the assignment.
However since no one else seems to have it you could simply assign it again through normal (not Manual) channels.

I know.. The exponent is showed in my cpus list ([url]http://www.mersenne.org/cpus/[/url]) but not in assignements one...
[url]http://www.mersenne.org/report_exponent/?exp_lo=63667837&exp_hi=&full=1[/url]
As you may see it results expired 4 days ago... The client is regularly working on it and the goal is just 4 days far...

[QUOTE=petrw1;393708]Welcome back...
Once it is expired under the new rules you lose the assignment.
However since no one else seems to have it you could simply assign it again through normal (not Manual) channels.[/QUOTE]

That sounds weird... Nothing to say about new rules, but what if a client is regularly communicating with the server telling it: "Hey Buddy, I'm just a bit late, not dead! Wait for me, OK?" ?
Nothin' can ovveride the rules? It does sound silly!
If it is like this, should be more efficient for the whole gimps project that Primenet told immediately the out of scheduling client: "that's it! Do something else, bud!"...

[QUOTE=guido72;393710]That sounds weird... Nothing to say about new rules, but what if a client is regularly communicating with the server telling it: "Hey Buddy, I'm just a bit late, not dead! Wait for me, OK?" ?
Nothin' can ovveride the rules? It does sound silly!
If it is like this, should be more efficient for the whole gimps project that Primenet told immediately the out of scheduling client: "that's it! Do something else, bud!"...[/QUOTE]

All the history and discussion is here
[url]http://www.mersenneforum.org/showthread.php?t=19082[/url]

and here
[url]http://www.mersenneforum.org/showthread.php?t=19081[/url]

"Preferred" Category 1 and 2 assignments have NO leeway. Cat 3 and 4 have some leeway as long as they are making good progress.

[QUOTE=guido72;393710]That sounds weird... Nothing to say about new rules, but what if a client is regularly communicating with the server telling it: "Hey Buddy, I'm just a bit late, not dead! Wait for me, OK?" ?
Nothin' can ovveride the rules? It does sound silly!
If it is like this, should be more efficient for the whole gimps project that Primenet told immediately the out of scheduling client: "that's it! Do something else, bud!"...[/QUOTE]

The idea is that clients unable to complete in time shouldn't get the assignments in the first place. This is problematic when clients slow down for some reason.

I'll have a look, THKS!

[QUOTE=petrw1;393708]Welcome back...
However since no one else seems to have it you could simply assign it again through normal (not Manual) channels.[/QUOTE]
In other words?

How it comes that M63667837 is listed in my personal extension list ([url]http://www.mersenne.org/manual_extension/[/url]) and in my cpus list ([url]http://www.mersenne.org/cpus/)?[/url] I mean: dear Primenet, if M63... is no longer assigned to me, why do you list it with my cpus list and moreover let me extend his expiring date?

[QUOTE=guido72;393716]In other words?[/QUOTE]

Add the line to worktodo.txt

test=63667837,74,1

Humbly: may be rational to think about an integration of the rules.
If (and only if!) I'm honestly and reliably (and you decide if I am) telling you what I'm doing and at what pace, the thresholds should be more flexible... 3.333% of deviation (that's my case: 6 days out of 180) should be manageable... What about implementing some "italian/latin" fuzzy logic? :)

[QUOTE=petrw1;393719]Add the line to worktodo.txt

test=63667837,74,1[/QUOTE]
Why? It is already in my wortodo.txt file....

[QUOTE=guido72;393720]Humbly: may be rational to think about an integration of the rules.
If (and only if!) I'm honestly and reliably (and you decide if I am) telling you what I'm doing and at what pace, the thresholds should be more flexible... 3.333% of deviation (that's my case: 6 days out of 180) should be manageable... What about implementing some "italian/latin" fuzzy logic? :)[/QUOTE]

That's exactly the same thing as arguing for a longer deadline. Which might make more sense, but that's not for me to decide.

[QUOTE=Mark Rose;393723]That's exactly the same thing as arguing for a longer deadline. Which might make more sense, but that's not for me to decide.[/QUOTE]
Hi Mark! thanks for quoting! Did anyone suggest something like this?
[QUOTE=guido72;393718]How it comes that M63667837 is listed in my personal extension list ([URL]http://www.mersenne.org/manual_extension/[/URL]) and in my cpus list ([URL="http://www.mersenne.org/cpus/%29?"]http://www.mersenne.org/cpus/)?[/URL] I mean: dear Primenet, if M63... is no longer assigned to me, why do you list it with my cpus list and moreover let me extend his expiring date?[/QUOTE]
any idea about this apparently self conflicting behavior of Primenet?

[QUOTE=guido72;393721]Why? It is already in my wortodo.txt file....[/QUOTE]

oh ok....then I believe the next time you communicate with the server it will assign it to you (Fingers Crossed)

[QUOTE=petrw1;393725]oh ok....then I believe the next time you communicate with the server it will assign it to you (Fingers Crossed)[/QUOTE]
The problem is not my specific case (after all we're speaking about 150 ghz/d...Even if when I joned the project in late 90s that meant a huge leap forward in top producers list!!) but the efiiciency of GIMPS...

"During February 2014, new [URL="http://www.mersenne.org/thresholds/"]assignment and recycling policies[/URL] were put in place to help GIMPS make steady progress on milestones by detecting assignments that [U][B]are proceeding extremely slowly or not at all."
[/B][/U]
It seems to me we're missing the target... Better: we're getting closer to it but not the "most close"...
What's better than giving some weight to the communications between clients and server? After this you may apply all the rules you prefer...

Anyway: finger crossed! ;-)

[QUOTE=guido72;393710]That sounds weird... Nothing to say about new rules, but what if a client is regularly communicating with the server telling it: "Hey Buddy, I'm just a bit late, not dead! Wait for me, OK?" ?
Nothin' can ovveride the rules? It does sound silly![/quote]
It is not silly, the "wait for me" rule was much abused in the past by guys hoarding exponents. We are still in arguments with the gods that be, to allow extension of the term if a "steady" progress is registered, but there is still difficult to define "steady progress" without leaving (too much) room for the "bad guys" :razz:
[quote]
If it is like this, should be more efficient for the whole gimps project that Primenet told immediately the out of scheduling client: "that's it! Do something else, bud!"...[/QUOTE]
Actually, this [U]is already[/U] as you say, and it was like that in the past. If your assignment key is wrong, the server replies you that the assignment key is wrong. However, your client will not abandon the work if it is started and some time and resources were invested in it. Anyhow the work "is needed", we will have to do DC in the future (and TC in the far future), so your work will be recorded and credit will be given (as DC credit). If you continue your work, and if really is "almost done", then you still can finish before the new assignee, and get "first LL" credit with a high probability. Nothing is lost, we are good as we are. :smile:

Similar thing happened to a number of my machines that I pause during hot months. When the cold weather came, and the machines were powered back on, I discovered that the assignments were given to somebody else.

The reverse thing also happened.

Overall, this is probably not a big deal, and is needed to combat hoarding.

It could become a problem when one of the contested exponents turns up to be a newly discovered Mersenne prime. Maybe we need a legal disclaimer that reservation system is provided for members' convenience and is not a guarantee that the exponent will not be tested by somebody else.

[QUOTE=LaurV;393778]If your assignment key is wrong, ...[/QUOTE]

And if the assignment is still not assigned to anyone else just delete the assignment key in worktodo.txt and you will get a new valid one.

[QUOTE=LaurV;393778]It is not silly, the "wait for me" rule was much abused in the past by guys hoarding exponents. We are still in arguments with the gods that be, to allow extension of the term if a "steady" progress is registered, but there is still difficult to define "steady progress" without leaving (too much) room for the "bad guys" :razz:

Actually, this [U]is already[/U] as you say, and it was like that in the past. If your assignment key is wrong, the server replies you that the assignment key is wrong. However, your client will not abandon the work if it is started and some time and resources were invested in it. Anyhow the work "is needed", we will have to do DC in the future (and TC in the far future), so your work will be recorded and credit will be given (as DC credit). If you continue your work, and if really is "almost done", then you still can finish before the new assignee, and get "first LL" credit with a high probability. Nothing is lost, we are good as we are. :smile:[/QUOTE]

I really need an "italian-romulan interpreter"... I'm not concerned about grace, goodness or whatelse about credits and I do am about bad guys and a faster advancement of GIMPS project. I know that no job will get lost too. I'm just saying: you, Primenet, are informed about what I'm doing and at what pace and you may decide if I'm fair, good, reliable etc enough. Why don't you use these infos? And this approach is far from arguing for longer deadlines...

[QUOTE=petrw1;393785]And if the assignment is still not assigned to anyone else just delete the assignment key in worktodo.txt and you will get a new valid one.[/QUOTE]
Been there, done it... Do not bought the T-Shirt... Nothing changed, as far as I understand...
What is Primenet error 33: cpu mismatch?

Who stole my cheese?
 

[QUOTE=TObject;393780]... contested exponents turns up to be a newly discovered Mersenne prime. Maybe we need a legal disclaimer that reservation system is provided for members' convenience and is not a guarantee that the exponent will not be tested by somebody else.[/QUOTE]

I didn't spend the time to specifically check, but from old reading, I reckon that it is entirely likely that your concerns of this nature have already been encountered, many times.
I suspect that you'll find that there are no guarantees offered by anybody about anything.
Reserve as you feel comfortable to consume, and enjoy; does that help, at all?

Dammit, I just got "poached". Kinda.
One of my Haswell boxes double checked [URL="http://www.mersenne.org/report_exponent/?exp_lo=33885989&full=1"]M33885989[/URL].
It didn't match the previous result, so it was immediately reassigned for triple checking. As luck would have it, one of my Sandy Bridge boxes picked it up. The SB got over 42% through the triple-check when the exponent was reassigned to For Research (Chris Halsall).
Annoying waste of $0.68

Something is wrong with dates on that exponent... Or maybe not... :)

[QUOTE=sdbardwick;393900]The SB got over 42% through the triple-check when the exponent was reassigned to For Research (Chris Halsall). Annoying waste of $0.68[/QUOTE]

If it helps at all, rechecking is not /suppost/ to be done by the original particiapant. My triple check matched your double check. I didn't intentionall "poach" you; this was entirely under Primenet's control and direction.

Chris, I didn't think you took any action. I'm just irked that (1) the server assigned me my own doublecheck, and (2) revoked the assignment after significant work performed. I'm moderately concerned that it might be using the public name as the basis for that reassignment, given that I have over the years been assigned my own doublechecks (years later) like [URL="http://www.mersenne.org/report_exponent/?exp_lo=33677509&full=1"]here[/URL].
Normally if I notice such assignments I release them back to PrimeNet.

[QUOTE=sdbardwick;394053]Chris, I didn't think you took any action. I'm just irked that (1) the server assigned me my own doublecheck, and (2) revoked the assignment after significant work performed.[/QUOTE]

You have a ligitmate reason for being irked.

I'm also concerned that what has been promised is not actually delivered.

Can you email me the exponent? I'd like to investigate further (if the cable company ever hooks me up to the Internet).

George, I'm happy to help, but I don't know what information you are requesting.
ETA: Sent PM

Who is this NR and why does he keep completing my assignments....
 

I have (make that HAD) about 100 TF 61-62 assignments (officially assigned to me .... NOT manual or N/A assignments) in the 60,000-69,999 range and each day since early March a few more are completed by NR and dropped from my assignment list as Not Required (NR ... how appropriate).

Can I assume this was an honest mistake?

62207 as one example.

[url]http://www.mersenne.org/report_exponent/?exp_lo=62207&exp_hi=62207&full=1[/url]

That was me, I am really sorry. I just wanted to look a little bit into factoring stuff sitting at the current lowest level. Since mfactc can't handle stuff below 100k I started there. Because [URL="http://www.mersenne.org/primenet/"]this link[/URL] doesn't tell anything about TF in that range I didn't look it up elsewhere.

Do you want me to send you some more results by the work you lost by that? If you are concerned about your credit.
I stopped working there, you can just continue on.

[QUOTE=manfred4;397301]That was me, I am really sorry. I just wanted to look a little bit into factoring stuff sitting at the current lowest level. Since mfactc can't handle stuff below 100k I started there. Because [URL="http://www.mersenne.org/primenet/"]this link[/URL] doesn't tell anything about TF in that range I didn't look it up elsewhere.

Do you want me to send you some more results by the work you lost by that? If you are concerned about your credit.
I stopped working there, you can just continue on.[/QUOTE]

No Problem (haha another NP).

At least in the case of a TF it knows if someone else completes it so when I check in my assignment progress daily PrimeNet simply tells me the work is no longer required and drops it from my worktodo.txt.
So I did NOT lose any credit.

Good point about the link you checked....since PrimeNet has decided all exponents under 20M are factored as deep as necessary it no longer reports any TF assignments in that range (only ECM or P1).

So when I want to see what work is truly free in those low ranges I use this:
[url]http://www.mersenne.org/report_factoring_effort/?exp_lo=20000&exp_hi=99999&bits_lo=1&bits_hi=61&exassigned=1&tftobits=72[/url]
Right now it shows me that there are 3 unassigned...I have no problem if you take those.

[CODE]
84191 61 100000000 2000000000
84391 61 100000000 2000000000
84509 61 100000000 2000000000[/CODE]

... Or any over 99,999. I am not in that range.

[QUOTE=petrw1;397292]I have (make that HAD) about 100 TF 61-62 assignments (officially assigned to me .... NOT manual or N/A assignments) in the 60,000-69,999 range[/QUOTE]

I have been aware of Sid & Andy wharehousing lots of work sub 100000.
Sometimes such assignments have become expired.
At least once in recent days I was aware of NR completing a job that I had reserved.

I noticed another four expired jobs a little while ago, and so reserved 84191, 84391, 84509 and 84592.
That was before I spotted your reference to three of those in a post above.

It would be more coordinated if people working low regions knew how to reserve such work.
Prime95 can register otherwise unassigned jobs queued, but any "N/A," must first be removed from the work unit.
I was exploring this subject in another thread [url]http://www.mersenneforum.org/showthread.php?t=20052;[/url] perhaps you missed it!

[QUOTE=snme2pm1;397344]It would be more coordinated if people working low regions knew how to reserve such work.[/QUOTE]

It often surprises me how often those "on the same page" fight each other.

I totally missed that discussion there, propably because I was busy with my exams. But that is a good way to reserve such work in the future (if I am in that mood of doing so again)

But that one only works for Prime95, mfaktc won't reserve anything if I wanted to. How would you reserve a big bunch of Assignments for your GPU?

Something else: It looks like we could have everything TF'ed up to 2^62 in the near future, if only Prime would let you TF very small Exponents <20.000 - it sais something like "Wrong work type, use ECM instead" and just does not do anything.

[QUOTE=manfred4;397346]I totally missed that discussion there, propably because I was busy with my exams. But that is a good way to reserve such work in the future (if I am in that mood of doing so again)

But that one only works for Prime95, mfaktc won't reserve anything if I wanted to. How would you reserve a big bunch of Assignments for your GPU?

Something else: It looks like we could have everything TF'ed up to 2^62 in the near future, if only Prime would let you TF very small Exponents <20.000 - it sais something like "Wrong work type, use ECM instead" and just does not do anything.[/QUOTE]

I may get chided for mentioning this :) but V24 of PrimeNet allows TF of exponents below 20K....
Apparently a special port of MFAKTC can also...at least one person of this forum has tried it.

Please note that these TFs have snowball's chance in hell of finding any factors. Just sayin' :whistle:

[QUOTE=axn;397364]Please note that these TFs have snowball's chance in hell of finding any factors. Just sayin' :whistle:[/QUOTE]

So if it snows in turkey pretty a pretty good chance lmao :[URL="http://news.discovery.com/history/archaeology/gate-to-hell-found-in-turkey-130329.htm"]Gate to Hell found in Turkey[/URL] okay just joking.

[QUOTE=axn;397364]Please note that these TFs have snowball's chance in hell of finding any factors. Just sayin' :whistle:[/QUOTE]

So, they have a high chance now and less as North America moves into summer?

[IMG]http://media.npr.org/assets/img/2014/01/08/hell082way_wide-d452268a5a1fd0fbc7351a269588579ff078053d-s1600-c85.jpg[/IMG]
[URL]http://www.npr.org/blogs/thetwo-way/2014/01/08/260735693/hell-has-frozen-over-headline-writers-rejoice[/URL]

Assignments "Expired" but still in worktodo.txt
 

The following are a few lines at the top of my current worktodo.txt (there are about 2 dozen in total for this worker; all but the first in the same "boat")
The first is a valid assignment I still see on PrimeNet.
The rest I DO NOT see; in fact they show up as "expired" a few days ago on the Exponent Status report.
I check in every day from that PC so by now it should have recognized and dropped the "expired" assignments.

[CODE][Worker #1]
Factor=BD9B5D9E9B9F087288B7759EC0043C9B,65839,61,62
Factor=CDADEADE888F5B31CF54929461F9073B,62207,61,62
Factor=CE2B0D27C722F9161738D5874ED6B695,62233,61,62[/CODE]

This shows the first assigned to me: [url]http://www.mersenne.org/report_exponent/?exp_lo=65839&exp_hi=&full=1[/url]
This shows the assignment completed on 03/06 and my assignment "expired" that same day [url]http://www.mersenne.org/report_exponent/?exp_lo=62207&exp_hi=&full=1[/url]
Ditto: [url]http://www.mersenne.org/report_exponent/?exp_lo=62233&exp_hi=&full=1[/url]

You do realise those exponents have had the equivalent of a t35 of ECM?

[edit]
Realised a bunch of people mentioned this before.

[QUOTE=VictordeHolland;397576]You do realise those exponents have had the equivalent of a t35 of ECM?[/QUOTE]

Yes I know the near zero change of finding a factor this way....just using "space heater" hardware for a little fun advancing bit levels.

[QUOTE=manfred4;397346]But that one only works for Prime95, mfaktc won't reserve anything if I wanted to. How would you reserve a big bunch of Assignments for your GPU?
[/QUOTE]

Evidently you have now figured that out, without the need for anyone to perhaps be accused of promotion of nefarious techniques.
I don't always reserve work in low ranges, but am more inclined to make that extra effort when there is a heightened risk of collision.
But when I don't reserve during a few hour period of work, in the slight potential conflict areas, that would be because I am at keyboard and would at each hour or two be aware of the results of adjacent workers, and thereby have a good idea where they have been been operating in recent days.
Certainly I would not queue a TF job that was already reserved for TF.

I figured out a workaround to reserve it, propably not the fastest way, but it works.
Usually I don't reserve such work (I am also working 20M-22M 66-67 Bits without reservations), because I can easily see that nobody else is working there recently.
But in the sub-1M-range, where I will be working after that more, there seems to be a bigger potential of clashing Assignments, so I will reserve the work there.

[QUOTE=sdbardwick;394053]Chris, I didn't think you took any action. I'm just irked that (1) the server assigned me my own doublecheck, and (2) revoked the assignment after significant work performed. I'm moderately concerned that it might be using the public name as the basis for that reassignment, given that I have over the years been assigned my own doublechecks (years later) like [URL="http://www.mersenne.org/report_exponent/?exp_lo=33677509&full=1"]here[/URL].
Normally if I notice such assignments I release them back to PrimeNet.[/QUOTE]

FYI, if it makes you feel any better, I'm doing triple-checks of self-verified work and I did notice a few of yours in there (old v4 assignments that were self-checked with your v5 account).

Nothing wrong with that happening...there was just nothing on the server to prevent that situation from arising. :smile:

FYI, these aren't part of the larger list of triple-check candidates I put out... it's a smaller list of just v4/v5 work by the same user which I'm pretty sure were just happy accidents of chance. :) I'm working my way through them now.

[QUOTE=Madpoo;398539]FYI, if it makes you feel any better, I'm doing triple-checks of self-verified work and I did notice a few of yours in there (old v4 assignments that were self-checked with your v5 account).

Nothing wrong with that happening...there was just nothing on the server to prevent that situation from arising. :smile:

FYI, these aren't part of the larger list of triple-check candidates I put out... it's a smaller list of just v4/v5 work by the same user which I'm pretty sure were just happy accidents of chance. :) I'm working my way through them now.[/QUOTE]
Yeah, I saw a couple of those go by...my bad SSD in my Haswell-E caused a bunch of more recent ones too, albeit with double checks. I think an odd collection of edge cases combined to cause them:

0. Account set to get lowest exponents
1. SSD corrupted save files
2. Days of Work set to 1
3. Computer could do about 1.9 per day, and met other low-exponent criteria for reliability and confidence
4. Computer reported mismatched residue due to #1, and immediately requested new work, since it was now below the "days of work" threshold.
5. First available exponent was the one it just turned in, so it was re-assigned.
6. Computer was rarely turned off, so corrupted save files only occasionally used, causing problem to be frustratingly intermittent, as uninterrupted runs returned matching residues.

I doubt I'll get a response in time for my needs, but this seems like the only existing thread for my kind of question. I will have to leave home for a few weeks and I can't take my computer with me and I can't risk leaving it on unattended for the length of time I will be gone. Should I unreserved every exponent that won't finish before I leave? I hate to do that because one will be almost done an hour or 2 before I have to leave, but I won't be able to stay home to let it finish. I'd love for them to e able to just stay with me until I get back, but I am guessing that can't happen.

I'd suggest unassigning the tasks that haven't been started yet.

For the ones that have been started, I'd just finish them when you get back - 2 weeks is not long enough for them to be automatically be unassigned, although you can always get an extension on them by going to "Manual Testing" -> "Extensions" if you are worried about that.

If you're back within 60 days, they shouldn't become unassigned from you unless they are within 60 days of their max time - [url]http://www.mersenne.org/thresholds/[/url] will tell you about assignment rules depending on the category they are in. If you haven't signed up for the quickest exponents, then they will probably be fine. If you are able to access the internet while you are away you can extend the time manually using [url]http://www.mersenne.org/manual_extension/[/url] as well as long as they don't break those threshold rules.

Well, it would be a little over 3 weeks at least that I'll be gone.

[QUOTE=Jwb52z;403759]Well, it would be a little over 3 weeks at least that I'll be gone.[/QUOTE]

I would just keep them....any that are already a few weeks old and NOT started may get unassigned.
Any newer and in progress probably not.

Something for when you get back:

Don't worry about being greedy and holding onto certain assignments even if they're on hold. Of all the numbers less than 1,000,000,000 (the Mersenne exponents that PrimeNet currently cover), about 50,000,000 of them are prime, so there are plenty of tests to go around!

I already had unreserved the 2 that I couldn't start before I leave before I came back to read this thread again. I'll just keep the new ones that it gives me until I get back then. BTW, I only do P-1 work, just so you know if it matters.

[QUOTE=Jwb52z;403767]BTW, I only do P-1 work, just so you know if it matters.[/QUOTE]

Tell your computer to shut it self down after the job is done.

[QUOTE=chalsall;403768]Tell your computer to shut it self down after the job is done.[/QUOTE]

LOL. To come back and see a message on the monitor: “Are you sure you want to shut down now? Abort, Retry, Fail?”

[QUOTE=TObject;403770]LOL. To come back and see a message on the monitor: “Are you sure you want to shut down now? Abort, Retry, Fail?”[/QUOTE]

LOL. Under Linux you don't get that. Under Winblows, I have no idea.

Under Linux, you probably get “Permission denied,” because your [i]sudo[/i] privileges timed out before the job completed, or something. Just kidding...

[QUOTE=TObject;403774]Under Linux, you probably get “Permission denied,” because your [i]sudo[/i] privileges timed out before the job completed, or something. Just kidding...[/QUOTE]

I appreciate the humour, but once you're root, you're root.

I used to teach a course at UVic. I explained that "sudo su -" was a bit like "I have a wish; give me infinite wishes".

Ubuntu has something called "RootSudoTimeout", which is 15 minutes by default.

I am just shooting in the dark; I do not know if it applies to how automatic shutdown on task completion is performed (we could use a master class on that); and I know you need administrator privileges to turn off the computer.

And, to answer my own question, for Ubuntu, here is, apparently, a way to make it not ask for password on shutdown:

[url]http://askubuntu.com/questions/15526/how-to-shut-down-the-computer-after-a-task-has-been-completed[/url]

PM George with your user name. It may help, he can do tricks with your assignments if you really want to keep them.

I am in the same situation, I won't be at the buttons and all the mill will stop during the whole July (1st to 31st). But I am not going to take any action, what will expire will expire. All the LL we can't finish till July 1st, will be finished [U]anyhow[/U] AFTER we will be back, with or without assignment, they will count as DC if we lost the reservation and somebody else LL them before we are back. For the GPU72 work, Chris will kick us out by himself if he gets pissed off with us holding back the progress of the factoring front... :razz: but we never queue more than few hundred exponents, or 1-2 days of work, so in case we lose them and somebody do them in the meantime, then that will be "work in vain" when we come back (i.e. "error 40, no needed"). The effort of unreserving all, etc is too big, and stopping everything (i.e not requesting more work) before we go would also result in some lost (idle) time [U]before[/U] we go, so it does not worth, a day or two may be lost anyhow. As it is, we will close down everything few minutes before we go to the airport, and on August we will turn them back few minutes after we come back, and let P95, cudaLucas, and Misfit deal with the assignments...

[QUOTE=TObject;403782]Ubuntu has something called "RootSudoTimeout", which is 15 minutes by default.[/QUOTE]

That only applies to the sudo command, which temporarily applies root privileges (more accurately, temporarily switches users) to whichever command it's prepended in front of, and *only* that command.

To do any further work as root, you must continue prepending sudo to each and every command.

The slight difference is that if you have successfully entered your sudo password within the last "RootSudoTimeout", further invocations of sudo will not require you to retype the password. However each command is run with full root privileges regardless of that timeout, and the owner of a process cannot change from root to non-root.

So the hypothetical you suggested is unrelated to the timeout you found, and is indeed impossible.

To avoid needing to write sudo before each command, you may run what chalsall wrote -- that (permanently, or rather until changed by the user again) changes the user of the terminal to root (not just the user of any commands run to root).

[QUOTE=LaurV;403802]For the GPU72 work, Chris will kick us out by himself if he gets pissed off with us holding back the progress of the factoring front... :razz: but we never queue more than few hundred exponents, or 1-2 days of work, so in case we lose them and somebody do them in the meantime, then that will be "work in vain" when we come back (i.e. "error 40, no needed").[/QUOTE]

To put on the table, GPU72 no longer automatically unreserves overdue assignments (although the warnings still appear).

I will attempt to contact the assignees to ask of their intentions, and will instruct my systems to unreserve the assignments if no response is received, and/or if they are clearly "Newbies" who ran a few assignment, and then left.

Thanks for clarifying, that is perfect.
As most of my GPU72 assignments are DCTF in 52M to 71 bits, there is not so fat a chance that someone will be needing them done before August 2nd, or 3rd. All good here.

That's odd
 

As shown in the capture, I was a bit over 36% on the DC of 34698809. When P95 checked in this morning, PrimeNet responded, "error 43, Invalid assignment key."

It is not a terribly big deal, but I wonder how it came to pass. :huh:

owftheevil Manual testing 34698809 C 2015-08-25 11:28 1.4 44.8193 565bc8ee116618__

Manual test of that user started yesterday with a valid assignment - did your time run out or did you not have a real assignment for that one?

[QUOTE=kladner;408745]As shown in the capture, I was a bit over 36% on the DC of 34698809. When P95 checked in this morning, PrimeNet responded, "error 43, Invalid assignment key."

It is not a terribly big deal, but I wonder how it came to pass. :huh:[/QUOTE]

Looks like someone checked in the matching DC. When that happens, any assignments are expired since they're no longer needed:
[URL="http://www.mersenne.org/M34698809"]M34698809[/URL]

The result that came in today did have an assignment for it. Was your assignment the one that expired back in May of 2014 but you were still working on it anyway? I'm guessing not since that one hasn't checked in since March of 2014 and was only 0.1% done at that time. :smile:

[QUOTE=manfred4;408772]owftheevil Manual testing 34698809 C 2015-08-25 11:28 1.4 44.8193 565bc8ee116618__

Manual test of that user started yesterday with a valid assignment - did your time run out or did you not have a real assignment for that one?[/QUOTE]

I only get LL/DC assignments through Prime95. I usually have one of each unless an assignment is within four days of completion. A DC typically takes me 20-30 days. Also, there is no record of my assignment having expired. Again, it does not matter that much, but I did check in with it on Aug 23 without incident.

[QUOTE=kladner;408784]I only get LL/DC assignments through Prime95. I usually have one of each unless an assignment is within four days of completion. A DC typically takes me 20-30 days. Also, there is no record of my assignment having expired. Again, it does not matter that much, but I did check in with it on Aug 23 without incident.[/QUOTE]
Using the GPU72 proxy?
Very, very rarely I've had first time tests transformed into DCs without warning via innocent poaching. One of the "poachers" was Prime95 so I assume it was innocent [though you know what they say about assumptions...].

[QUOTE=sdbardwick;408788]Using the GPU72 proxy?[/QUOTE]
Yes, I am.
[QUOTE]Very, very rarely I've had first time tests transformed into DCs without warning via innocent poaching. One of the "poachers" was Prime95 so I assume it was innocent [though you know what they say about assumptions...].[/QUOTE]

I suspect no nefarious deeds. I am just puzzled. This was definitely a DC from the beginning: a 34M. Ah, well. Let it go. :smile:

I wouldn't let it go, this is a bug somewhere in someone's code, which means it could happen again (wasting more cpu time). We (by which I mean not me) should be looking into the root cause and possible fixes for it.

[QUOTE=Dubslow;408793]I wouldn't let it go, this is a bug somewhere in someone's code, which means it could happen again (wasting more cpu time). We (by which I mean not me) should be looking into the root cause and possible fixes for it.[/QUOTE]

OK. Let's get "Down and Dirty". This is what the GPU72 proxy saw with regards to this:

[CODE]mysql> select * from Traffic where Client like "%A3BA119A8F7E3C0F4CB2F4B11C16DCFA%" or Server like "%A3BA119A8F7E3C0F4CB2F4B11C16DCFA%";
+---------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------+---------------------+
| ID | Type | Log | Client | Server | Date | Sent | James |
+---------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------+---------------------+
| 6207082 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=621a95c6678557e6154afcde3cfeae90&c=0&ss=18467&sh=C42C8B775F6AACBDD1533ED7AD3D8585 | pnErrorResult=0
pnErrorDetail=Server assigned Lucas Lehmer primality double-check work.
g=621a95c6678557e6154afcde3cfeae90
k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA
A=1
b=2
n=34698809
c=-1
w=101
sf=71
p1=1
==END==

| 2015-08-20 11:43:46 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
| 6207083 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=621a95c6678557e6154afcde3cfeae90&k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA&c=0&p=0.0000&d=86400&e=1724589&ss=6334&sh=E09A349C8FBB850985DF5C822D9B2F03 | pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

| 2015-08-20 11:43:47 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
| 6207093 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=621a95c6678557e6154afcde3cfeae90&k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA&c=0&p=0.0000&d=86400&e=1724317&ss=24661&sh=7AFEA889EDE86DDE2BDD09F4CFA59C2E | pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

| 2015-08-20 11:49:47 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
| 6209157 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=621a95c6678557e6154afcde3cfeae90&k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA&stage=LL&c=0&p=0.9050&d=86400&e=1466470&ss=28218&sh=043E7AF28EADCA209183645E4F2BA502 | pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

| 2015-08-22 13:03:50 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
| 6210202 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=621a95c6678557e6154afcde3cfeae90&k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA&stage=LL&c=0&p=15.7541&d=86400&e=1194268&ss=6599&sh=035D23194788BF56F16F269535885AFF | pnErrorResult=0
pnErrorDetail=SUCCESS
==END==

| 2015-08-23 19:03:15 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
| 6211574 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=621a95c6678557e6154afcde3cfeae90&k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA&stage=LL&c=0&p=36.2721&d=86400&e=801621&ss=31343&sh=DB4AA25A61AF38DB3F9D100F331C13A1 | pnErrorResult=43
pnErrorDetail=ap: no such assignment key, GUID: 621a95c6678557e6154afcde3cfeae90, key: A3BA119A8F7E3C0F4CB2F4B11C16DCFA
==END==

| 2015-08-25 09:44:24 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 |
+---------+------+------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------------------+---------------------+[/CODE]

I am pretty sure that this doesn't release any sensitive information.

Equally, I have no idea why this candidate was assigned by Primenet and then declared invalid.

(If, on the other hand, this was a bug on my end, please let me know.)

[QUOTE=Madpoo;408778]Looks like someone checked in the matching DC. When that happens, any assignments are expired since they're no longer needed:
[URL="http://www.mersenne.org/M34698809"]M34698809[/URL]

The result that came in today did have an assignment for it. Was your assignment the one that expired back in May of 2014 but you were still working on it anyway? I'm guessing not since that one hasn't checked in since March of 2014 and was only 0.1% done at that time. :smile:[/QUOTE]

It used to be that LL tests completed not by an official client displayed residues in small letters on the status page. This one is displayed in capital letters, I wonder why the change…

[QUOTE=TObject;408798]It used to be that LL tests completed not by an official client displayed residues in small letters on the status page. This one is displayed in capital letters, I wonder why the change…[/QUOTE]
No change. P95 was used. Some related issue: there was a time when P95 used to keep the exponents if the work was already started (and cancel/abandon those in the queue whose keys became invalid, [U]only if the work for them wasn't started yet[/U]). If the behavior changed with the new versions of P95, then someone should tell me and I will immediately roll back. This test should have been kept running, and recorded as DC (or TC, etc) and the credit given to the user. We do lots of (credited) TCs anyhow. I would be quite upset if it happens to me!

I hope one still could use N/A as a key, to work some unassigned expo (otherwise I would have to disconnect from the net during the tests :shock:)

OTOH, magic with DCs assigned through GPU72 proxy used to happen in the past - that is why I gave up, and I am now requesting DC work directly from PrimeNet - this was long discussed in a nearby topic. From the log shown above, however, it seems that is not a proxy problem, it was not a PrimeNet thing either, because the exponent was completed, so the key became nil. But P95, the local P95, should continue the work, if it was started (and replace the key with N/A), or at least, don't delete the ckpoint files, so the user may continue if he wants. Otherwise is bullshit, I* will look for exponents ready to complete (completed 80% or so), put my GPUs on them (a good GPU need less than half a day for one DC) and sabotage the credit for the assignee, I know few guys for who I would do that :devil:

------
* The "general I", not me in particular.

[QUOTE=LaurV;408809]...OTOH, magic with DCs assigned through GPU72 proxy used to happen in the past - that is why I gave up, and I am now requesting DC work directly from PrimeNet - this was long discussed in a nearby topic. From the log shown above, however, it seems that is not a proxy problem, it was not a PrimeNet thing either, because the exponent was completed, so the key became nil. But P95, the local P95, should continue the work, if it was started (and replace the key with N/A), or at least, don't delete the ckpoint files, so the user may continue if he wants. Otherwise is bullshit, I* will look for exponents ready to complete (completed 80% or so), put my GPUs on them (a good GPU need less than half a day for one DC) and sabotage the credit for the assignee, I know few guys for who I would do that :devil: ...[/QUOTE]

Oooo, evil. :smile:

It seems like in this case, I'm not convinced the assignment ever showed up on the Primenet server (as in, it didn't get logged in the assignment table, regardless of what the response code back to the GPU72 proxy was). I'll have to look back at the raw logs for that date and see what showed up.

The reason I say that... let's say you have an assignment for something, and it gets poached. The way the server handles that is to "soft" expire the assignment. It gets a date stamp in the database for when it expired, and gives an expiration reason of "poached".

If the user continues the assignment and checks it in, the result may not really be needed, but the user will still get credit for it.

This is true in other cases... if you're doing a test and someone "poaches" it by doing extra TF or P-1 and finds a factor, they check it in and all LL/DC assignments get expired the same way, but if you check in your result eventually, it's accepted and you'll get credit, it was just not needed anymore.

In this case though, I don't even see a "soft expired" entry. The only time an assignment actually gets removed from the database is when the result is checked in, or if it's manually removed using the website, or I guess if the user quits GIMPS? In other words, purposeful things.

I guess there could be something else going on... not sure what. Maybe the logs will help me when I look through them.

[QUOTE=chalsall;408795]OK. Let's get "Down and Dirty". This is what the GPU72 proxy saw with regards to this:

[CODE]| 6207082 | NULL | NULL | http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=621a95c6678557e6154afcde3cfeae90&c=0&ss=18467&sh=C42C8B775F6AACBDD1533ED7AD3D8585 | pnErrorResult=0
pnErrorDetail=Server assigned Lucas Lehmer primality double-check work.
g=621a95c6678557e6154afcde3cfeae90
k=A3BA119A8F7E3C0F4CB2F4B11C16DCFA
A=1
b=2
n=34698809
c=-1
w=101
sf=71
p1=1
==END==

| 2015-08-20 11:43:46 | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | [/QUOTE]

Well, I found the Primenet log entry:
[CODE]2015-08-20 15:43:45 107.155.126.203 GET /v5server/ v=0.95&px=GIMPS&t=ga&g=621a95c6678557e6154afcde3cfeae90&c=0&ss=18467&sh=C42C8B775F6AACBDD1533ED7AD3D8585 80 - <your ip address was here> - - v5.mersenne.org 200 0 0 363 202 202[/CODE]

I can't see the server response though. One thing I do notice... the proxy server must not be synced to an NTP time source like Primenet. :smile: There's a 1 second difference (the Primenet stamps are UTC).

So... yeah, I can't really explain what happened there. Primenet got the assignment okay. I guess if I'm curious enough I can restore a previous backup of the DB from a few days ago and look at that table just to see that, yeah, it really was in there and just got expunged for whatever reason.

[QUOTE=Madpoo;408821]So... yeah, I can't really explain what happened there. Primenet got the assignment okay. I guess if I'm curious enough I can restore a previous backup of the DB from a few days ago and look at that table just to see that, yeah, it really was in there and just got expunged for whatever reason.[/QUOTE]

So, I just restored a copy of the DB from a couple days ago (Sunday). I see that assignment in there:
[CODE]aid: A3BA119A8F7E3C0F4CB2F4B11C16DCFA
exponent: 34698809
assigned: 2015-08-20 15:43:46.413
last updated: 2015-08-22 17:03:50.233
next expected: 2015-08-23 17:03:50.233
est. completion: 2015-09-08 16:25:00.233
% done: 0.9
stage: LL[/CODE]

So... it did get assigned. And then for whatever reason it got [I]reassigned[/I] to someone else on "2015-08-24 01:48:54.020"

The server wouldn't have reassigned it if that original assignment were in place and still going. It's impossible... if it's assigned, it's not available for assignment to anyone else (excepting overlapping ECM work).

My best guess? Somehow, something cancelled that assignment made on the 20th. And given it's low #, it would have been reassigned almost right away.

Think you could look in the GPU72 logs again and see if there was anything passing through there later on that may have sent a request to cancel that assignment? I'd roll through some diff logs as well as the full backup, but that's like work for me.

If I look at the IIS logs, I can see that on the 23rd it checked in again and updated the % done to 15.75%. And then on the 24th at 01:22:06 (UTC) it connected and sent a t=au for that assignment. I'm not sure what t=au is... t=ap is an update to the assignment for the latest progress, I saw that, but I'd have to dig through that code and see what t=au means. I'm guessing it's an assignment/unassign ? It came from the same GPU72 proxy IP address (50.21.x.x)

On the 25th it tried to connect again and update with the t=ap command . That must be when it found out it was unassigned.

Hope that helps. And now everyone has a weirdly fresh and blood and guts look at how the servers all talk to each other. LOL

This is why you shouldn't share your assignment ID's with anyone... someone could send a command to unassign that work leaving you high and dry. Well, at least in this case, since someone else had got the assignment and finished it real quick. Otherwise it would have accepted the unknown assignment ID (or generated a new one?)

[QUOTE=Madpoo;408818]The reason I say that... let's say you have an assignment for something, and it gets poached. The way the server handles that is to "soft" expire the assignment. It gets a date stamp in the database for when it expired, and gives an expiration reason of "poached".

If the user continues the assignment and checks it in, the result may not really be needed, but the user will still get credit for it.

This is true in other cases... if you're doing a test and someone "poaches" it by doing extra TF or P-1 and finds a factor, they check it in and all LL/DC assignments get expired the same way, but if you check in your result eventually, it's accepted and you'll get credit, it was just not needed anymore.

In this case though, I don't even see a "soft expired" entry. The only time an assignment actually gets removed from the database is when the result is checked in, or if it's manually removed using the website, or I guess if the user quits GIMPS? In other words, purposeful things.
[/QUOTE]
Yes, what you describe is [U]exactly[/U] what it should be, and this is the correct and the fair way. Let me do quadruple checks if I want to waste my time and money (maybe a checkbox with "I know what I am doing", or a local.txt key should ensure this - but it was exactly why the N/A key was introduced, wasn't it?), and in case I am doing some legal-assigned DC, don't interrupt me (and rob me from the credit) if some poacher does my work faster.

The Prime95 I know used to erase the work from the worktodo if it was not needed anymore [B][U]and[/U][/B] if it was not started. There should not be any changes in the newer versions (are they any?). We were talking in the past about "notifying the user" (maybe he doesn't want to waste his time anymore, for not-needed work, and he will willingly switch to the next exponent in the queue), and even about canceling the current text (to save time), but if something like that was (or will be) implemented in P95, then the checkpoint files should not be deleted, to allow the user to continue the work later, if he wants.

[QUOTE=Madpoo;408829]Think you could look in the GPU72 logs again and see if there was anything passing through there later on that may have sent a request to cancel that assignment?[/QUOTE]

What I posted above is everything related to that candidate / assignment. There was no "unassign" request made -- the client was told it no longer had it when it checked in.

Further, there's no record of that candidate being assigned to anyone except kladner.

Definitely strange.

[QUOTE=chalsall;408852]What I posted above is everything related to that candidate / assignment. There was no "unassign" request made -- the client was told it no longer had it when it checked in.

Further, there's no record of that candidate being assigned to anyone except kladner.

Definitely strange.[/QUOTE]

Well, I looked through the code and I can confirm that a t=au parameter when calling the Primenet API will indeed delete the assignment.

That request came through the GPU72 proxy, so I guess the question is where did that originate? I've never used the proxy, but I'm assuming clients point to it, and it will pass along requests to Primenet if/when needed, or handle assignments using it's own pool of work it has at the ready.

If I had to guess, a request from the end client to unassign (t=au) some work came in and that was passed along to the Primenet server. Your logs around that same time might show that original request since it did pass through the proxy, so you could see if it's the same IP address as "kladner" normally uses. Feel free to PM me for any additional info you might need to help narrow it down... we may be boring everyone else here with all of the inside baseball chats (or maybe they enjoy it?)