![]() |
[QUOTE=davieddy;302068]So why isn't every exponent >53M TFed to 72 at least?
Because you won't listen.[/QUOTE] Hmm, considering 114468691 NF 2012-06-13 22:47 0.9 no factor from 2^65 to 2^66 is where the LMH is currently at, it'd be rather difficult to get every exponent >53M to 72 (and I'd hate to get started on infinity). Seriously though, when I started with GIMPS, I was assigned 54-56M exps (and this was Oct last year). More recently I have gottten 48-53M TF'd to ^72 from primenet (I can get lower via GPU72, but I haven't bothered with that system), which shows we are making a difference. The bottom line though is that unless George changes the LL assignment rules, we will still end up with 'under TF'd' assignments getting handed out since the system is basically set up to hand out assignments more on breadth than on TF level. Since a 53M (or lower) exp TF'd to 71 will be handed out before 5000 54-58M exp's TF'd to 72, it amazes me how you can blame us for that. |
[QUOTE=Uncwilly;302218]:cmd:
That discussion is about tombs, plural not singular.[/QUOTE] The discussion is about preaching the opposite to what you "really" believe. David |
[QUOTE=davieddy;302170]I rest my case.[/QUOTE]
The case is resting. Is now the time to spit in the fan? Snakes and gerbils hate cleaning up. |
[QUOTE=bcp19;302221]The bottom line though is that unless George changes the LL assignment rules, we will still end up with 'under TF'd' assignments getting handed out since the system is basically set up to hand out assignments more on breadth than on TF level. Since a 53M (or lower) exp TF'd to 71 will be handed out before 5000 54-58M exp's TF'd to 72, it amazes me how you can blame us for that.[/QUOTE]
Just to speak to this, for the clarity of everyone... While it is true that PrimeNet continues to hand out assignments below 72 "bits", it should be noted that almost all of them are picked up by Spidy for processing by the GPU72 project. If you look at the [URL="http://mersenne.org/primenet/"]PrimeNet Exponent Status Distribution[/URL] report, every single candidate in the Available columns for P-1 and LL below 58M are already at 72 bits or above. This means when someone asks for LL work, it will almost always be at 72 bits or above, and often will have had P-1 done. Additionally, all assignments for P-1 work from PrimeNet will also already be at 72 bits or above. At our current rate, we should clear out everything we hold below 58M in [URL="http://www.gpu72.com/reports/estimated_completion/"]about 11 days[/URL]. Taking into account that some are now working above 58M (mostly to 73), a more realistic estimate is around 15 days. Now, every night PrimeNet expires many candidates (approximately 800 a day), some of which are below 72 bits. While this is usually only a few dozen or so, last night (for example) there were approximately 600 which needed additional TFing. But, even if we were given every single candidate to process, it would still only take us [URL="http://www.gpu72.com/reports/estimated_completion/primenet/"]about 24 days[/URL] (or 36 days realistically). Additionally, it is worth noting that this means that less than 25% of all assigned LL work is ever actually completed. Lastly, before a certain person accuses us of "hording" candidates, I would like to point out that the oldest candidate we currently own below 58M but which is not yet assigned for processing is exactly one month old. Additionally, we are currently processing and returning to PrimeNet more than four times as many candidates as are having LL completed. We are definitely now pulling ahead of the "wave". |
I'm curious why about 3 weeks ago this: [url]http://www.gpu72.com/reports/estimated_completion/primenet/[/url]
was under 100 days, then it jumped back to over 120 days. Was there a large batch of TF assignments dropped by someone or did something cause your estimation calculation to change or ??? |
[QUOTE=petrw1;302263]I'm curious why about 3 weeks ago this: [url]http://www.gpu72.com/reports/estimated_completion/primenet/[/url]
was under 100 days, then it jumped back to over 120 days.[/QUOTE] Based on the analysis of James as to where the "curves cross" for going to 73, I changed the cross-over point from 58.52M to 58.00M. I plan in a couple of months (once we've mostly cleared out everything from 58M to 60M to 73 bits) to bring back into the system candidates between 57.5M to 58M for processing from 72 to 73, for those willing to do so. By that time it will be a bit like it is now in the DC range (where we're currently over 500 days ahead of the wave) and we can take our time doing the work, and offer different ranges for people to do the work they enjoy. |
I probably should know this but does GPUto72/spidey grab all released exponents for TF to 72+ or only those that do not already have a LL test done?
|
[QUOTE=petrw1;302266]I probably should know this but does GPUto72/spidey grab all released exponents for TF to 72+ or only those that do not already have a LL test done?[/QUOTE]
The latter. Additionally, if the system detects that a LL result is submitted for a candidate we hold (thus becoming a DC candidate) it will release it. |
Hmmm...
So tonight PrimeNet released 92 candidates below 53M which needed additional Trial Factoring which Spidy collected for some loving attention. Anyone have a problem with that? |
[QUOTE=chalsall;302321]Hmmm...
So tonight PrimeNet released 92 candidates below 53M which needed additional Trial Factoring which Spidy collected for some loving attention. Anyone have a problem with that?[/QUOTE] I think I picked up a fair share of them, so no :D I notice I got a couple 25M as well that need a couple bits |
[QUOTE=bcp19;302322]I notice I got a couple 25M as well that need a couple bits[/QUOTE]
And there are a couple of "eager beavers" willing to take on the 25Ms once you're done TFing them, even though they might be "poached". These guys have some serious hardware to throw at the candidates; might make the poacher waste his time.... |
| All times are UTC. The time now is 23:15. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.