|
:rant:
|
[QUOTE=nucleon;293239]Yep, sort is working fine now :)[/QUOTE]
Seems to be broken again... :smile: Also, it's fun watching Pete and Greg keep switching between the [URL="http://www.gpu72.com/reports/workers/graph/3-12/"]#3 and #4[/URL] positions.... |
[QUOTE=chalsall;293316]Seems to be broken again... :smile:
Also, it's fun watching Pete and Greg keep switching between the [URL="http://www.gpu72.com/reports/workers/graph/3-12/"]#3 and #4[/URL] positions....[/QUOTE] I'm glad we can keep you amused. |
[QUOTE=bcp19;293319]I'm glad we can keep you amused.[/QUOTE]
What can I say... I don't get out much.... :smile: |
Change to P-1 assignment policy...
Hey all. So everyone knows... I was doing a review of current P-1 assignments, and found some issues...
Some users have some [U][I]very[/I][/U] old assignments still outstanding, even though they are currently reserving new work. Others have bitten off a bit more than they can reasonably "chew"... Additionally, I think it's unreasonable for P-1 assignments to be valid for three months, when it only takes at most a couple of days per modern core. That was short-sighted of me when I implemented the P-1 option. So, I have added the same type of sanity check when people try to register new P-1 assignments as already exists for TF work -- if someone has old assignments, or more than they can process within a month, they are warned rather than given more. I will "grandfather" current assignments, but new assignments (as of tomorrow) will expire after one month unless extended. I haven't yet, but will add highlighted notices of those P-1 assignments which are past due on the View Assignments page. Also, P-1 assignments are now only available for candidates which have already been trial factored to 72 or more bits. My thinking here is it doesn't make sense to do a more expensive P-1 run when a much more efficient GPU TF run could find the low factors. In addition, to have the P-1 assignments appear as such on PrimeNet they will have to be transfered to another "state", and I don't want to lose any which have not already been maximally TFed. Lastly, just so people know, as Dubslow predicted, we currently have more P-1 work than we can handle, and are thus beginning to throw back to PrimeNet those canadidates we can't reasonable handle within about a week. The good news here is it seems there are many P-1 workers taking the work through PrimeNet rather than them going to LL workers. As always comments, and/or corrections to my thinking, welcomed and encouraged. |
:goodposting:
[QUOTE=chalsall;293336] I will "grandfather" current assignments, but new assignments (as of tomorrow) will expire after one month unless extended. I haven't yet, but will add highlighted notices of those P-1 assignments which are past due on the View Assignments page. [/quote]When is "past due"? I would guess a month, but that's when they expire, not when we'd get a warning. I think two weeks after assignment would be a good time to highlight, what do the rest of you think? (Regarding why I reserved 100 a few days ago, this week is my spring break and lugging my desktop around didn't seem too appealing. :smile: I think it may be a bit more than a week of work, but then I don't think it's more than two weeks. Suggestion: As with TF, estimate how many days of P-1 we have reserved? That would be a good tool. (In fact, that's how I counted how much TF I needed for a week.)[QUOTE=chalsall;293336] Lastly, just so people know, as Dubslow predicted, we currently have more P-1 work than we can handle, and are thus beginning to throw back to PrimeNet those canadidates we can't reasonable handle within about a week. The good news here is it seems there are many P-1 workers taking the work through PrimeNet rather than them going to LL workers. [/QUOTE] I would actually like to propose that you don't release any: At the moment, there are 20.8K candidates that need P-1; our current rate suggests [URL="http://www.wolframalpha.com/input/?i=20800%2F%2880+per+day%29"]we could clear that in 8 months[/URL]... okay, maybe we should release the higher expos. Keep in mind however that there are many more expos that we don't have that still need P-1, so I would not be worried in any way about overloading the non-GPU272 P-1 workers. [QUOTE=chalsall;293336]In addition, to have the P-1 assignments appear as such on PrimeNet they will have to be transfered to another "state", and I don't want to lose any which have not already been maximally TFed.[/quote] Why bother re-reserving them as P-1? As long as it's not reserved as LL, I say it's not worth the risk of losing it to PrimeNet if it already is listed as "Trial Factoring". Otherwise, agreement! |
[QUOTE=chalsall;293336]Also, P-1 assignments are now only available for candidates which have already been trial factored to 72 or more bits. [/QUOTE]
This would improve P-1 thruput, since P95 will be choosing lower bounds. |
1 Million
Done
1000,140 |
[QUOTE=chalsall;293336]Also, P-1 assignments are now only available for candidates which have already been trial factored to 72 or more bits.
As always comments, and/or corrections to my thinking, welcomed and encouraged.[/QUOTE] Are you sure there will be enough for all the P-1 workers? Last year when I was doing P-1 on GPUto72 I often had to take P-1 assignments at lower bit levels because there were NONE at 72 bits. |
There are now more than a thousand candidates at 72 bits. It's been slowly building up for the last week. (Two days ago it was at 850.)
|
[QUOTE=chalsall;293336]Hey all. So everyone knows... I was doing a review of current P-1 assignments, and found some issues...
Some users have some [U][I]very[/I][/U] old assignments still outstanding, even though they are currently reserving new work. Others have bitten off a bit more than they can reasonably "chew"... As always comments, and/or corrections to my thinking, welcomed and encouraged.[/QUOTE] I'm possibly more or less not definitely rejecting the idea that I undeniably do or do not know that it's possible that it could or could not be me :unsure: [COLOR=black][FONT=Verdana]With that, chalsall, I apologize for the overzealous P-1 reservations. No need to get into reasons. I can unreserved and start over or finish what I have. Let me know the best way ahead...[/FONT][/COLOR] |
[QUOTE=Dubslow;293338]At the moment, there are 20.8K candidates that need P-1; our current rate suggests [URL="http://www.wolframalpha.com/input/?i=20800%2F%2880+per+day%29"]we could clear that in 8 months[/URL]...[/QUOTE]
[QUOTE=petrw1;293345]Are you sure there will be enough for all the P-1 workers? Last year when I was doing P-1 on GPUto72 I often had to take P-1 assignments at lower bit levels because there were NONE at 72 bits.[/QUOTE] [QUOTE=Dubslow;293348]There are now more than a thousand candidates at 72 bits. It's been slowly building up for the last week. (Two days ago it was at 850.)[/QUOTE] Ya know... petrw1, you've previously said you can do 15 a day, right? Well, if I underestimated our current throughput and you went back to P-1... We could clear the current backlog in [URL="http://www.wolframalpha.com/input/?i=20800%2F%28100+per+day%29"]a bit less than 7 months[/URL]... |
[QUOTE=flashjh;293351]I'm possibly more or less not definitely rejecting the idea that I undeniably do or do not know that it's possible that it could or could not be me :unsure:
I can unreserved and start over or finish what I have. Let me know the best way ahead...[/QUOTE] I wasn't singling you out -- I wrote a quick report for the G72 "admin" area which showed a dozen different individuals who had reservations beyond the new policy's range -- two (not you) with rather extremely old assignments. But, in your case, I think it would be best if you unreserved some, and let the system process them or pass them back to PrimeNet as appropriate. If you try to reserve some more now, you'll see just how long it is expected what you have currently assigned will take you to do. On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days. |
[QUOTE=Dubslow;293338]When is "past due"? I would guess a month, but that's when they expire, not when we'd get a warning. I think two weeks after assignment would be a good time to highlight, what do the rest of you think?[/QUOTE]
I "spoke" too quickly as I was being called to dinner by "She who must be OKed...". :smile: The warning highlighting currently kicks in at 25 days after assignment, with the "past due" (and automatic expiry unless there are "special circumstances") being 31 days after assignment. |
[QUOTE=chalsall;293356]I wasn't singling you out --[/QUOTE]
I know... Now that my main P-1 system seems stable, I've been looking over my assignments the last few days and realized there was no way I could get them done in time unless I extended them. I had thought about unreserving some anyway. [QUOTE]I wrote a quick report for the G72 "admin" area which showed a dozen different individuals who had reservations beyond the new policy's range -- two (not you) with rather extremely old assignments. But, in your case, I think it would be best if you unreserved some, and let the system process them or pass them back to PrimeNet as appropriate. If you try to reserve some more now, you'll see just how long it is expected what you have currently assigned will take you to do. On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days.[/QUOTE] Over the next few days I'll unreserve stuff that is old and rebuild my worktodo files. |
Small request: Can you put a link to the "Individual Worker's Progress" page on the left under the "My Account" heading?
|
[QUOTE=Dubslow;293353]Ya know... petrw1, you've previously said you can do 15 a day, right? Well, if I underestimated our current throughput and you went back to P-1...[/QUOTE]
Well I do miss the feeling of being a major contributor...except for two things: 1. There was a fair bit of manual effort 2. Our home system (Q9500) really took a beating trying to run 4 X P-1. My current project is DC (any I can snag under 26M) plus GPUto72 DC. I was hoping to compete 1,000 this year but I am lower on hardware than I had anticipated. First I need job then I need a Sandy/Ivy. I plan to stick to DC all year or until the DC collective clears up to 30M whichever comes first. Then maybe P-1 again??? |
[QUOTE][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][/QUOTE] Well, this is new! And it is welcomed, too, so I would know and don't waste my time. For the exponent in cause 26247811, it was me who finish it, but I did not check if I am logged in when I reported it... |
[QUOTE=chalsall;293356]I wasn't singling you out -- I wrote a quick report for the G72 "admin" area which showed a dozen different individuals who had reservations beyond the new policy's range -- two (not you) with rather extremely old assignments.
But, in your case, I think it would be best if you unreserved some, and let the system process them or pass them back to PrimeNet as appropriate. If you try to reserve some more now, you'll see just how long it is expected what you have currently assigned will take you to do. On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days.[/QUOTE] I know I accidentally reserved 2 months worth, and the ones I have remaining will be done within the next month. |
[QUOTE=chalsall;293356]On a related matter, this "driving problem" gave me the incentive to codify a much smarter GHzDays / Day heuristic for the different Work Types, which I will expose the results of over the next few days.[/QUOTE]
OK... This information is now being rendered on everyone's View Assignments page. Note that the "GHz Days per Day" value is calculated differently than the simple "30 day running average" on the graphs. It takes into account the total amount of work done divided by the total number of days assignments were out (for each work type class). Thus, the "GHz Days per Day" value will be less than the "30 day running average", particularily for the DC/LL work class where the assignments will be out for some period of time before the first result is submitted. This is to handle situations like what Ethan encountered, where he did a large batch of TF work, and then stopped for several months before returning. |
The heuristics box is another much appreciated tool for keeping track of assignments. It's nice to have statistics for all active assignments in one place.
|
The number formatting seems funny, leading decimals and such. I have, for example:
GHz Days per Day TF: ".150.38" GHz Days TF: "2.192.42" GHz Days P-1: ".711.52" |
[QUOTE=James Heinrich;293399]The number formatting seems funny, leading decimals and such.[/QUOTE]
Whoops... Bad regex! Bad! Thanks for pointing that out. |
I have a stupid question! Probably already been answered, but...how hard would it be to translate p95's P-1 algorithm to a GPU? Or is a GPU incapable due to low memory access? Short answer is all thats needed, thanks!
|
[QUOTE=c10ck3r;293427]I have a stupid question! Probably already been answered, but...how hard would it be to translate p95's P-1 algorithm to a GPU? Or is a GPU incapable due to low memory access? Short answer is all thats needed, thanks![/QUOTE]
Not terribly hard. The "easiest" way would be to create a version of the gwnum library that uses CUDA. At first it would support only Mersenne numbers. Supporting all the k*b^n+/-c variations that the gwnum library library supports would be quite a bit harder. I'm not sure how many temporaries could be allocated on the GPU. |
Wouldn't you just use CUFFT like CUDALucas? In fact, isn't Stage 1 basically the same as the LL test, except instead of calculating Sn^2 modM, you calculate 3^E modM (where E is a large primorial), which can be done as a series of M size multiplications? In other words, all you need to do is change the input data to the FFT, but otherwise it's the same. Obviously Stage 2 is a bit harder with the memory and I'm not sure about the math, but it still seems like CUDALucas would be a good basis.
|
E is not a big primorial, you can see it like a product of primorials if you like, and everything times p. Of course you could use cufft to do the multiplications, but you don't get any speedup as you need to transfer the data to gpu memory everytime. I raised this question sometime ago and some guy with better knowledge (sorry, I forgot who was, but the discussion is here around) argued that transfer with global/constant/texture memories (one per grid) is 500 times slower then working with registers and shared memory (one inside of each block on the grid). In fact mfaktc is many times faster then a CPU-competitor (10, 20, 50, 100 times) because it takes advantages of working inside of these blocks (see GPU-Z: there is no memory activity with mfaktc), but CudaLucas is not more than 2-3 times faster than a CPU-competitor, because it needs to transfer data back and forth after every iteration, data is too big to be stored in shared memory (and if you look to GPU-Z, you will see memory activity to 50-60% always!).
|
Huh. Is there any way to get directly to the registers with CUDA? I guess so, since mfaktc appears to be capable of doing it.
|
Hi chalsall,
What are the new P-1 limits? I usually put 5-10 P-1 assignments per worker into the worktodo file, which obviously crosses some threshold you have established: [code] Sorry Bdot, but you already have too many assignments. Since you joined the project you have done on average 8.59 GHz Days of P-1 Factoring work per day. You currently have 41 assignments totalling 189.29 GHz Days of work assigned, or 22 days worth based on your history. The oldest is 45 days old[/code]Allowing less than 22 days of P-1 seems a little tight to me. I rebalanced some assignments so the worker which was running low can continue ... Lets see how often I bump into the limit. |
[QUOTE=Bdot;293485]Allowing less than 22 days of P-1 seems a little tight to me.[/QUOTE]I don't think it's the 22 days of work, I think it's that the oldest one you have is 45 days old.
|
[QUOTE=James Heinrich;293487]I don't think it's the 22 days of work, I think it's that the oldest one you have is 45 days old.[/QUOTE]
Indeed, the oldest assignments should be cleaned first, at least for the reason that you can lose them... |
[QUOTE=Bdot;293485]What are the new P-1 limits? I usually put 5-10 P-1 assignments per worker into the worktodo file, which obviously crosses some threshold you have established.[/QUOTE]
If you look back on this thread, you'll see the new limits. Basically I'm bringing the allowed quantity, and age, down to one month. The problem you're facing, as James pointed out, is "The oldest is 45 days old". The error message also shows you this: [code]In order to have access to additional assignments, please complete some more of the work already assigned [COLOR="Red"](particularily the oldest)[/COLOR]...[/code] I'm sorry for any inconvience this causes people. I'm definitely not trying to discourage P-1 participation, but we've found ourselves in a situation where there are simply too many P-1 assignments which are unreasonably old. (Not naming names, and it's not you Bdot, but there are currently outstanding assignments from November of last year.) I will shortly add highlighting on the View Assignments page for old P-1 assignments so it's clearer. Also, if the P-1er's argue that one month is too short, we can take the limit up to, say, six weeks. But I think the previous limit of three months is simply too long. |
[QUOTE=chalsall;293489]I will shortly add highlighting on the View Assignments page for old P-1 assignments so it's clearer.[/QUOTE]
And for DC and LL? |
[QUOTE=petrw1;293511]And for DC and LL?[/QUOTE]
They fall under PrimeNet's rules. But perhaps I should detect and alert when a candidate has not been updated in a for more than a month. |
[QUOTE=chalsall;293519]They fall under PrimeNet's rules.
But perhaps I should detect and alert when a candidate has not been updated in a for more than a month.[/QUOTE] I was thinking more along the lines of hi-lighting when they are close to expiring. |
[QUOTE=petrw1;293524]I was thinking more along the lines of hi-lighting when they are close to expiring.[/QUOTE]
When he says under PrimeNet rules, he means that GPU272 does not control the exponent. chalsall can't actually do anything to "expire" the exponent and remove it from the user. Like he said, the assignment is controlled by PrimeNet, so PrimeNet must do any expiring. (@chalsall: Perhaps he means that if an expo gets lost, e.g. in the copy/paste process, then highlight any (say) 2 month old expos, before PrimeNet expiry rules apply, so that the user can fix it and get it in queue.) |
[QUOTE=Dubslow;293529]When he says under PrimeNet rules, he means that GPU272 does not control the exponent. chalsall can't actually do anything to "expire" the exponent and remove it from the user. Like he said, the assignment is controlled by PrimeNet, so PrimeNet must do any expiring.[/QUOTE]
Ah right....never mind |
[QUOTE=chalsall;293396]OK... This information is now being rendered on everyone's View Assignments page.
Note that the "GHz Days per Day" value is calculated differently than the simple "30 day running average" on the graphs. It takes into account the total amount of work done divided by the total number of days assignments were out (for each work type class). Thus, the "GHz Days per Day" value will be less than the "30 day running average", particularily for the DC/LL work class where the assignments will be out for some period of time before the first result is submitted. This is to handle situations like what Ethan encountered, where he did a large batch of TF work, and then stopped for several months before returning.[/QUOTE] Food for your algorithm's thought: [code]Since you joined the project you have done on average 10.02 GHz Days of P-1 Factoring work per day.[/code] [code]Production Heuristics for Dubslow Work Type Class Completed GHz Days per Day Assigned GHz Days Days of Work Oldest (Days) Trial Factoring 1623 97.17 94 985.21 10 4 P-1 Factoring 357 10.02 101 327.97 33 6[/code] I'm not quite sure how your algo works, but if you look over the last up to a month or so at my completed assignments, you'll see that I've been doing (roughly) the same number of assignments for P-1 and TF. (This is even more true over the last 3-7 days.) Yet somehow your algo comes up with three times as long for P-1 as TF. Is this perhaps related to the week where I had two cores doing the really low LL? (Even so, the three times as many days estimate still seems a bit high.) Edit: Idea: You said that it's based (among other things) on assignment age: Well, I typically do P-1 in larger batches (30-50), whereas with TF (excepting this week of spring break) I grab the expos below 50M whenever they appear, so the assignment age would be much more homogeneous. (I do this to guarantee a quick clear, and I generally keep my TF queue under a week.) And because it seems to have gotten lost: Can you put a link to the "Individual Worker's Progress" page on the left under the "My Account" heading? |
[QUOTE=Dubslow;293548]Yet somehow your algo comes up with three times as long for P-1 as TF. Is this perhaps related to the week where I had two cores doing the really low LL? (Even so, the three times as many days estimate still seems a bit high.)[/QUOTE]
Different scales... [QUOTE=Dubslow;293548]And because it seems to have gotten lost: Can you put a link to the "Individual Worker's Progress" page on the left under the "My Account" heading?[/QUOTE] You're not very attentive... What do you think is the new "Individual Overall Statistics" link? :wink: |
[QUOTE=chalsall;293549]Different scales...
[/quote]By which I meant for a week I had two less cores than usual doing P-1. Either way, my P-1 estimate is quite a bit off. :P [QUOTE=chalsall;293549] You're not very attentive... What do you think is the new "Individual Overall Statistics" link? :wink:[/QUOTE] What link...? :unsure: [code]<div id="menu"> <ul><li><h2>GPU to 72 Tool</h2><ul> <li><a href="/" title="Home">Home</a></li> <li><a >Links</a><ul> <li><a href="http://www.mersenne.org/" title="PrimeNet">PrimeNet</a></li> <li><a href="http://www.mersenneforum.org/" title="Mersenne Forum">Mersenne Forum</a></li> <li><a href="http://mersenne-aries.sili.net/" title="Mersenne-aries Stats">Mersenne-aries Stats</a></li> <li><a href="http://www.mersenne.info/" title="GIMPS Visualisation">GIMPS Visualisation</a></li> </ul> <li><a href="/contact/" title="Contact">Contact</a></li> <li><a href="/signup/" title="Sign Up">Sign Up</a></li> <li><a href="/whats_new/" title="What's New">What's New</a></li> <li><a href="/spider/" title="Submission Spider">Submission Spider</a></li> </ul> <li> </li> </ul> <ul><li><h2>My Account</h2><ul> <li><a href="/account/getassignments/" title="Get Assignments">Get Assignments</a><ul> <li><a href="/account/getassignments/lltf/" title="LL Trial Factoring Work">LL Trial Factoring Work</a></li> <li><a href="/account/getassignments/dctf/" title="DC Trial Factoring Work">DC Trial Factoring Work</a></li> <li><a href="/account/getassignments/p-1/" title="P-1 Factoring Work">P-1 Factoring Work</a></li> <li><a href="/account/getassignments/ll/" title="Low Lucas-Lehmer Work">Low Lucas-Lehmer Work</a></li> <li><a href="/account/getassignments/dc/" title="Low Double Check Work">Low Double Check Work</a></li> </ul> <li><a href="/account/assignments/" title="View Assignments">View Assignments</a><ul> <li><a href="/account/assignments/" title="Sorted by Exponent">Sorted by Exponent</a></li> <li><a href="/account/assignments/bydate/" title="Sorted by Date">Sorted by Date</a></li> <li><a href="/account/assignments/byworktype/" title="Sorted by Work Type">Sorted by Work Type</a></li> </ul> <li><a href="/account/completed/" title="View Completed">View Completed</a></li> </ul> <li> </li> </ul> <ul><li><h2>Reports</h2><ul> <li><a href="/reports/overall/" title="Overall System Progress">Overall System Progress</a><ul> <li><a href="/reports/overall/graph/hourly/" title="Hourly Graph">Hourly Graph</a></li> <li><a href="/reports/overall/graph/" title="Weekly Graphs">Weekly Graphs</a></li> <li><a href="/reports/overall/graph/month/" title="Monthly Graphs">Monthly Graphs</a></li> <li><a href="/reports/overall/graph/quarter/" title="Quarterly Graphs">Quarterly Graphs</a></li> </ul> <li><a href="/reports/workers/" title="Workers' Progress">Workers' Progress</a><ul> <li><a href="/reports/workers/" title="Overall Work">Overall Work</a><ul> <li><a href="/reports/workers/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> <li><a href="/reports/workers/graph/21-30/" title="Top 21-30 Graph">Top 21-30 Graph</a></li> <li><a href="/reports/workers/graph/31-40/" title="Top 31-40 Graph">Top 31-40 Graph</a></li> <li><a href="/reports/workers/graph/41-50/" title="Top 41-50 Graph">Top 41-50 Graph</a></li> </ul> <li><a href="/reports/workers/lltf/" title="LL Trial Factoring">LL Trial Factoring</a><ul> <li><a href="/reports/workers/lltf/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/lltf/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> <li><a href="/reports/workers/lltf/graph/21-30/" title="Top 21-30 Graph">Top 21-30 Graph</a></li> <li><a href="/reports/workers/lltf/graph/31-40/" title="Top 31-40 Graph">Top 31-40 Graph</a></li> </ul> <li><a href="/reports/workers/dctf/" title="DC Trial Factoring">DC Trial Factoring</a><ul> <li><a href="/reports/workers/dctf/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/dctf/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> <li><a href="/reports/workers/dctf/graph/21-30/" title="Top 21-30 Graph">Top 21-30 Graph</a></li> </ul> <li><a href="/reports/workers/p-1/" title="P-1 Factoring">P-1 Factoring</a><ul> <li><a href="/reports/workers/p-1/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/p-1/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> <li><a href="/reports/workers/p-1/graph/21-30/" title="Top 21-30 Graph">Top 21-30 Graph</a></li> <li><a href="/reports/workers/p-1/graph/31-40/" title="Top 31-40 Graph">Top 31-40 Graph</a></li> </ul> <li><a href="/reports/workers/ll/" title="Lucas-Lehmer">Lucas-Lehmer</a><ul> <li><a href="/reports/workers/ll/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/ll/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> </ul> <li><a href="/reports/workers/dc/" title="Double Checking">Double Checking</a><ul> <li><a href="/reports/workers/dc/graph/" title="Top 10 Graph">Top 10 Graph</a></li> <li><a href="/reports/workers/dc/graph/11-20/" title="Top 11-20 Graph">Top 11-20 Graph</a></li> </ul> </ul> <li><a href="/reports/available/" title="Available TF Assignments">Available TF Assignments</a><ul> <li><a href="/reports/available/p-1/" title="Prior P-1 Work Done">Prior P-1 Work Done</a></li> <li><a href="/reports/available/nop-1/" title="No prior P-1 Work Done">No prior P-1 Work Done</a></li> </ul> <li><a href="/reports/available/lldc/" title="Available LL/DC Assignments">Available LL/DC Assignments</a></li> <li><a href="/reports/factoring_cost/" title="Cost per Factor Found">Cost per Factor Found</a><ul> <li><a href="/reports/factoring_cost/" title="By Trial Factoring">By Trial Factoring</a></li> <li><a href="/reports/factoring_cost/p-1/" title="By P-1 Factoring">By P-1 Factoring</a></li> </ul> <li><a href="/reports/factor_percentage/" title="Factor Found Percentages">Factor Found Percentages</a></li> <li><a href="/reports/released_level/" title="Released TF Level">Released TF Level</a><ul> <li><a href="/reports/released_level/p-1/" title="Prior P-1 Work Done">Prior P-1 Work Done</a></li> <li><a href="/reports/released_level/nop-1/" title="No prior P-1 Work Done">No prior P-1 Work Done</a></li> </ul> <li><a href="/reports/largest_factors/" title="Top 100 Factors Found">Top 100 Factors Found</a></li> <li><a href="http://www.mersenne.info/trial_factored_tabular_delta_7/2/20000000/" title="20M - 30M Range Weekly Progress">20M - 30M Range Weekly Progress</a></li> <li><a href="http://www.mersenne.info/trial_factored_tabular_delta_7/2/30000000/" title="30M - 40M Range Weekly Progress">30M - 40M Range Weekly Progress</a></li> <li><a href="http://www.mersenne.info/trial_factored_tabular_delta_7/2/40000000/" title="40M - 50M Range Weekly Progress">40M - 50M Range Weekly Progress</a></li> <li><a href="http://www.mersenne.info/trial_factored_tabular_delta_7/2/50000000/" title="50M - 60M Range Weekly Progress">50M - 60M Range Weekly Progress</a></li> </ul> <li> </li> </ul> </div>[/code] |
[QUOTE=Dubslow;293551]What link...? :unsure:[/QUOTE]
Log in, it'll be the last link in My Account. It's also the destination of the links that are the worker names at pages like [url]http://www.gpu72.com/reports/workers/[/url] |
[QUOTE=Dubslow;293551]
What link...? :unsure: [/QUOTE] I think he means [URL="http://www.gpu72.com/reports/worker/829a683f5d991e17d4cca0453117d491/"]this[/URL]. |
[QUOTE=Mini-Geek;293554]Log in, it'll be the last link in My Account. It's also the destination of the links that are the worker names at pages like [url]http://www.gpu72.com/reports/workers/[/url][/QUOTE]
[QUOTE=LaurV;293555]I think he means [URL="http://www.gpu72.com/reports/worker/829a683f5d991e17d4cca0453117d491/"]this[/URL].[/QUOTE] You are both right, but I still don't see it, look at the HTML code I pasted. I am logged in, in fact the HTML came from the "View Completed" page, so I am totally sure I'm logged in. I see "Get Assignments", "View Assignments", "View Completed" (again, see the HTML) and their submenus (none of those are right either). In fact, I lost this post once because I just cleared my cookies etc., and tried to post this and lost it (because I was then not logged in), and I still don't see it. |
And suddenly it appears! Thanks chalsall! (I wonder why I was glitching out? Or was it server side?)
|
[QUOTE=Dubslow;293558]And suddenly it appears! Thanks chalsall! (I wonder why I was glitching out? Or was it server side?)[/QUOTE]
Sigh... My fault (as usual). Error in my SQL table definition. Text versions of IP numbers can be up to 15 characters, not 13.... |
Huh... the heuristics table does not appear to update itself as often as the other tables. Presumably this is deliberate, to keep down CPU usage? (Is it updated daily or something?)
I also just noticed that Spidey is now collecting 60M-61M expos... |
[QUOTE=Dubslow;293563]
I also just noticed that Spidey is now collecting 60M-61M expos...[/QUOTE] Do we really need to go that far ahead of the LL wavefront? I would think the 34000 reserved for TF by GPU272 would be plenty? Especially when we see that only 8000 are currently assigned? Or perhaps spidy is running wild? :smile: |
[QUOTE=diamonddave;293565]Do we really need to go that far ahead of the LL wavefront? I would think the 34000 reserved for TF by GPU272 would be plenty? Especially when we see that only 8000 are currently assigned?[/QUOTE]
I'm not sure 60M is much "ahead" of the LL wavefront....looks to me like it is close to 59M. Until now this sub-project has mostly been grabbing returned LL (and DC) assignments and TF'ing deeper to eliminate some before they are reassigned. By TF'ing just ahead of LL emilinates even the first LL attempt. |
[QUOTE=diamonddave;293565]Do we really need to go that far ahead of the LL wavefront? I would think the 34000 reserved for TF by GPU272 would be plenty? Especially when we see that only 8000 are currently assigned? Or perhaps spidy is running wild? :smile:[/QUOTE]
If Spidy was "running wild", it would have allocated everything currently at 69 bits... :smile: As petrw1 points out, entering the 60M range isn't that far ahead of the wave. And at our current rate, we hold less than three months of TF work. Over the next week you'll see our rate of released candidates increasing as more and more people have been "pledging" to go straight to 72 bits. |
[QUOTE=Dubslow;293563]Huh... the heuristics table does not appear to update itself as often as the other tables. Presumably this is deliberate, to keep down CPU usage? (Is it updated daily or something?)[/QUOTE]
I had to upgrade the script which runs after work is "observed" to use the new subroutines. This has now been done. |
[QUOTE=chalsall;293573]I had to upgrade the script which runs after work is "observed" to use the new subroutines. This has now been done.[/QUOTE]
Ah good :smile: [QUOTE=chalsall;293571]If Spidy was "running wild", it would have allocated everything currently at 69 bits... :smile: As petrw1 points out, entering the 60M range isn't that far ahead of the wave. And at our current rate, we hold less than three months of TF work. Over the next week you'll see our rate of released candidates increasing as more and more people have been "pledging" to go straight to 72 bits.[/QUOTE] I would rather get the lower expos at 71 bits than the higher expos at 69 bits. Make sure everything it thoroughly done. |
[QUOTE=chalsall;293489]If you look back on this thread, you'll see the new limits. Basically I'm bringing the allowed quantity, and age, down to one month.
... I will shortly add highlighting on the View Assignments page for old P-1 assignments so it's clearer. Also, if the P-1er's argue that one month is too short, we can take the limit up to, say, six weeks. But I think the previous limit of three months is simply too long.[/QUOTE] Thanks, I understood. I temporarily added a machine to help the two slow boxes that hold the 7 offending assignments I have. I think it would be useful to distinguish between allowed quantity and age. I'm running very different machines, from really slow to quite fast. I cannot avoid that some of my later assignments finish earlier than some of the old ones. My slow machines finish one P-1 in 10-11 days (per thread; certainly also because I change the assignments from "...,2" to "...,3"). I used to add batches of 5 assignments when only 1 or 2 were left. Looks like I need to add them one by one to comply with the new rules. I just checked: primenet gave me a 56.3M P-1 test, I could switch the machines to primenet assignments again (but I like your nice statistics ...). Or, you change the logic to hand out assignments up to a total of 25 days at most, if the oldest assignment is below 50 days? How's that? |
The P-1 GHz-days credits seem to be off in some cases. For example, from my completed exponents list :
** 52374953 72 P-1 2012-02-07 15:28:33 2012-03-14 02:41:20 3.685 But my prime.log shows Sending result to server: UID: kcjaget/Laptop, M52374953 has a factor: 441339726116774185834183 RESPONSE: pnErrorResult=0 pnErrorDetail=CPU credit is 2.8833 GHz-days. This only seems to be a problem on P-1s that find factors ... in most cases the results match what I'm seeing in my log files. I'm not really worried about getting too much credit, but this 3.68x number shows up in the assignment page as well. I wanted to point it out in case it was used to figure out how many days of P-1 work are assigned. If so, its overestimating by a decent amount. |
[QUOTE=Dubslow;293581]Ah good :smile:
I would rather get the lower expos at 71 bits than the higher expos at 69 bits. Make sure everything it thoroughly done.[/QUOTE] I believe you can choose lower expos on the "Get Assignments" screen. Also the odds are slightly higher of finding a 69 bit factor than a 71 bit. Also if you find a factor of a 60M exponent you save more work than for a lower exponent. Also, do I say also too much? |
[QUOTE=Bdot;293600]Or, you change the logic to hand out assignments up to a total of 25 days at most, if the oldest assignment is below 50 days? How's that?[/QUOTE]
That seems reasonable. OK, I have adjusted the code's logic such that P-1 assignments are now valid for 50 days. However, new assignments won't be given out if there's more than 25 days worth assigned, [I][U]or[/U][/I] the oldest is more than 45 days old. (It didn't make sense to me to assign new work on the same day one or more of the old were going to be expired.) I have also added the warnings and highlights on the View Assignments page. And, just for fun and because I was in the code, I've added a column for "GHz Days" for each assignment. |
[QUOTE=kjaget;293602]I'm not really worried about getting too much credit, but this 3.68x number shows up in the assignment page as well. I wanted to point it out in case it was used to figure out how many days of P-1 work are assigned. If so, its overestimating by a decent amount.[/QUOTE]
Thanks for letting me know. Dubslow pointed out the over-credit before, and it's on my todo list, but the overestimating might be an issue I'll need to look into. |
[QUOTE=petrw1;293609]I believe you can choose lower expos on the "Get Assignments" screen.[/QUOTE]
In fact, someone has to change the "Maximum Range" to be higher than 60M to get assignments at 61M. While working within the wave is the most important thing at the moment, I know some people love working the low TFed candidates, so I thought I'd have Spidy bring in a few when they became available. |
[QUOTE=petrw1;293609]Also, do I say also too much?[/QUOTE]Yes :smile:
[QUOTE=petrw1;293609]I believe you can choose lower expos on the "Get Assignments" screen. Also the odds are slightly higher of finding a 69 bit factor than a 71 bit. Also if you find a factor of a 60M exponent you save more work than for a lower exponent. [/quote] What I meant here is that there are many expos 50M-60M that are already at 71 bits that Spidey doesn't reserve. The available TF from GPU272 at 71 bits are only those exponents that were picked up at lower bits and taken to 71. So in this case, I would prefer to take those expos at 71 without us, have Spidey grab them, and finish the job to 72 before going higher. [QUOTE=chalsall;293621]In fact, someone has to change the "Maximum Range" to be higher than 60M to get assignments at 61M. While working within the wave is the most important thing at the moment, I know some people love working the low TFed candidates, so I thought I'd have Spidy bring in a few when they became available.[/QUOTE] On the other hand, that is totally fair ;) |
So, I was bored waiting for an AI training run to finish (I often wish I had the computing power some of you do... :wink:) and thought I'd expose a graph I use in the Admin area...
The [URL="http://www.gpu72.com/reports/overall/graph/assigned/"]Assignment Age and Pledge Level[/URL] graph is available as a sub-menu of the "Overall System Progress" menu. Not sure that's the best place for it, but I couldn't think of where else, and it doesn't warrant it's own menu item. Note that this only shows LL and DC Trial Factoring assignments which haven't been extended. I'll bring the P-1 assignments into this once we've retired some of the old assignments. The graph shows that we're doing quite a good job of keeping assignments "timely", and that most people are now going to 72 bits in one go in the LL range. |
Heh.. if you're bored, I would be interested in a graph where the x axis is date, and each "slot" on the y-axis is one of my individual assignments, with a bar representing the assigned date through to completion date. For me and LLTF, it would be a pretty boring graph, since I only have one mfaktc instance, but for P-1 it would be an interesting mix as assignments are moved around from worker to worker and I prioritize lower expos/older assignments, etc...
I wasn't going to say anything, but now you've presented me an opportunity to pester you with an idea that's cool, awesome, hard to implement and totally useless :smile: |
[QUOTE=flashjh;293360]Over the next few days I'll unreserve stuff that is old and rebuild my worktodo files.[/QUOTE]
All done |
[QUOTE=Dubslow;293626]Yes :smile:[/QUOTE]
WRONG. Petrw is spot on. [Quote]What I meant here is that there are many expos 50M-60M that are already at 71 bits that Spidey doesn't reserve. The available TF from GPU272 at 71 bits are only those exponents that were picked up at lower bits and taken to 71. So in this case, I would prefer to take those expos at 71 without us, have Spidey grab them, and finish the job to 72 before going higher.[/QUOTE] WRONG. [Quote]On the other hand, that is totally fair ;)[/QUOTE] WRONG. You sure weren't kidding when you said you hadn't understood me. Read the "TF strategy" thread again. David |
[QUOTE=Dubslow;293581]I would rather get the lower expos at 71 bits than the higher expos at 69 bits. Make sure everything it thoroughly done.[/QUOTE]
Totally bonkers. In the days when you could follow the daily LL assignments on the "Primenet Summary" page, you would have seen that there were ~1000 per day, but only ~200 of these were "brand new", thereby advancing the wavefront. 72 was determined simply because 200 a day could be done to 72 AHEAD of the wavefront. Rate of "saving work" goes as exponent^3. Spidy grabs returned expos, and could take 69 to 70, starting with the highest and working down. But the priority should be taking expos just of the wavefront straight to 73, I'd judge by now, working just ahead of the wavefront. The reason this didn't start back when the wavefront was 53M is that Primenet embarked on a half-hearted "one bit at a time" strategy which (as I predicted) fizzled out at 70 or 71 bits. David |
[QUOTE=davieddy;293667]Totally bonkers.[/QUOTE]
Sigh... Here we go again... :cry: [QUOTE=davieddy;293667]In the days when you could follow the daily LL assignments on the "Primenet Summary" page, you would have seen that there were ~1000 per day, but only ~200 of these were "brand new", thereby advancing the wavefront.[/QUOTE] You always talk about "brand new", but never explain how such an candidate is any more important to TF than some poor little orphaned candidate which has been abandoned. Many argue it is more important to process the lower candidates first -- eliminate what we can and get the rest back into PrimeNet's pool for processing -- since they might be prime, and doing the LL test is less expensive than higher candidates. [QUOTE=davieddy;293667]72 was determined simply because 200 a day could be done to 72 AHEAD of the wavefront.[/QUOTE] Then isn't it [URL="http://www.gpu72.com/reports/overall/graph/month/"]impressive[/URL] that we're currently doing about 600 a day WITHIN the wave, where it's computationally more expensive? And to be a little more empirical (rather than hysterical), over the [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/40000000/"]last[/URL] [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/50000000/"]month[/URL] there have been on average 197 LL tests completed. During the same period, 28 candidates per day were eliminated thanks to Trial and P-1 factoring. [QUOTE=davieddy;293667]But the priority should be taking expos just of the wavefront straight to 73, I'd judge by now, working just ahead of the wavefront.[/QUOTE] That is your [B][I][U]opinion[/U][/I][/B], which isn't shared by most people. The end of the day David there is only one person who could convience us to change our stategy. And just in case it isn't clear, that person isn't you.... |
[QUOTE=chalsall;293688]The end of the day David there is only one person who could convience us to change our stategy. [/QUOTE]
Then it has to be: [url]http://www.chucknorrisfacts.com/search/node/prime[/url] Note especially the 3rd fact. |
[QUOTE=chalsall;293688]Sigh... Here we go again... :cry:
You always talk about "brand new", but never explain how such an candidate is any more important to TF than some poor little orphaned candidate which has been abandoned. Many argue it is more important to process the lower candidates first -- eliminate what we can and get the rest back into PrimeNet's pool for processing -- since they might be prime, and doing the LL test is less expensive than higher candidates. Then isn't it [URL="http://www.gpu72.com/reports/overall/graph/month/"]impressive[/URL] that we're currently doing about 600 a day WITHIN the wave, where it's computationally more expensive? And to be a little more empirical (rather than hysterical), over the [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/40000000/"]last[/URL] [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/50000000/"]month[/URL] there have been on average 197 LL tests completed. During the same period, 28 candidates per day were eliminated thanks to Trial and P-1 factoring. That is your [B][I][U]opinion[/U][/I][/B], which isn't shared by most people. The end of the day David there is only one person who could convience us to change our stategy. And just in case it isn't clear, that person isn't you....[/QUOTE] I love a good logical argument. More anon, but in the meantime I shall watch "Pointless". David x |
[QUOTE=chalsall;293688]
And to be a little more empirical (rather than hysterical), over the [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/40000000/"]last[/URL] [URL="http://www.mersenne.info/exponent_status_tabular_delta_30/2/50000000/"]month[/URL] there have been on average 197 LL tests completed. During the same period, 28 candidates per day were eliminated thanks to Trial and P-1 factoring. [/QUOTE] Does this mean we are only getting about half as much P-1 as necessary? :cry: There are those like [URL="http://mersenne.org/report_top_500_P-1/"]Never Odd or Even[/URL] on PrimeNet, but I don't think PrimeNet is also getting 85/day not counting us... is there any way for mersenne.info to get a daily P-1 count? (I should also point out that NOoE has a bizzare attempted/success count.) |
[QUOTE=chalsall;293688]You always talk about "brand new", but never explain how such an candidate is any more important to TF than some poor little orphaned candidate which has been abandoned.[/quote]
While the "brand new" rhetoric is distracting, there is a certain logic to this. The aim of GPUto72 is to reduce/eliminate "Unwanted LLs" -- defined as any completed LL test that shouldn't have run in the first place because it has a factor b/w PrimeNet limits and extended limits (but the factor was never found). Perfection is achieved when there are zero "unwanted LLs". However, if we have to choose b/w preventing a 45M unwanted LL and a 55M unwanted LL, we should favor the 55M one because preventing the latter would lead to greater reduction of "waste". Thus leading edge of LL assignment should be the focus. Having said that, I believe this is only a temporary problem, and that the rate at which GPUto72 is progressing, it should soon overtake the LL wave (any projections on when this might be?). [QUOTE=chalsall;293688]Many argue it is more important to process the lower candidates first -- eliminate what we can and get the rest back into PrimeNet's pool for processing -- since they might be prime, and doing the LL test is less expensive than higher candidates.[/quote] From an individual cruncher's perspective, smaller is better. But since this is an open-ended project, from the project's perspective, they are all the same. They all need to be crunched. |
[QUOTE=Dubslow;293696](I should also point out that NOoE has a bizzare attempted/success count.)[/QUOTE]
This one? 1552 NoOne 10.911 3 0 3 and 0 does not seem bizarre? What am I missing? |
[QUOTE=axn;293699]Having said that, I believe this is only a temporary problem, and that the rate at which GPUto72 is progressing, it should soon overtake the LL wave (any projections on when this might be?).[/QUOTE]
I would have to write a fairly involved query to answer this with extreme accuracy (taking into account those candidates at 71 bits which "Spidy" is currently throwing back, the fact that TF gets cheaper the larger the candidate, etc), but a back-of-the-envelope calculation says at our current rate we can take everything we currently "own" to 72 bits in just short of two months. And, for some time now, we have been processing many more candidates than are being LLed, which means while we haven't yet "pulled ahead of the wavefront" like we have in the DC range, the "wave" is now compressing. [QUOTE=axn;293699]However, if we have to choose b/w preventing a 45M unwanted LL and a 55M unwanted LL, we should favor the 55M one because preventing the latter would lead to greater reduction of "waste". Thus leading edge of LL assignment should be the focus.[/QUOTE] The assignment pages have always allowed individuals to choose the range they wish. For those who agree that higher is better the system is more than willing to facilitiate. |
[QUOTE=petrw1;293702]This one?
1552 NoOne 10.911 3 0 3 and 0 does not seem bizarre? What am I missing?[/QUOTE] Never Odd or Even, rank 1. |
[QUOTE=Dubslow;293696]There are those like [URL="http://mersenne.org/report_top_500_P-1/"]Never Odd or Even[/URL] on PrimeNet.[/QUOTE]
Never Odd or Even is doing very large P-1 at 26 GDs per. On the other hand James H. is doing much smaller at 0.5 per. [QUOTE=Dubslow;293696]Is there any way for mersenne.info to get a daily P-1 count?[/QUOTE] FYI: I did a query first full 20 days in March. [CODE]GhzDays Attempts Successes Per Day 27459.439 14582 632 729 [/CODE] If you are interested in the P-1 activity near the LL line: Depending on your definition of, there are between about 2,000 and 7,450 that are small P-1 and 40ish that are very large P-1 and could be excluded. I would exclude all 7500 making the Per-Day average somewhere in the DC/LL ranges of about 354. |
[QUOTE=Dubslow;293704]Never Odd or Even, rank 1.[/QUOTE]
Ah... Bizarre because he is doing very large P-1....maybe even in the 332M range. |
Today's workload showed that
[code] no factor for M55402873 from 2^70 to 2^71 [mfaktc 0.18 71bit_mul24] no factor for M55402873 from 2^71 to 2^72 [mfaktc 0.18 barrett79_mul32] no factor for M55428083 from 2^70 to 2^71 [mfaktc 0.18 71bit_mul24] no factor for M55428083 from 2^71 to 2^72 [mfaktc 0.18 barrett79_mul32] no factor for M55447649 from 2^70 to 2^71 [mfaktc 0.18 71bit_mul24] M55447649 has a factor: 4620203324582193305831 [TF:71:72:mfaktc 0.18 barrett79_mul32] M55447649 has a factor: 2659983278771704313633 [TF:71:72:mfaktc 0.18 barrett79_mul32] found 2 factors for M55447649 from 2^71 to 2^72 [mfaktc 0.18 barrett79_mul32] [/code] while the last row (done from 2^71 to 2^72) was not counted. But if you look at the results, I got respectively 16.xx and 10.xx GHz/day for the 2 factors. Not bad... :smile: Luigi |
So, we are actually getting 350 P-1/day versus 200 LL/day? So that in a year or so this P-1 crunch will be gone?
|
[QUOTE=chalsall;293703]And, for some time now, we have been processing many more candidates than are being LLed, which means while we haven't yet "pulled ahead of the wavefront" like we have in the DC range, the "wave" is now compressing.[/QUOTE]
Another point I would like to make... Because of the rate we're processing and returning candidates, very few if any DC or LL assignments should be issued by PrimeNet which are not already TFed to 69 or 72 bits, as appropriate (except when I have to turn off the "returning spider" because of maintenance). Thus, the more of the lower candidates we process earlier, the more will be given to LL/DC workers sooner rather than later. |
[QUOTE=axn;293699]While the "brand new" rhetoric is distracting, there is a certain logic to this. The aim of GPUto72 is to reduce/eliminate "Unwanted LLs" -- defined as any completed LL test that shouldn't have run in the first place because it has a factor b/w PrimeNet limits and extended limits (but the factor was never found). Perfection is achieved when there are zero "unwanted LLs". However, if we have to choose b/w preventing a 45M unwanted LL and a 55M unwanted LL, we should favor the 55M one because preventing the latter would lead to greater reduction of "waste". Thus leading edge of LL assignment should be the focus.
Having said that, I believe this is only a temporary problem, and that the rate at which GPUto72 is progressing, it should soon overtake the LL wave (any projections on when this might be?). From an individual cruncher's perspective, smaller is better. But since this is an open-ended project, from the project's perspective, they are all the same. They all need to be crunched.[/QUOTE] THX. IMAO "brand" new = "non-regurgitated" = "ahead of the wavefront". David |
[QUOTE=chalsall;293717]Another point I would like to make... Because of the rate we're processing and returning candidates, very few if any DC or LL assignments should be issued by PrimeNet which are not already TFed to 69 or 72 bits, as appropriate (except when I have to turn off the "returning spider" because of maintenance).
[/QUOTE] Out of curiosity, davieddy, what's your current exponent? (And how accurate are Prime95's estimated completion dates for you?) |
[QUOTE=Dubslow;293748]Out of curiosity, davieddy, what's your current exponent? (And how accurate are Prime95's estimated completion dates for you?)[/QUOTE]
They start pessimistic, then realise I do leave the thing running 24/7 and it gets hopeful. Then I watch a few movies. I won't tell you the exponent in case someone poaches it, but it is ~50M (like me:smile:) It was TFed to 72. (Otherwise I would ask a GPUer for assistance) and (P-1)ed well. (Otherwise I'd DIY). It's not me. I'm a professional nuisance. Its the rest of the riff-raff out there we should be thinking about. I hear there are a lot of folk in China, India, Africa, South America... some of who own computers these days. David |
[QUOTE=chalsall;293703]I would have to write a fairly involved query to answer this with extreme accuracy (taking into account those candidates at 71 bits which "Spidy" is currently throwing back, the fact that TF gets cheaper the larger the candidate, etc), but a back-of-the-envelope calculation says at our current rate we can take everything we currently "own" to 72 bits in just short of two months.[/QUOTE]
I was myself interested in the answer to "how much work do we actually have?", so I wrote the needed query. It actually turned out to be less involved than I first thought... The new report [URL="http://www.gpu72.com/reports/estimated_completion/"]Estimated Days to Complete Trial Factoring[/URL] calculates the number of days each range is going to take to each needed bit level for all candidates we currently own, based on our 30 day average production. And the answer is... We currently hold about 42 days of LL Trial Factoring work. This value will vary as Spidy grabs new work, we complete assigned work, and as our 30 day average changes. This chart is updated in real-time. Currently the report only shows the LL range; I'll add the Double Check range later. Also, I'll add a different "view" answering how long it would take us to do every candidate not already LLed (or DCed), including those we don't currently own. |
[QUOTE=chalsall;293785]Also, I'll add a different "view" answering how long it would take us to do every candidate not already LLed (or DCed), including those we don't currently own.[/QUOTE]
[URL="http://www.gpu72.com/reports/estimated_completion/primenet/"]View added.[/URL] Answer: less than 200 days to Trial Factor everything to the new GPU levels up to 60M for every candidate not already LLed. Wow!!! GPUs are just amazing!!! :smile: |
[QUOTE=chalsall;293790][URL="http://www.gpu72.com/reports/estimated_completion/primenet/"]View added.[/URL] Answer: less than 200 days to Trial Factor everything to the new GPU levels up to 60M for every candidate not already LLed.
Wow!!! GPUs are just amazing!!! :smile:[/QUOTE] Even less, provided that many among us are waiting to buy a new card... :smile: What then? Luigi |
I just picked up 2 29M DCs for P95 and 25 69-70bit 63?M TFs for Mfaktc. I'm wondering, though, how long would a ~70M P-1 with B1=B2=5,000,000 on a Pentium D 940 (3.2Ghz, two threads in P95 running simul, 1843MB EWE allotted)? Thanks!
|
[QUOTE=c10ck3r;293801]I just picked up 2 29M DCs for P95 and 25 69-70bit 63?M TFs for Mfaktc.[/QUOTE]
From PrimeNet. |
[QUOTE=c10ck3r;293801]I just picked up 2 29M DCs for P95 and 25 69-70bit 63?M TFs for Mfaktc. I'm wondering, though, how long would a ~70M P-1 with B1=B2=5,000,000 on a Pentium D 940 (3.2Ghz, two threads in P95 running simul, 1843MB EWE allotted)? Thanks![/QUOTE]
We strongly, strongly ask that you PLEASE NOT do P-1 if you don't have sufficient memory to do Stage 2. If you insist on doing such however, you can get an estimate of the credit awarded for such an assignment from [url]http://www.mersenne-aries.sili.net[/url] . Edit: I see you do have plenty of memory for Stage 2, so please let Prime95 choose the bounds on its own. |
[QUOTE=Dubslow;293803]We strongly, strongly ask that you PLEASE NOT do P-1 if you don't have sufficient memory to do Stage 2.[/QUOTE]
According to my AI heuristics, "c10ck3r" is more than 95% likely to be a certain David. LOL... And to think I thought that that AI course would be useless.... |
[QUOTE=chalsall;293805]According to my AI heuristics, "c10ck3r" is more than 95% likely to be a certain David.
LOL... And to think I thought that that AI course would be useless....[/QUOTE] Kansas, 2010... I seriously hope you're wrong :razz::unsure: |
LOL, no.
[QUOTE=chalsall;293805]According to my AI heuristics, "c10ck3r" is more than 95% likely to be a certain David.
LOL... And to think I thought that that AI course would be useless....[/QUOTE] Well, whether or not it is useless, it is the 5% that won. The name is John, and I've got nowhere near as much "knowledge" (whether real or perceived) as our strongly-opinionated friend daveiddy:devil: However, I would love to have even half of the computational power he seems to wield! |
[QUOTE=c10ck3r;293829]However, I would love to have even half of the computational power he seems to wield![/QUOTE]
Close to nothing? You need to set your sights higher.... |
My Setup
[QUOTE=chalsall;293831]Close to nothing?
You need to set your sights higher....[/QUOTE] That's what I operate on (close to nothing) 1x GTX 460 on the 3.2GHz Pent D 940 w/ 2GB RAM. A P4? that does TF on it's 1.8GHz core A new, quad core laptop running TF whenever I'm at the grandparent's house. I think he probably has me beat. I have, however, found over 850 new factors of mersenne numbers below M1000000000 throughout my participation. |
A GTX 460 is a lot more than davieddy has.
|
[QUOTE=Dubslow;293836]A GTX 460 is a lot more than davieddy has.[/QUOTE]
But at least I am partially sighted and drunk in charge of a brain. |
[QUOTE=chalsall;293790][URL="http://www.gpu72.com/reports/estimated_completion/primenet/"]View added.[/URL] Answer: less than 200 days to Trial Factor everything to the new GPU levels up to 60M for every candidate not already LLed.
Wow!!! GPUs are just amazing!!! :smile:[/QUOTE] With a decent percentage of this being taken up by doing the 58M-60M range to 73 bits, if I'm reading the chart correctly. |
[QUOTE=kjaget;293871]With a decent percentage of this being taken up by doing the 58M-60M range to 73 bits, if I'm reading the chart correctly.[/QUOTE]
You are. We could take [I][U]everything[/U][/I] up to 60M to 72 bits in about 106 days. And so everyone knows, the report is taking into account that the 58 range is "special" in that the transition to 73 bits starts at 58.52M. However, something to start discussing... Once we have effectively cleared out the "wave", should we race ahead of it, or come back and start going to 73 below 58.52? Probably we'll do what we're now doing in the DC range -- some are having fun taking higher ranges from 67 to 68, while "Pete" is taking many candidates below 29.69 to 70 rather than the nominal 69. |
[QUOTE=chalsall;293875]You are.
We could take [I][U]everything[/U][/I] up to 60M to 72 bits in about 106 days. And so everyone knows, the report is taking into account that the 58 range is "special" in that the transition to 73 bits starts at 58.52M. However, something to start discussing... Once we have effectively cleared out the "wave", should we race ahead of it, or come back and start going to 73 below 58.52? Probably we'll do what we're now doing in the DC range -- some are having fun taking higher ranges from 67 to 68, while "Pete" is taking many candidates below 29.69 to 70 rather than the nominal 69.[/QUOTE] That's laziness... there are usually less than 15 that show up under the cutoff and I normally grab 50 at a time, so selecting lowest exp to 70 is easier than figuring out how many are below and selecting them to 69, then grabbing the leftover to 70. Edit: Would it be difficult to make the site do this automatically? I normally select Lowest exponent, since there is a lowest to 70 selection, how about the program ignore the factor to box on lowest exponent and give out assignments below the cutoff to 69 and above to 70? |
[QUOTE=chalsall;293875]Once we have effectively cleared out the "wave", should we race ahead of it, or come back and start going to 73 below 58.52?[/QUOTE]My preference would be to "race ahead", but that's cause I enjoy finding factors. Same reason I do TF in the 800M range and P-1 in the 10M range. No doubt a vocal portion of the group will decry my work preferences as immoral in some manner, but they're free to use their own GPUs as they see fit. :smile:
|
[QUOTE=chalsall;293875]However, something to start discussing... Once we have effectively cleared out the "wave", should we race ahead of it, or come back and start going to 73 below 58.52?[/QUOTE]
I suspect that the answer would turn out to be "both" :smile: Build up a buffer ahead of the wave while simultaneously speeding up the wave. Maybe even prep some EFF prize candidates (~332M range)? |
| All times are UTC. The time now is 01:02. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.