So now we have only one to go.

[code]
There is 1 assignment

[SIZE="1"]81885841 LL LL, 96.40% 11 -5 2018-10-08 2018-12-20 2018-12-21 2018-12-21 Waki[/SIZE][/code]

Unfortunately, it's been stuck at 96.40% since at least the first week of December.

It would only require 1 day to complete but unless Waki notices it it won't.

I think 5 days is a lot of time and many things can happen.

Mile Milestone
 

Speaking of [B][SIZE=3]mile[/SIZE][/B]stones, the number of unfactored Mersenne numbers below the classic 79.3M limit is currently 1,609,344, which is exactly equal to the number of millimeters in a mile. Of those numbers,

1,036,235 are composites with two LL tests
573,059 are composites with one LL test
50 are prime

To visualize how rare these primes are, if each unfactored Mersenne number were represented by 1mm, the total length of them below 79.3M would be 1 mile. However, the total length of the primes would be just under two inches, with most of them concentrated in the very beginning of the mile.

[QUOTE=rudy235;504033]
[code]
There is 1 assignment

[SIZE="1"]81885841 LL LL, 96.40% 11 -5 2018-10-08 2018-12-20 2018-12-21 2018-12-21 Waki[/SIZE][/code]

Unfortunately, it's been stuck at 96.40% since at least the first week of December.
It would only require 1 day to complete but unless Waki notices it it won't.
I think 5 days is a lot of time and many things can happen.[/QUOTE]

I will bet that someone has already completed this assignment and will report it before the end of the year if it isn't otherwise completed.

[QUOTE=rudy235;504033]So now we have only one to go.
...
Unfortunately, it's been stuck at 96.40% since at least the first week of December.

It would only require 1 day to complete but unless Waki notices it it won't.

I think 5 days is a lot of time and many things can happen.[/QUOTE]

I looked at the historical progress of it and that user has had bursts of activity followed by long droughts of inactivity.

I really don't know what happens with some of these machines where it will start out gangbusters, doing 10% per day and then suddenly plummet to doing zero % per day (while still reporting in), or sometimes not checking in at all for weeks, and then finishing in a short, frenzied burst.

My guess is these are systems that run Prime95 manually and maybe they forget to restart after a reboot ... the ones that I can't explain are the ones that check in every day like good little workers, but have nothing to show for it. Either the worker is stopped but the program is still running, or the system is so busy doing other things that Prime95 doesn't have any idle cycles to use, or... who knows.

[QUOTE=Madpoo;504178]I looked at the historical progress of it and that user has had bursts of activity followed by long droughts of inactivity.

I really don't know what happens with some of these machines where it will start out gangbusters, doing 10% per day and then suddenly plummet to doing zero % per day (while still reporting in), or sometimes not checking in at all for weeks, and then finishing in a short, frenzied burst.

My guess is these are systems that run Prime95 manually and maybe they forget to restart after a reboot ... the ones that I can't explain are the ones that check in every day like good little workers, but have nothing to show for it. Either the worker is stopped but the program is still running, or the system is so busy doing other things that Prime95 doesn't have any idle cycles to use, or... who knows.[/QUOTE]
There definitely are things that will unexpectedly begin to take up a whole core or more, taking it away from prime95, which stalls an entire worker. (A version of Windows that is no longer supported for automatic updates can spin a core uselessly seeking updates indefinitely for days until manually stopped. That's a "feature" in Vista for example. In early 2020 the unavailability of updates will spread to Windows 7. [URL]https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-official-support-end-date/c7fba52e-a273-4235-a000-030d956bb1a0[/URL])

CUDAPm1's gcd is performed on a cpu core, and that can stall an entire multi-core prime95 worker for however long that takes. gpuOwL's PRP-1 does the same as I recall. This type stall should be of order an hour or less per gcd, not the days or weeks that would show up as stalled primality tests in primenet server reports.

Another possibility is the assignment gets moved behind some other assignment(s). It would make no progress while an assignment "in front of it" makes progress. When it gets to the front of that worker's queue suddenly it starts making progress again. This can happen either with significant manual intervention to reorder entries in the worktodo file, or simply by reducing the number of workers. It could also be that someone paused the work, "just for a minute", then forgot to click continue, as you say.

Another possibility is a prime95 or mprime instance on a seldom used lab computer with an aggressive power save setting. The system could go into deep hibernation, where what might take two minutes normally, could take 100 times longer or more.

[QUOTE=The Carnivore;504152]Speaking of [B][SIZE=3]mile[/SIZE][/B]stones...[/QUOTE]
Beautiful post, and very well spotted!

:goodposting:

[QUOTE=Madpoo;504178]I looked at the historical progress of it and that user has had bursts of activity followed by long droughts of inactivity.

I really don't know what happens with some of these machines where it will start out gangbusters, doing 10% per day and then suddenly plummet to doing zero % per day (while still reporting in), or sometimes not checking in at all for weeks, and then finishing in a short, frenzied burst.

My guess is these are systems that run Prime95 manually and maybe they forget to restart after a reboot ... the ones that I can't explain are the ones that check in every day like good little workers, but have nothing to show for it. Either the worker is stopped but the program is still running, or the system is so busy doing other things that Prime95 doesn't have any idle cycles to use, or... who knows.[/QUOTE]

I am working on different projects. Sometimes I stop mprime or prime95 to run LLR, pfgw or a siever, but keep the prime95 window open: this behaviour reminds me that I have work queued up, avoids to lose the exponent due to expiration (the program still checks in to the server daily) and prevents poachers from stealing it.

I must admit that I very seldom request type 0, 1 or 2 exponents, so I am not guilty to procrastinate milestones... :razz:

[QUOTE=Chuck;504175]I will bet that someone has already completed this assignment and will report it before the end of the year if it isn't otherwise completed.[/QUOTE]

YES. And it is not a prime.

[QUOTE=rudy235;504222]YES. And it is not a prime.[/QUOTE]

It's too bad Kreisel did it as a PRP, because the assignment will probably finish, eventually, and now we'll have one PRP and one LL, and we'll need yet a 3rd one of either to verify. If we're going to poach, let's at least do it the same as the assignee so we're not creating extra work in case that assignment actually does finish.

[QUOTE=Madpoo;504444]It's too bad Kreisel did it as a PRP, [B]because the assignment will probably finish, eventually,[/B] and now we'll have one PRP and one LL, and we'll need yet a 3rd one of either to verify. If we're going to poach, let's at least do it the same as the assignee so we're not creating extra work in case that assignment actually does finish.[/QUOTE]


Clarify this for me.

When does an assignment end definitely?

Apparently, it does not end when it expires. So what has to happen for the assignment to not finish at all?

When an exponent expire on the server, it does not send a message to the users client to delete the exponent.
The user can continue work on it for as long as he/she wants and his client will turn it in when it is done, it could be in a year.