[QUOTE=thyw;439401]So about ecm assigments. I was working on[URL="http://www.mersenne.org/report_exponent/?exp_lo=81239&exp_hi=&full=1&ecmhist=1"] m81239[/URL] ecm, b1=1M...
but about halfway there the server unreserved it from me. Somebody finished the current "range/bounds", by completing enough of the requied curves on [URL="http://www.mersenne.org/report_ecm/?txt=0&ecm_lo=81239&ecm_hi=81239"]ecm progress[/URL].
It was like 5GHzday 150 curves, but i cannot continue to ecm on with those bounds even from my existing savefile, it jumps to higher bounds assigment.
Is it intended to unreserve exponents from users when the range/curve count is complete?
[/QUOTE]

Are you sure that the server unreserved the assignment? What normally happens when someone else delivers full results ahead of you is that the server marks your assignment as 'expired' (though I'm not sure that it even does that for ECM - must check sometime as it often happens to me), and it disappears from your Account Assignment Details list (which seems to be a bug) but as LaurV stated, it's still actually assigned to you and has no effect on whether the server will accept your results when you deliver them. If someone else jumps in with manual results and completes the level when you're running ECM, you might want to complete your run early, but in any case your additional ECM curves will still count when delivered - additional curves beyond the standard limit count as a contribution to the next level up at a reduced rate (something like 3-5 curves count as 1 at the next level, depending on the B1 ratios I think) so it's not wasted work.

[QUOTE=thyw;439401][U]Thank you GP2[/U], but i think i screwed up and probably overwrote the savefiles when tried to reassign. It won't continue, old or new instance. [I][SIZE=1]
[/SIZE][/I][/QUOTE]

Yes, the save files names are derived from the exponent you're working on, so starting a 'new' assignment with the same exponent would overwrite the existing save files... A pity.

IIRC: I was away while i happened, later i
[LIST=1][*]Noticed the "Unreserving..." in the prime95 ui.[*]Reserved it by adding the 1M line to the worktodo[*]Then pressed start[*]It started the one with b1= 3M[*]Copied the savefiles, since the client writes to the savefile when you stop it (as i noticed based on the "modified" date.) (!Maybe? it write the first when you start an exponent!)[*]Stopped the client.[*]Tried to reassign the exponent from primenet and manually too. (little panicing)[*]Couldn't get it to continue.[/LIST]...Probably still my fault somewhere.
[CODE]
[SIZE=1][Fri Jul 29 13:26:29 2016 - ver 28.7]
Updating computer information on the server
Sending expected completion date for M81239: Jul 31 2016
Sending expected completion date for M9000209: Aug 15 2016
[Fri Jul 29 21:11:06 2016 - ver 28.7]
Exchanging program options with server
[Sat Jul 30 15:28:41 2016 - ver 28.7]
Exchanging program options with server
[Sun Jul 31 01:13:46 2016 - ver 28.7]
Exchanging program options with server
[Sun Jul 31 05:25:31 2016 - ver 28.7]
Exchanging program options with server
[Sun Jul 31 14:40:00 2016 - ver 28.7]
Updating computer information on the server
Sending expected completion date for M81239: Aug 01 2016
Sending expected completion date for M9000209: Aug 16 2016
Exchanging program options with server
[Sun Jul 31 18:49:17 2016 - ver 28.7]
Updating computer information on the server
Sending expected completion date for M81239: Aug 02 2016
Sending expected completion date for M9000209: Aug 16 2016
[Mon Aug 01 15:25:51 2016 - ver 28.7]
Exchanging program options with server
[Mon Aug 01 16:46:54 2016 - ver 28.7][/SIZE]
Unreserving M81239[/CODE]

[QUOTE=thyw;439697][CODE][SIZE=1]
...
[Mon Aug 01 15:25:51 2016 - ver 28.7]
Exchanging program options with server
[Mon Aug 01 16:46:54 2016 - ver 28.7][/SIZE]
Unreserving M81239[/CODE][/QUOTE]

OK, that makes sense. This is your local Prime95.exe itself unilaterally deciding to abandon that exponent, nothing to do with the server I believe - bad news, as it would normally delete any save files at the same time as releasing the exponent.

Maybe someone else can correct me here, but afaik this should only happen if the start date for that exponent is now beyond the 'Days of work to queue up:' value you have set. The question is, how did the start date of this exponent get moved back? Had you, perhaps, edited another work unit into the worktodo.txt file in front of M81239, or perhaps reduced your 'Days of work' value? Or maybe you were making unexpectedly slow progress so the finish time for a prior exponent slipped back? Whatever happened, I believe that any work on that exponent would probably have been lost when it was released.

There is a way to prevent Prime95 releasing work which is outside the 'days of work to queue up' limit if you need to, say if you're also adding some work manually; just add the line UnreserveDays=n (where n is the number of days ahead that Prime95 should allow work to be starting without releasing it) to the prime.txt file. (You'll also need to stop and restart Prime95 for it to become effective).

