For the record, here's that exponent:

se/i2/results.log:1947:20120302-014333 M52733041 has a factor: 525148122526114916273 [TF:68:69*:mfaktc 0.18 barrett79_mul32]
se/i2/results.log:1948:20120302-014333 found 1 factor for M52733041 from 2^68 to 2^69 (partially tested) [mfaktc 0.18 barrett79_mul32]


-- Craig

[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]

w00t! Thanks chalsall!:grin: It's been a long time since I saw even a few 68s.

EDIT: BTW, has there been any upward revision in the "to72" recommendation? Just wondering. I'm happy going to 72.

And once again The Man shows us why he's The Man :smile:


Edit: Ooohh, more below 45M. Is the "preferred" spider working, or are we getting glitched out again by PrimeNet?
Edit2: "Could it be? Yes, it could. Something's coming, something good, If I can wait! Something's coming, I don't know what it is, But it is Gonna be great!"
YES!!! I just got two expos BELOW 42M AND THEY HAVEN'T BEEN TESTED YET. WOO!! I propose that these expos are too good and too risky to be released and rereserved with the ANON spider (not to mention preferred) and therefore we should manually assign someone to LL these and keep then reserved to GPU272 until the LL is turned in.


(Holy crap that was awesome chalsall! :smile::smile:)

Edit3: You are the best spider trainer I have ever seen. :smile::smile: Point in case: I just reserved [URL="http://www.mersenne.org/report_exponent/?exp_lo=42576463&exp_hi=&B1=Get+status"]42576463[/URL] to go from 69-->72. Go hit the link, and see when GPU Factoring "reserved" that exponent. It's magic! What the heck did you do chalsall?!? I think I have to pull it out: :bow wave:

[QUOTE=kladner;291454]BTW, has there been any upward revision in the "to72" recommendation? Just wondering. I'm happy going to 72.[/QUOTE]

Not yet. And probably not for several months.

72 bits is where we release LL candidates back to PrimeNet at below 58.52M.

Until we're ahead of the LL wave it doesn't make sense to go past 72 bits below there.

Dubslow - your enthusiasm never ceases to amaze me.

-- Craig

[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.

[QUOTE=KyleAskine;291570]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]

We're just being obsessive-compulsive... It would be nice to see the milestone count drop suddenly... :smile:

We still have two left for LLing. First PMed, first served.

[QUOTE=KyleAskine;291571]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.[/QUOTE]

I appreciate your and Bdot's perspective. Something to think about.

My change yesterday was a bit of an emotional response. To identify the elephant in the room, while many who only go from 6[8|9] to 70 are "big guns", there are also several smaller-throughput workers who tend to grab large numbers of low TFed candidates as they become available.

And please don't mis-understand me -- every cycle contributed is needed and appreciated. Not everyone can be a Craig, Xyzzy, Greg, Pete, et al...

However, I think it's important to remember that the whole point of G72 is to help GIMPS. And while finding factors is of course the ultimate goal, at the end of the day we don't really help GIMPS until we return candidates back to PrimeNet. That means TFing to 72 bits, and then P-1ing if needed.

As a compromise, once the last batch of candidates currently at 69 bits have been assigned, I'll remove the restriction so everyone has access to the few 69s Spidy still manages to find every day.

[QUOTE=chalsall;291575]I appreciate your and Bdot's perspective. Something to think about.

My change yesterday was a bit of an emotional response. To identify the elephant in the room, while many who only go from 6[8|9] to 70 are "big guns", there are also several smaller-throughput workers who tend to grab large numbers of low TFed candidates as they become available.

And please don't mis-understand me -- every cycle contributed is needed and appreciated. Not everyone can be a Craig, Xyzzy, Greg, Pete, et al...

However, I think it's important to remember that the whole point of G72 is to help GIMPS. And while finding factors is of course the ultimate goal, at the end of the day we don't really help GIMPS until we return candidates back to PrimeNet. That means TFing to 72 bits, and then P-1ing if needed.

As a compromise, once the last batch of candidates currently at 69 bits have been assigned, I'll remove the restriction so everyone has access to the few 69s Spidy still manages to find every day.[/QUOTE]

In my opinion, you don't have to. You have earned the right to run GPU to 72 however you see fit!

