[QUOTE=manfred4;433628]Just wait until our famous Anonymous guy, who did most of the DCTF and now switched to LLTF starts getting Assignments in P-1 ranges, then we'll be set for some time again I guess[/QUOTE]

Yeah, but that's three months out or so. What is really annoying is there are some users who get hundreds of manual P-1 assignments from Primenet and then never work them. These are held up for six months before being released back into the pool.

Also, just so everyone knows... We are very comfortably ahead of the Cat 1, 2 and 4 wavefronts. We're currently balancing most of our fire power keeping ahead of the P-1'ers (in 77M) and the Cat 3 LL'ers (in 73M).

Interestingly, the assignments for Cat 3 and 4 are less than the daily offset jump. As in, many candidates are being "skipped" as the boundaries move upwards. Cat 2 assignments, on the other hand, are currently being fully assigned.

What this means is that in a few months Cat 1 will consist of candidates which were previously assigned but were then recycled, mostly because of abandonment. Exactly as the newest assignment rules were designed for.

I wonder if someone of those manual assignments were requested by bots. Perhaps it would be a good idea to require non-logged-in users to complete a CAPTCHA?

[QUOTE=ixfd64;433668]I wonder if someone of those manual assignments were requested by bots. Perhaps it would be a good idea to require non-logged-in users to complete a CAPTCHA?[/QUOTE]

Possibly a CAPTCHA would be a good idea. But for the most part the manual P-1 assignments are by logged in users.

See [URL="http://www.mersenne.org/assignments/?exp_lo=74000000&exp_hi=80000000&execm=1&exdchk=1&exfirst=1&extf=1"]this report[/URL] for example.

I had recently taken to running 2 P-1 instances, along with 3 DC's in P95. I did this mainly because 25 GiB of idle RAM was begging for some action. However, when I realized that feeding P-1 is the primary TF challenge, I decided to switch the CPU back to all DC.

This proved easier said than done. I have a well-worn routine for changing assignment types, but it did not work this time. Usually, [INDENT]1) I stop P95
2) Change the settings in Worker Windows
3) Shut down P95 if I am changing worktodo.txt manually
4) Go to My Account>CPU and make changes there
5) Start up P95 and communicate with the server
[/INDENT]I also unreserved P-1 assignments which had not started, and moved the remaining ones to the same worker.

When P95 called home, it promptly pulled some more P-1s. I ditched these, first in GPU72. When they came back, I also used P95 to unreserve, as well as GPU72. Like bad pennies, they kept coming back.

I finally took the ultimate step of changing the workers in question to 1st LL on Prime Net, communicating, and then changing them back to DC, and communicating again. This seems to have succeeded. :smile:

Could be done to the end of 80M by October ...
 

At what point do you go to 76 bits?

80M?
85M?
90M?

I know there's a graph somewhere in mersenne.ca

[QUOTE=petrw1;434216]At what point do you go to 76 bits?[/quote]Around 100M-110M

[QUOTE=petrw1;434216]I know there's a graph somewhere in mersenne.ca[/QUOTE]Presumably you mean [url=http://www.mersenne.ca/cudalucas.php?model=490]this one[/url]. It doesn't go that high, but if it did it would look like this (all the way up to 1000M):

I would guess earlier than that. Mostly the global bit level change goes in line with the turnover point which is highest for current GPUs.
Another kinda 'rule' I found is that can approximately take the last point where we changed the bit level (around 70M or 66M for the "enthusiasts") which would relate to 76 bits at around 90M (or around 85M for the enthusiasts)

[QUOTE=manfred4;434231]I would guess earlier than that.[/QUOTE]
Not really. Titans** are very efficient bitches for LL. You have to add about 0.8-0.9 bits (i.e. move the red/orange lines up) for a gtx580, for example, and in that case your feeling would be right.

--------------
** maybe you didn't see the graphic is for a Titan, but the graphic is correct

(sorry for double post, time limit, been busy all morning with job, lunch break here - and we didn't know that is so difficult to make an animated gif! we had to make a movie first and convert it online - we somehow lost our gif animator program, as we didn't use it for ages...:blush:)

This shows very well how the TF limit is card-dependent, we were talking here for ages about that, but an image worth a thousand words... :razz:

[ATTACH]14387[/ATTACH]

[edit: from this image it seems that the offset is not 0.9 bits, but is well over a full bit, more like 1.3 bits or so. I will have to check my... memories]

I use Manual Assignments to get TF candidates for my GPUs [around 1000GHz-day/day total] and they are all at least 128M, way ahead of the 75M-80M LL wavefront.

Does this mean that all the TF necessary around the LL wavefront is completed? Or just that all the LLTF is already assigned to GPU to 72 and awaiting completion?

Let's say I want to do more TF between 75M and 100M how can I get those candidates assigned without joining GPU to 72?

How is that graph applied IRL please?

Does it tell us based on how long a particular CPU or GPU takes at TF at increasing bit levels vs LL that there comes a point at which further TF is pointless and LL should be done instead?

If so, given that the recommendation is
1. use your whatever GPU for TF and not for LL
2. use your whatever CPU for LL and not for TF

How can we then project a definite crossover point for TF to LL for each CPU and GPU when we don't know what GPU(s) [sometimes multiple persons will be assigned for TF at different bit levels] will be used for TF and what CPU for LL by computer D?

The crossover point seems necessarily arbitrary for such a distributed project.