Tony

[QUOTE=Syntony;439736]OK, that makes sense. This is your local Prime95.exe itself unilaterally deciding to abandon that exponent, nothing to do with the server I believe...[/QUOTE]

That is my understanding as well.

[QUOTE=Syntony;439736]...bad news, as it would normally delete any save files at the same time as releasing the exponent.[/QUOTE]

It /shouldn't/, AFAIU. Once any work has been done the client _shouldn't_ unreserve the assignment nor delete the safe files.

[QUOTE=Syntony;439736]Maybe someone else can correct me here, but afaik this should only happen if the start date for that exponent is now beyond the 'Days of work to queue up:' value you have set. The question is, how did the start date of this exponent get moved back?[/QUOTE]

There have been similar reports in the past, by many people, that the mprime/Prime95 clients sometimes radically adjust their predictions as to their completion times. This can then lead to client-side unreserving of assignments.

The reports suggest this isn't just because of clients which have been offline for a while, but sometimes for clients which have been running continuously 24/7 for extended periods.

I consider this a "once-a-month bug". Evident, but difficult to reproduce.

I wonder if the [URL="http://www.mersenne.org/report_recent_cleared/"]Recent Cleared[/URL] report might have an issue.

An additional factor for [URL="http://www.mersenne.org/report_exponent/?exp_lo=3836363&exp_hi=&full=1"]M3836363[/URL] was returned by TJAOI on 2016-08-10 but doesn't show up in the Recent Cleared report, even though as of this moment the oldest entry in that report dates from 2016-08-09 06:35

[QUOTE=GP2;439804]I wonder if the [URL="http://www.mersenne.org/report_recent_cleared/"]Recent Cleared[/URL] report might have an issue.

An additional factor for [URL="http://www.mersenne.org/report_exponent/?exp_lo=3836363&exp_hi=&full=1"]M3836363[/URL] was returned by TJAOI on 2016-08-10 but doesn't show up in the Recent Cleared report, even though as of this moment the oldest entry in that report dates from 2016-08-09 06:35[/QUOTE]There were already three other factors reported many years earlier. So presumably it hasn't just been "recently cleared".

I didn't know about these, thank you for the solution and the efforts.
And yes, the "days of work to queue up" was 0 for me. Semi-manual assigments. But i can't remember any other case of unreserving. Probably that was it.

[QUOTE=retina;439805]There were already three other factors reported many years earlier. So presumably it hasn't just been "recently cleared".[/QUOTE]

Doh.

[QUOTE=retina;439805]There were already three other factors reported many years earlier. So presumably it hasn't just been "recently cleared".[/QUOTE]

Wait... it didn't work that way before. I discovered a few non-first factors of low exponents no more than a week ago, and I did see them show up in the Recent Cleared list. Also you would occasionally see a fresh batch of factors from TJAOI, and he rarely finds first factors.

Clearly a very recent change. Might actually be a good idea. There's still "[URL="http://www.mersenne.org/report_factors/"]Detailed Reports / Factors Found[/URL]" with the "Discovered since" parameter to see all factors.

Another recent oddity I've noticed - [URL="http://www.mersenne.org/report_exponent/?exp_lo=1420109&full=1"]M1420109[/URL] had an ECM factor reported by raman22feb1988 on August 10th, but it hasn't been entered in the [URL="http://www.mersenne.ca/exponent/1420109"]ECM Factoring Results[/URL] table (though it has been listed as a factor) :confused2:

[QUOTE=Syntony;439848]Another recent oddity I've noticed - [URL="http://www.mersenne.org/report_exponent/?exp_lo=1420109&full=1"]M1420109[/URL] had an ECM factor reported by raman22feb1988 on August 10th, but it hasn't been entered in the [URL="http://www.mersenne.ca/exponent/1420109"]ECM Factoring Results[/URL] table (though it has been listed as a factor) :confused2:[/QUOTE]

It's there now. There seems to be a short delay in updating that table, one of my negative results from 12 hours ago doesn't show up yet, but another one from 24 hours ago does appear.