The only restriction it puts on me is that I have a HD 4870 that can't possibly run anything more than up to 69. It takes like 4 hours to run 68->69. It's not that big of a deal though, that system is probably due to be retired soon :smile:

[QUOTE=flashjh;291580]The only restriction it puts on me is that I have a HD 4870 that can't possibly run anything more than up to 69. It takes like 4 hours to run 68->69. It's not that big of a deal though, that system is probably due to be retired soon :smile:[/QUOTE]

Remember also that you can always do DC-TFing.

While not as important as LL-TFing, there are 48,000 candidates which need to be brought up from 67 bits in the 32-38M range. I'm bringing in a few thousand at a time while we're ahead of the DC wave front for those who enjoy such work.

Ah, never mind then. That's what that machine is doing. Chugging along at 4 to 6 per day.

[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]

No point, yet at least. Until we (by which I mean you) have control of all of them below a certain milestone, delaying them a month or two doesn't keep us from clearing hitting the goal any quicker. It'll probably take longer to get control of the rest of the exponents than it will to complete the ones we have at using the normal TF-first, LL afterwards, so it's not the limiting factor.

In fact, it actually slows things down overall if you have people doing duplicate work which we might end up throwing away.

So you know chalsall, it's taking me around four hours for each of those six candidates I grabbed, so we'll know by... roughly 0800 UTC if they have a factor in that range, so the workers can wait if they want to. (That's 2 am my time.)

Lots of Double Check Candidates without P-1... haven't seen that in a while.

edit: never mind... someone got them ;)

[QUOTE=flashjh;291649]Lots of Double Check Candidates without P-1... haven't seen that in a while.

edit: never mind... someone got them ;)[/QUOTE]

I don't see any no-P-1 in the available TF... :unsure: (even if it's assigned, it still shows up on the left, [strike]right[/strike] correct?)

