[QUOTE=Dubslow;291455]Go hit the link, and see when GPU Factoring "reserved" that exponent. It's magic! What the heck did you do chalsall?!?[/QUOTE]

Thanks for your kind words Dubslow...

I would rather not go into details of how this works. It was a serendipitous discovery while I experimented with ways of having Spidy cause less load on PrimeNet.

With regards to 42576463, it had been previously reserved by someone using V4 of PrimeNet on 2008-11-24; 1193 days ago. No LL work had been done on it, but it was checking in every few weeks...

Why PrimeNet itself didn't unreserve it is a bit of a mystery to me.....

[QUOTE=nucleon;291462]Dubslow - your enthusiasm never ceases to amaze me.

-- Craig[/QUOTE]

In this case, it's because chalsall waved his hands (typed with his hands? :smile:) and suddenly GPU to 72 has control of at least 15, possibly more of the expos holding this up:
[quote]Countdown to testing all exponents below M(43112609) once: 85[/quote]

As long as the system don't return them when we're done TFing them (!), we can clear them ourselves and be significantly closer to the milestone than we might have been otherwise. If I stopped all the P-1 I was doing, I could clear 15 expos that low in... 3-4 months, and we can certainly do it faster if we give a few to Bdot, a few to George, maybe you or Xyzzy, monst, etc. Hence my enthusiasm :)
(Also, seeing as most heuristics suggest it'll be a long time until we find another prime, and I joined 'just last year', this is all I have to be excited about :razz:)

[strike]@chalsall: If gpu-2-72 gets back 26026433 and/or 26177689 could you please keep them reserved (not re-assign them) or assign them to me. As per discussion in [URL="http://www.mersenneforum.org/showpost.php?p=291484&postcount=861"]this post[/URL].
[/strike] Sorry. Stupid poster! Forget this. The expo is already verified... by myself, of feb.12, well I won't expect myself to remember all expos I verified...

chalsall, if you set the spider to not unreserve expos below 45M after TF, I can coordinate and keep track of an effort on the part of forumgoers to clear them, because they'll take much longer the PrimeNet way. If there are even two more volunteers (besides me) we can probably clear them in a month. (There are 15 expos<43M, and 46 expos<45M, at the moment.)

The way I see it, you could PM me a list of expos; Any volunteers will then PM me with how many expos they can/want to clear, and I can assign them manually. Either me, the tester or spidey can check for completion, at which point spidey unreserves them. (If somebody requests I can make the list of assignments available on my site, but there's no reason a priori to do that.)

What do you think? I think I might be talking a bit too much, but it is a pretty sweet opportunity.

[QUOTE=Dubslow;291496]chalsall, if you set the spider to not unreserve expos below 45M after TF, I can coordinate and keep track of an effort on the part of forumgoers to clear them, because they'll take much longer the PrimeNet way. If there are even two more volunteers (besides me) we can probably clear them in a month. (There are 15 expos<43M, and 46 expos<45M, at the moment.)

The way I see it, you could PM me a list of expos; Any volunteers will then PM me with how many expos they can/want to clear, and I can assign them manually. Either me, the tester or spidey can check for completion, at which point spidey unreserves them. (If somebody requests I can make the list of assignments available on my site, but there's no reason a priori to do that.)

What do you think? I think I might be talking a bit too much, but it is a pretty sweet opportunity.[/QUOTE]

I can pause my current LLs and take 10. It will take me about a month to clear 8 of them at a time, the other two would take about 20 days longer each.

[QUOTE=Dubslow;291496]What do you think? I think I might be talking a bit too much, but it is a pretty sweet opportunity.[/QUOTE]

Thanks for the offer. But don't you think it would make more sense for me to coordinate this? After all, I could have Spidy watch for the completions, and award credit on G72. :smile:

I have asked Spidy to not return any candidate below 43112609, of which we hold twenty. All were well over a year old; fifteen were over three years old. Ten of these had had [B][I][U]no[/U][/I][/B] work done on them. One hadn't even had P-1 done!

The good news is these have gone to three good homes -- reliable workers who will hopefully put them at the top of their worktodo.txt files.

But a question: what do people think about, for this "special case", that we issue these to LL workers at the same time as the TF work is going on? The risk is to the LL workers -- a factor might be found before the work is completed. I'd e-mail / PM the person impacted if this happens.

Any volunteers? Please PM me if you're interested. I'd like to see all of them run in parallel, rather than queued, so please ask for only as many as you can run at the same time. (Dubslow -- let me know which of the six you've been assigned you'd like to keep for LLing. All of them is fine if you've got the fire power.)

I offered to do it so it isn't more work for you. $DEITY knows you've certainly put a buttload of work into this already, and this is one of the few things (as yet) that I can do, so I figure I'd make my services available if necessary. (I figured it would be easiest for Spidey to watch for completions, but on the PM end it's still manual work, which I can do :smile:)

I did put mine at the top of my worktodo :)

The problem with my LL is that currently I have ~1.5 weeks' worth of P-1 queued up, half 52M and half >52M (and like 2 below 50M). If the system is okay with the unreserving, then I can unreserve them, and I think I'd keep all six LLs -- on this desktop/main box, I use 3/4 cores for P-1 (1/4 mfaktc), so I would have two tests per worker. I'd estimate a month, maybe a bit more to do all six. PM with expos is on its way.

You can pass me lower TF work at both DC and LL fronts, from time to time. For example PM. My queued work is never longer then 10 days and the expos are automatically sorted by size every time I do reports (at least 2-3 times per day) or do work-additions. I am also recording all factors I ever found (like in "being a packing rat"), I would get notification for each (all job is done by a batch file which also collects work from all mfactc folders, this batch I launch it manually from time to time, it is doing its job and exits), and I do all the reports manually, on the mersenne.org web page, after being sure I am logged in to primenet (I don't trust reporting spiders, exactly for this reason, sometime they could be too fast and my results end up reported as anonymous). You see, there is no way that a factor would escape unseen, and I could post here (emailing to the LL assignee I won't promise, but posting here around would be no bother) if a factor is found for an exponent between say 35M and 45M. The assignees of such lower exponents should check if a TF work is in progress for them. When CudaLucas would be fixed and reliable, I would engage to LL them too.

[QUOTE=chalsall;291451]
While Spidy continues to work, I have modified the LL-TF reservation page such that any candidates TFed to 69 bits and below are now considered "preferred". Only those who pledge to take them to 72 bit or above will have access.[/QUOTE]

Oh chalsall ...

Probably one reason (for me the main one) for having a dedicated instance running only 69-70 is in a current deficiency of mfakto (a well-tested prerel-version that Kyle, flashjh and myself are running). The most efficient kernel of this version can only handle tests up to 70 bits, and the throughput difference compared to 71-tests is significant.

This alone would not be too bad - mfakto could run to 70 bit with this fast kernel, and do the rest with a less efficient one. However, currently this fast kernel requires VectorSize=8 for best results. Running the next kernel to 71 (or 72) bits with that vector size, yields terribly slow results - it requires VectorSize=4. Therefore you need to stop mfakto and restart it with different config. Or, you run one instance with 69-70 tests, and another one for the bigger tests. A few weeks ago I changed my assignments to run only one instance with 69-70 tests, and 4 to 72.

Up to the official release of these kernels, I'll change the VectorSize config to switch automatically, but I'm not yet that far. Mfakto development is slower than I want (time constraints :down:)

I understand why you did this change and most GPU-to-72 users will thank you. For me this means I either separate the 69-70 step from the 69-72 assignments (when I get those), or run them all with VectorSize=4. Less efficient, but probably better than more manual intervention (and more chances for errors).

PS: Regarding the very low LL tests: I cannot help with that before Monday. I don't have access to the faster machine before that.

[QUOTE=chalsall;291512]
But a question: what do people think about, for this "special case", that we issue these to LL workers at the same time as the TF work is going on? The risk is to the LL workers -- a factor might be found before the work is completed. I'd e-mail / PM the person impacted if this happens.
[/QUOTE]

Why? If you actually told people to put the TF work on top it should only take hours or days to get results? I wouldn't do anything differently with low exponents.

I might be missing something though.

[QUOTE=Bdot;291550]Oh chalsall ...

Probably one reason (for me the main one) for having a dedicated instance running only 69-70 is in a current deficiency of mfakto (a well-tested prerel-version that Kyle, flashjh and myself are running). The most efficient kernel of this version can only handle tests up to 70 bits, and the throughput difference compared to 71-tests is significant.

This alone would not be too bad - mfakto could run to 70 bit with this fast kernel, and do the rest with a less efficient one. However, currently this fast kernel requires VectorSize=8 for best results. Running the next kernel to 71 (or 72) bits with that vector size, yields terribly slow results - it requires VectorSize=4. Therefore you need to stop mfakto and restart it with different config. Or, you run one instance with 69-70 tests, and another one for the bigger tests. A few weeks ago I changed my assignments to run only one instance with 69-70 tests, and 4 to 72.

Up to the official release of these kernels, I'll change the VectorSize config to switch automatically, but I'm not yet that far. Mfakto development is slower than I want (time constraints :down:)

I understand why you did this change and most GPU-to-72 users will thank you. For me this means I either separate the 69-70 step from the 69-72 assignments (when I get those), or run them all with VectorSize=4. Less efficient, but probably better than more manual intervention (and more chances for errors).

PS: Regarding the very low LL tests: I cannot help with that before Monday. I don't have access to the faster machine before that.[/QUOTE]

I am not going to complain about anything that chalsall does, since he has brought an untold amount of good to the distributed computing project. I imagine that there are people participating simply because of his website. And my gratitude for what he has done is humongous.

But, yes, in this case, this no longer allows people who have AMD's to participate with the exponents below 70. Unless they are willing to sacrifice huge amounts of efficiency or to do the work of splitting each factor line individually to the part <= 70 and the part > 70.

This doesn't bother me. I am just as happy going from 70 to 71, but it is something to put out there.