[QUOTE=lycorn;278675]When the first exponent finished, the second one started straightaway but the result for the first one wasn´t immediately sent to Primenet Server, as I have Prime95 set to not automatically send results to the server. Some hours later, I sent the result to the server (via Prime95, not the manual pages). The result was accepted, credit correctly given, but the 3rd and 4th exponents in the queue, which had not any work done on them yet, got kicked out of worktodo.txt. No big issue, I rebuilt the lines with the information on my Assignments Report in GPU to 72 tool; now the thing is, next time I send a result to the server the same thing will happen. If instead of 2 exps one has 20 or more, it starts to be a real pain...
[/QUOTE]
Curious as to why you are NOT sending results immediately. Though I have a feeling doing so would not change you losing the worktodo.

I have reserved lots of P1 (10 per worker) and never lost any from work todo. Is it possible you have your "Days of work to queue up" or "Unreserver Days" set too low?

[QUOTE]
I see 2 workarounds for this situation: the worker receives the hex key from GPU to 72 together with the assignment OR the worker reports the completion of the work unit using the Manual Pages of Primenet. The first would be the most practical, of course.
What you think?
[/QUOTE]

I'd rather not have to do manual submission. In my little GIMPS world I like to know which CPU completed the work and under Manual it can't

[QUOTE=chalsall;278690]Hmmm... Damn. I had thought that the N/A would result in Prime95/mprime not trying to report back to PrimeNet until the work was completed. Obviously incorrect...
[/QUOTE]

I get the Prime95 credit as soon as the work completes and sends it....and your credit at xx:35 as prescribed.

I'm not sure it is the server that drops worktodo entries. All of my N/A assignments do NOT show up on the server in my worklist and do NOT send expected completion dates to the server and do NOT drop from my worktodo list.
On my client I have days of work to queue up to 5 so that I don't get other work as these finish but I also have in prime.txt:

[CODE]MaxExponents=15
UnreserveDays=365[/CODE]

If the first is too low (i.e. 3) it will tell my client to drop any assignments after the 3rd for each worker

If the second is too low (i.e. 10) it will drop any assignments more than 10 days from starting.

It seems half the people on this thread completely missed that the problem has already been solved with just a reboot of P95 whenever lines are added. Nothing needs to change currently. petrw1, I find the same thing with regards to PrimeNet and that these P-1 assignments don't appear.

[QUOTE=Dubslow;278713]It seems half the people on this thread completely missed that the problem has already been solved with just a reboot of P95 whenever lines are added. Nothing needs to change currently.[/QUOTE]

Including me... I didn't even think of this since I always stop mprime before editing my worktodo.txt files and then restart, or else use the worktodo.add feature. I'll have to add this as a note on the Get Assignment pages.

[QUOTE=Dubslow;278713]petrw1, I find the same thing with regards to PrimeNet and that these P-1 assignments don't appear.[/QUOTE]

This is how it should be. The assignments from "GPU to 72" don't actually formally "belong" to you, they are "owned" by "GPU Factoring" as far as PrimeNet is concerned, and are being "lent" to Workers.

Indeed, that´s the solution. No worries about the server, the spider, P95 client or anything else but the user (which is generally the bad factor in any system... :smile:)

@petrw1: the reason I don´t send results automatically has nothing to do with this type of work/assignments, I´ve actually done so for a long time. It´s just that I like to have a closer control over the client, changing types of work, workloads, adding some personal picks, etc., without server "interference", i.e. getting sometimes work I don´t really want, just to unreserve it later.
Moreover, imagine the computer reports a new prime: I would have the pleasure to announce the discovery at my own discretion, and only after re-running the last iterations from the saved savefile, so I would be a bit more confident in the result before shouting out loud. (Of course I´m kidding, that´s not the main reason... :loco:)

[QUOTE=chalsall;278727]Including me... I didn't even think of this since I always stop mprime before editing my worktodo.txt files and then restart, or else use the worktodo.add feature. I'll have to add this as a note on the Get Assignment pages.[/QUOTE]

Someone correct me if I am wrong but I believe Prime95 loads contents of work files such as Prime.txt; local.txt and Worktodo.txt into memory...and hence should NOT be updated while it is running because it seems that when Prime95 is stopped it writes what it has back into the work files overwriting whatever you have changed.

SO I too concur...when you take GPU-to-72 work you either need to use worktodo.add OR stop Prime95 before editing worktodo.txt directly.

I've never had it overwrite any changes I've made while it's running.

[QUOTE=petrw1;277632]If that (doing P-1 only) is an option I could help out there too.

I've got 9 cores available.[/QUOTE]

OK all 9 cores going ... and completing about 8 per day.

[QUOTE=Dubslow;278736]I've never had it overwrite any changes I've made while it's running.[/QUOTE]

Good to know.

How about local.txt or prime.txt with it running?
Have you tried to update worktodo.txt? Without it overwriting? If so then that still leaves lycorn's issue or losing worktodo entries as a mystery to me.

[QUOTE=Dubslow;278736]I've never had it overwrite any changes I've made while it's running.[/QUOTE]


I always lose the assignments without the hex key, using N/A, unless I reboot, and never have a problem when I have the hex key and add them "live".

Doug

[QUOTE=Dubslow;278736]I've never had it overwrite any changes I've made while it's running.[/QUOTE]

I have.

That's why I got into the habit of automatically stopping mprime before I made any changes.