[QUOTE=Dubslow;291654]I don't see any no-P-1 in the available TF... :unsure: [/QUOTE]
There were like 200 or so when I first posted, then it was going up to ~240. Then I refreshed and they went away.
[QUOTE](even if it's assigned, it still shows up on the left, [strike]right[/strike] correct?)[/QUOTE]
I don't rememeber...

I just requested a bunch of LLTF work to take to 71 and 72 bits using the Lowest Exponent option, and got a number of DCTF assignments around 30M. Only I'm assigned to take them to 71 or 72 bits, not 70 bits. Was this intentional? Or should I stop and unreserve these and grab new assignments?

Considering the amount of work we've put into steering people away from DCTF, I'd say this was definitely a mistake.

[QUOTE=frmky;291682]I just requested a bunch of LLTF work to take to 71 and 72 bits using the Lowest Exponent option, and got a number of DCTF assignments around 30M. Only I'm assigned to take them to 71 or 72 bits, not 70 bits. Was this intentional? Or should I stop and unreserve these and grab new assignments?[/QUOTE]

Under my current assignments 30M exponents show as DCTF which is correct, but on my [URL="http://www.gpu72.com/reports/worker/b49e80e9382626afc7ebe2f81662dadb/"]progress report[/URL] 'work done' chart, my DCTF is flat for the last few days even though I turned in several per day. The system seems to be confused about that range and treats them as LLTF.

I would turn them back in and when you make your request, set the minimum exponent to 40M.

[QUOTE=Dubslow;291686]Considering the amount of work we've put into steering people away from DCTF, I'd say this was definitely a mistake.[/QUOTE]
Agree

Speaking of this...
[QUOTE=Bdot;291550]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.[/QUOTE]

I've had much success with this pre-build. Any chance for a final version?

[QUOTE=frmky;291682]I just requested a bunch of LLTF work to take to 71 and 72 bits using the Lowest Exponent option, and got a number of DCTF assignments around 30M. Only I'm assigned to take them to 71 or 72 bits, not 70 bits. Was this intentional? Or should I stop and unreserve these and grab new assignments?[/QUOTE]

Whoops. Sorry -- that was an error. The new, lower load spider was used to grab a few hundred assignments in the 30M range, but set the worktype to be 100 rather than 101. Fixed.

But, yes please... Don't do that work -- unreserve them and get other work. The DC range definitly doesn't need to go to 72 bits!!! :smile:

[QUOTE=flashjh;291692]But on my [URL="http://www.gpu72.com/reports/worker/b49e80e9382626afc7ebe2f81662dadb/"]progress report[/URL] 'work done' chart, my DCTF is flat for the last few days even though I turned in several per day. The system seems to be confused about that range and treats them as LLTF.[/QUOTE]

No, it's not. If you look at your Work Done chart, you can see that the system is correctly detecting and graphing the (very small amount of) DCTFing you're returning. The line graph appears to be flat-lined simply because you haven't submitted enough work to be "worth a pixel" (:smile:).

[QUOTE=chalsall;291717]No, it's not. If you look at your Work Done chart, you can see that the system is correctly detecting and graphing the (very small amount of) DCTFing you're returning. The line graph appears to be flat-lined simply because you haven't submitted enough work to be "worth a pixel" (:smile:).[/QUOTE]

That's what that computer does too, a pixel's worth. Thanks.

Who took the two lowest 40M expos to 73? (Btw, no factor for any of my six.)

I just noticed that Spidey's new tricks also allowed it to get preferred DC expos. Are there any plans in place to clear those?

Mersenne.org seems to be down?! I can't submit anything.

Have you tried [URL]http://www.downforeveryoneorjustme.com/[/URL] ?

...Well, just pulling your leg. Of course [URL="http://www.mersenneforum.org/showthread.php?p=291596#post291596"]it is down[/URL].

[QUOTE=flashjh;291708]Speaking of this...


I've had much success with this pre-build. Any chance for a final version?[/QUOTE]

Not too soon. Oliver pointed out to me that the variable SieveSizeLimit causes the siever to run ~3% slower on Linux. On Windows this was not measurable (the Windows binary does not seem to be highly optimized anyway).

I need to do lots of measuring, trying out things ...
On the other hand, I could end up offering two (or more) different binaries for different CPUs ... would also allow to turn on CPU-specific optimizations in the compiler.

[QUOTE=Bdot;291849]Not too soon. Oliver pointed out to me that the variable SieveSizeLimit causes the siever to run ~3% slower on Linux. On Windows this was not measurable (the Windows binary does not seem to be highly optimized anyway).

I need to do lots of measuring, trying out things ...
On the other hand, I could end up offering two (or more) different binaries for different CPUs ... would also allow to turn on CPU-specific optimizations in the compiler.[/QUOTE]

I do not let the sieve size change on any of my PCs. I feel it is faster when I lock it down.

2 factors found (*yay*) in my last test-batch of 100 exponents GPU272, and still searching.
I'm wondering whether to submit them any time soon or not :)). (Just to play naughty...)

[QUOTE=sonjohan;291972]I'm wondering whether to submit them any time soon or not[/QUOTE]Delayed submission of results does not much other than increase risk of duplicated/wasted work. Submit results as often as is convenient.

I was just toying around. I think I got about 40 exponents or so done.
I'm happy to have found factors actually. It always leaves me with a bad feeling not finding anything.

Having an entire report with nothing but the same 'no factors found' gives me the impression mfaktc was just bored and copy-pasted the same sentence over and over again.

[QUOTE=sonjohan;291975]Having an entire report with nothing but the same 'no factors found' gives me the impression mfaktc was just bored and copy-pasted the same sentence over and over again.[/QUOTE]

I had never thought of it in those terms, but I know the feeling. The above creates an amusing image, though, of The Judger's wicked software :devil: messing with your head.

[QUOTE=sonjohan;291975]Having an entire report with nothing but the same 'no factors found' gives me the impression mfaktc was just bored and copy-pasted the same sentence over and over again.[/QUOTE]
As [URL="http://www.mersenneforum.org/showpost.php?p=279949&postcount=252"]I said before[/URL], I was hating the number 77 with all multiplies. Well, right when I succeeded to learn them by heart, mfaktc changed to v0.18, so now I start hating 73 with all his multiples, and learning them by heart.... 146, 219, 292, 365...:smile:

Not sure if that was discussed (and maybe fixed) before, but I now have the second instance of running DC work on 40-something-M exponents.

[code]
LL test successfully completes double-check of M45358927
CPU credit is 72.8027 GHz-days.
[/code]My other example was [B][URL="http://www.mersenne.org/report_exponent/?exp_lo=43007599"]43007599[/URL][/B] that I TF'd to 72 (with highest priority!) way after the first LL-check was done. And I see it still has "Assigned LL testing to "GPU Factoring" on 2011-02-07". AFAICS this one should be returned to primenet until the DC front reaches 43M.

Though it is not directly wasted resources, it still is not quite what I intended to do ...

Both still appear as LL TF / LL instead of DC TF / DC in my completed results / work done reports which makes me think GPU272 takes the size of an exponent and does not look at the status for categorizing work done on them?

Chalsall, maybe that is already done, but if not, could you please check that LL / LL TF assignments do not already have an "Unverified LL" test done on them?

I know when I made a post about 45000017, that one had in fact been tested once, but the first one had an error code, so PrimeNet marks it out for LL (not DC) assignment. Despite the error code, my test matched and so any trace of "Suspect LL" was thus erased. I'm guessing that's what happened here (and since the "Suspect" is erased on good DC, there's no way to be sure).

Edit: For reference, [URL="http://www.mersenne.org/report_exponent/?exp_lo=45000017&exp_hi=&B1=Get+status"]here's my expo[/URL], for which I'm sure the first test was "Suspect" before I turned my test in.

[QUOTE=Bdot;292078]Chalsall, maybe that is already done, but if not, could you please check that LL / LL TF assignments do not already have an "Unverified LL" test done on them?[/QUOTE]

G72 does go by the WorkType given by PrimeNet. LLs are reserved with a different spider than DCs, and are listed in the database as 100s and 101s, respectfully.

However, because "Spidy" is designed to collect expired exponents, there is the risk that the original assignee will complete the work after PrimeNet reassigns it to us. In addition, as Dubslow points out, PrimeNet will immediately reissue LL work when the previous effort's results were "Suspect". This knowledge disappears if the second LL test turns out to match the suspect results.

To minimize unnecessary work being done on assignments, Spidy now checks with PrimeNet once an hour, and will update it's knowledge when a LL turns into a DC. Or, worse, a DC turns into a "Proven". In the case of TF/P-1 candidates, the system will return any which are not assigned, and mark for return any which are currently assigned when they complete to whatever level they're pledged to.

In addition, I'm going to add a notice to people's "View Assignments" page if they're doing a "real" LL test on a candidate which becomes a DC, or (even worse) are doing a DC test which is no longer needed. Unfortunately there are currently a total of four -- I'll PM the individuals impacted as well.

I'm afraid there's not much beyond this I can do. There are simply going to be a (very) few cases where such situations occur.

[QUOTE=Dubslow;292123]I know when I made a post about 45000017, that one had in fact been tested once, but the first one had an error code, so PrimeNet marks it out for LL (not DC) assignment. Despite the error code, my test matched and so any trace of "Suspect LL" was thus erased. I'm guessing that's what happened here (and since the "Suspect" is erased on good DC, there's no way to be sure).

Edit: For reference, [URL="http://www.mersenne.org/report_exponent/?exp_lo=45000017&exp_hi=&B1=Get+status"]here's my expo[/URL], for which I'm sure the first test was "Suspect" before I turned my test in.[/QUOTE]
OK, this may have happened with the 45M exp of mine. But the 43M one still shows a clear "Unverified LL" state, yet GPU272 handed it to me as LL TF. It's not a big deal. I just think that it was not intended that way, and maybe can be caught by the system.

Chalsall, thanks a lot - that should cover most of these cases very well! And it is one more reason to concentrate on LL instead of DC ... then you'll still get the credit when you turn in the result (which may then be a DC one).

Do you have an explanation why 43007599 is still assigned as "LL testing to "GPU Factoring" on 2011-02-07"?

Yes, the 43M one is odd, but I remember like a month ago when we got the first wave of <45Ms, most of them were in fact DC candidates, and as I recall, we're still not sure why PrimeNet assigned them as DC candidates. That's something that has as yet gone unsolved. (I don't know why that one is still held by GPU272.)

I remember there was a discussion about PrimeNet server confusing TF factors with P-1 factors, for bigger factors which fall over its TF-limit cutoff. I can not find that discussion, maybe someone can point me to it. I have looked in related threads (p95, gimps, server, etc) but at the end the factors I found in the last time were done under gpu-2-72 project, so I decided to post here. My dilemma is like that:

I have reported
[CODE]
Manual testing 30946609 F 2012-03-07 13:17 0.0 541996012842777321943 3.6199
Manual testing 30946441 F 2012-03-07 13:17 0.0 370279690461888625657 2.5581
Manual testing 30987637 F 2012-03-07 07:36 0.0 310149215308792133399 2.0615
Manual testing 30603973 F 2012-03-06 17:10 0.0 480678252080857673159 3.3221
Manual testing 30037489 F 2012-03-01 15:34 0.0 319103639527297121881 2.2084
Manual testing 30939407 F 2012-03-01 11:41 0.0 314781084386270804327 2.1060
Manual testing 30938429 F 2012-03-01 00:33 0.0 567188230459976620057 3.7475
Manual testing 30566929 F 2012-02-29 18:37 0.0 351439136952867720439 2.4425
Manual testing 30958133 F 2012-02-29 15:49 0.0 383911472785050228289 2.6578
Manual testing 30917287 F 2012-02-29 15:49 0.0 569839859834256833551 3.7631
Manual testing 30565753 F 2012-02-27 11:54 0.0 476887570104844591409 3.3039
Manual testing 30565627 F 2012-02-27 11:54 0.0 379975074935690511911 2.6629
Manual testing 30954299 F 2012-02-26 02:06 0.0 340900192216659318823 2.3271
[/CODE]but...
[CODE]Manual testing 30924497 F-PM1 2012-03-06 11:13 0.0 325158435139110861601 1.3727
[/CODE]What is the mystery? They were all found by mfaktc and reported "by hand", it is not related to size of the expo, size of the "k", size of the factor, time of day, etc. Then is related to what? (I deliberately selected the expos above, in the same range, having about the same size of the factors, being reported at different times, etc).

I don't care about 1.5 GHz-day credit difference, but I know there is some dilemma about this and maybe I can cast a spark... :P

We've known for sometime that it's only a PrimeNet issue, and only fixing PrimeNet will fix the issue. We're mostly just waiting for James to [URL="http://www.mersenneforum.org/showthread.php?p=290902#post290902"]setup a WIMP environment[/URL], but as you can see he's having trouble.

Thanks Dubslow, that discussion is what I was looking for.

[QUOTE=Dubslow;292305]We're mostly just waiting for James to [URL="http://www.mersenneforum.org/showthread.php?p=290902#post290902"]setup a WIMP environment[/URL], but as you can see he's having trouble.[/QUOTE]Sorry :redface:

The good news, however, is that I've successfully set up a WIMP->LAMP wrapper, so I'm now able to work through the code. I've made good progress so far, but I haven't worked though to the manual_results section yet. Out of curiosity, I want to look through that code and figure out why TF-PM1 credit gets mixed up, but honestly I'll probably just replace much of that code with the results parser from [url=http://mersenne-aries.sili.net]mersenne-aries.sili.net[/url] since I know that works well.

[QUOTE=LaurV;292301]What is the mystery?[/QUOTE]Excellent question, good example. I'll look at the code and let you know. :smile:

[QUOTE=James Heinrich;292321]but honestly I'll probably just replace much of that code with the results parser from [url=http://mersenne-aries.sili.net]mersenne-aries.sili.net[/url] since I know that works well.[/QUOTE]

Oooohh, will that also make it as fast as your site, or is the speed more a hardware or (WI) thing?

[QUOTE=LaurV;292301]What is the mystery? [/QUOTE]

I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.

[QUOTE=Bdot;292374]I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.[/QUOTE]
This could be a very interesting observation! I remember I submitted a single factor exactly once! But I do not bet is the factor in cause, or another. But very good observation! I will watch for it.

[QUOTE=Bdot;292374]I noticed that my factors were usually just "F" when the "factor found" line was surrounded by "no factor found ... mfakto ..." lines.

I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.

But I do not find enough factors to validate this observation.[/QUOTE]

I did a similiar thing, I pulled the factor found lines out before the spider uploaded and put them in a file which I manually uploaded thinking I could get the correct credit. They were credited as P-1's. If I had submitted the entire file rather than edit those out, they would have been credited as TF.

[QUOTE=Bdot;292374]I just recently submitted a single "factor found" result without preceeding "no factor" lines, and that became a "F-PM1" again.[/QUOTE]You've more-or-less got it. After looking quickly through the current code, it goes something like this (simplified, leaving out many details):[code]if (previously_found_mfaktco_nofactor_lines AND length(factor) <= 23) {
handle_as_TF_factor()
} else if (exponent < 16,000,000) {
if (factor_bits > 55) {
handle_as_ECM_factor()
} else {
handle_as_TF_factor()
}
} else {
if (factor_bits < default_tf_limit(exponent)) {
handle_as_TF_factor()
} else {
handle_as_PM1_factor()
}
}[/code]The key point, it seems, is to make sure that there's at least one mfaktc/mfakto non-factor line in the submitted results (it doesn't actually matter if it comes before or after the factor line). This puts the results-parser into "mfakt[co]-mode" where it will accept large factors as TF. Otherwise any factor over the default TF limit will be assumed to be P-1.

Hmm... doesn't seem to be code that actually reads what the results lines are saying. Presuming your code does that, then I vote for that.

Just an update, my farm is likely to go down for a day or two in the next week or so.

The power company mailed me to say my power is going out for maintenance work.

I hope this doesn't cause any issues.

Also, you should see LL TF results coming from my farm now. DCTF work from my farm should slowly drop over the next couple of days.

-- Craig

You know you're important when you post (way) ahead of time when you're offline so that no one freaks out.
:smile:

[QUOTE=nucleon;292465]Just an update, my farm is likely to go down for a day or two in the next week or so.

The power company mailed me to say my power is going out for maintenance work.

-- Craig[/QUOTE]
No UPS and Diesel generator (yet)?

[QUOTE=Bdot;292469]No UPS and Diesel generator (yet)?[/QUOTE]

Diesel generator? We need our exercise, he should have a bicycle hooked to a generator, fewer greenhouse gases as well. (Unless he had beans for dinner)

^^ heehee

[URL="http://gpu72.com/reports/worker/6e67460a77a11a707a665a6270df1a82/"]oh boy[/URL]


@chalsall: There are 5 expos at 70 bits in the 25M range that have been reported as "available" for a few days. Do they need to be distributed for testing?

[YOUTUBE]ZmzeKNiMkAs[/YOUTUBE]

[QUOTE=nucleon;292465]Just an update, my farm is likely to go down for a day or two in the next week or so.

The power company mailed me to say my power is going out for maintenance work.[/QUOTE]

You know you're important when the power company has to upgrade their Transmission and Distribution network to supply your cluster.... :smile:

Is this a glitch or something?

[COLOR=red]Warning:[/COLOR]
[LIST][*][COLOR=red]1 of your Double Check assignments have been completed by another worker. These are highlighted in red below with a double-dagger (‡).It would be best if you stopped working on these and unreserved them, as the work is no longer needed.
[/COLOR][/LIST]...
[B][URL="http://www.mersenne.org/report_exponent/?exp_lo=26059867"]26059867[/URL][/B] Double Check 69 N/A[COLOR=red] ‡ [I][B]2012-03-07 05:21:30[/B][/I][/COLOR]

Sheesh - it was completed by me!

[QUOTE=Batalov;292489]Is this a glitch or something?

Sheesh - it was completed by me![/QUOTE]

Sort of... The warning is a new sanity check I introduced a few days ago. The reason you received it is "Spidy" didn't know your PrimeNet display name, and so didn't detect that it was actually you who completed the work. I've "told" Spidy your PNDN, and this completion has now been detected and credited to you.

@chalsall
For some of us the "completed" reports are getting very big. That would not be a problem in itself, but they are not sortable (by assignment date, completion date, whatever) and looking for expos could be difficult. Can they be "sortable"? That is the table having clickable column heads. And/or display limit (like "show the last 1000") by default. The PrimeNet has this too, and if you want more you must dig the "customization" stuff. I think "the last 1000" completed results would be ok by default, covering the last few days and also making the page load faster.

@LaurV...

The completed report [B][I]is already[/I][/B] limited to the last 1000 records.

But, yes, I could make the columns sortable.

Do people also want to have access to more than 1000 records?

[QUOTE=chalsall;292518]
Do people also want to have access to more than 1000 records?[/QUOTE]
Not me. It looks unlimited for me already :D I didnt realized is limited :blush:

It would be neato if this page was able to be sorted by column:

[url]http://gpu72.com/reports/workers/[/url]

:smile:

[QUOTE=chalsall;292518]@LaurV...

The completed report [B][I]is already[/I][/B] limited to the last 1000 records.

But, yes, I could make the columns sortable.

Do people also want to have access to more than 1000 records?[/QUOTE]

I have never needed the whole list before, but I have needed to search for some completed exponents that were off the list already.

[QUOTE]Do people also want to have access to more than 1000 records?[/QUOTE]Sure!

:smile:

I got the first two of my LL's below M46 completed. If you've been watching, the milestone count dropped 2 today :smile:

Gpu72.com is down.

[QUOTE=garo;292701]Gpu72.com is down.[/QUOTE]

Appears fine to me. What are you seeing?

[QUOTE=chalsall;292719]Appears fine to me. What are you seeing?[/QUOTE]

It is up now, but it was definitely down for me this morning as well.

[QUOTE=KyleAskine;292724]It is up now, but it was definitely down for me this morning as well.[/QUOTE]

Hmmm... That's a bit strange. The system has an uptime of over two weeks (read: it didn't crash), and my SSH sessions are still up. Additionally, the [URL="http://www.gpu72.com/reports/overall/graph/hourly/"]Hourly Completions Graph[/URL] shows Spidy was talking to PrimeNet throughout the night.

It might have been a DNS issue. My DNS provider gave notice they were going to be doing maintaince at around this time, but promised that domain resolution would not be effected.

Yes it was most likely a DNS issue. I was able to access mersenne.info at the same time.

[QUOTE=chalsall;292480]You know you're important when the power company has to upgrade their Transmission and Distribution network to supply your cluster.... :smile:[/QUOTE]

This gave me a giggle. :) For more detail, the power company is replacing the meter with a 'smart meter', which in tech terms is time based charging. My power bill may go down. But that maybe wishful thinking.

I don't see myself as important.

I guess it's the way I'm programmed from my job. I'm in network operations. So Outage -> send outage notification. It's sort of an reflex action :)

-- Craig

[QUOTE=Xyzzy;292520]It would be neato if this page was able to be sorted by column:

:smile:[/QUOTE]

And I have reason to beleive I know why you wanted a page like [URL="http://www.gpu72.com/reports/workers/saved/"]Workers' Overall Progress sorted by GHz Days Saved[/URL]... :smile:

[QUOTE=chalsall;292913]And I have reason to beleive I know why you wanted a page like [URL="http://www.gpu72.com/reports/workers/saved/"]Workers' Overall Progress sorted by GHz Days Saved[/URL]... :smile:[/QUOTE]Nice. :smile:

Would I get yelled at if I asked about an efficiency ranking table; ordered by saved/effort desc? :unsure:

Those who do only P-1 would win hands down.

[QUOTE=Dubslow;292922]Those who do only P-1 would win hands down.[/QUOTE]

Yeah... That's why, when I do that (it's a good idea), I will use the "normalized" transform for GPU work like I have for the Overall System Status report...

(Let the argument about what is the appropriate coefficient restart.... :smile:)

[QUOTE=chalsall;292924]Yeah... That's why, when I do that (it's a good idea), I will use the "normalized" transform for GPU work like I have for the Overall System Status report...

(Let the argument about what is the appropriate coefficient restart.... :smile:)[/QUOTE]

Looks like 'Eric Christenson', 'hellrider', and 'sflicker' all win!

[QUOTE=chalsall;292924]
(Let the argument about what is the appropriate coefficient restart.... :smile:)[/QUOTE]
Remember that CSV you made available? I never did get around to importing it to Calc, but you ought to be able to get an estimate of GPU272's overall coefficient from that data. (Craig and such are balanced by monst and such, I think it's a pretty even mix.)

I've got vision...
 

[QUOTE=garo;292740]Yes it was most likely a DNS issue. I was able to access mersenne.info at the same time.[/QUOTE]
...while the rest of the world wears bifocals.

(Ask William)

David

PS I've got a cold.
Beam me up a Scottie.
(Krankies)

Weehoo!
 

Going through recent results and found this:

[url]http://www.mersenne.org/report_exponent/?exp_lo=47908067[/url]

A test completed after we got to it!

See what we mean davieddy?

[QUOTE=Dubslow;292960]Going through recent results and found this:

[URL]http://www.mersenne.org/report_exponent/?exp_lo=47908067[/URL]

A test completed after we got to it!

See what we mean davieddy?[/QUOTE]
More info:
[CODE]
Member Name Computer Name Exponent Type UTC Time Received Days GHz-days Result
-------------------- ---------------- --------- -------- ------------------- ----- -------- -------------------------------------------------
Windessy render3 47908067 C Mar 14 2012 4:54AM 22.1 83.1737 CEEC5F2EE9213D__
[/CODE]

For [URL="http://gpu72.com/reports/factor_percentage/"]this page[/URL] it could be better to use Bayesian estimates.

See the formula at the bottom of the [URL="http://www.imdb.com/chart/top"]IMDb rating page[/URL]:
[QUOTE="Bayes"][FONT=Arial, Helvetica, sans-serif][SIZE=-1][B]true Bayesian estimate[/B]: [/SIZE][/FONT][FONT=Arial, Helvetica, sans-serif][SIZE=-1]weighted rating (WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C [/SIZE][/FONT][FONT=Arial, Helvetica, sans-serif][SIZE=-1] where:
[LIST][*] R = average for the movie (mean) = (Rating)[*] v = number of votes for the movie = (votes)[*] m = minimum votes required to be listed in the Top 250 (currently 3000)[*] C = the mean vote across the whole report (currently 6.9) <-- can use MO here[/LIST][/SIZE][/FONT][/QUOTE]
For the cells with many observations, the formula changes almost nothing, for cells with just 1 or 2 factums, the MO will be shown. This takes care of the swings: both into 0.000's (e.g. 0 successes out of 15 trials) or into unrealistic 1.000's (1 success out of 1 lucky trial)
:two cents:

[url]http://www.mersenne.org/report_exponent/?exp_lo=45571159[/url]

That exponent in particular, and many more if [url]http://www.mersenne.org/primenet/[/url] is anything to go by, are reserved for Trial Factoring and [i]not[/i] reserved as LLs. Is this a result of the discussion between George and Chris? Because if so, I approve :smile: (I've been wondering for a while what sort of impact we'd have on PrimeNet if we got ahead of the LL wave but were still reserving expos as LL.)

My questions are, how does Spidey find low expos that aren't reserved for LL? Does it still reserve them as LL and then immediately unreserve/rereserve as TF? Does Spidey get special treatment from PrimeNet to make sure a candidate isn't lost again?

Heehee
[code]
Factors Found
P-1 404[/code]

[QUOTE=Dubslow;293158]Is this a result of the discussion between George and Chris? Because if so, I approve :smile:[/QUOTE]

And if it wasn't because of a discussion between George and myself, would you disapprove? :smile:

This is something I've been wanting to do for a while. Several people (including you and davieddy) have complained on the negative impact we've been having on the /primenet/ report. I didn't like it myself.

[QUOTE=Dubslow;293158]My questions are, how does Spidey find low expos that aren't reserved for LL? Does it still reserve them as LL and then immediately unreserve/rereserve as TF? Does Spidey get special treatment from PrimeNet to make sure a candidate isn't lost again?[/QUOTE]

Answers in order:

1. Spidy uses a variety of techniques to get candidates.

2. Some are still reserved as LL/DC, but are then shortly later unreserved/rereserved as TF.

3. Spidy gets no special treatment from Primenet. But the transfer window is less than a second, and if we lose a candidate in the process it's not the end of the world.

4. To answer an unasked question: in order to transfer those candidates which were already owned by workers while minimizing the loss risk I waited until after midnight UTC when a lot of "low-hanging fruit" became available, and then ran the transfer script from lowest to highest candidates.

4.1. This was a one-off event -- the assignment scripts only assign work which are already reserved from PrimeNet as TF.

5. To answer another unasked question: yes, I will soon be doing the same thing for the P-1 work type.

Sweet!

[QUOTE=chalsall;292913]And I have reason to beleive I know why you wanted a page like [URL="http://www.gpu72.com/reports/workers/saved/"]Workers' Overall Progress sorted by GHz Days Saved[/URL]... :smile:[/QUOTE]

Yep, sort is working fine now :)

-- Craig