Thank you very much for your very fast answer and action! Now let's raise a bit in the top... I was beginning to rust there... :D

[QUOTE=chalsall;289426]I agree the heuristic is not optimal at the moment for users like you, and have been thinking about how to improve the intelegence of the algorithm. But for the time being (as it says on the reservation pages) just ask me if you wish to be exempted and I will (usually) oblidge.[/QUOTE]

Just thinking out loud, could you include some sort of average age when results are submitted calculation to the process. That is, if this user has a history of returning results in a week then you'd give them a bit more lee-way compared to users who return half their results in a month and let the rest expire. This would help the case where users switch back and forth between work types, because when they shifted to TF work again you'd know that they have a good or bad track record of returning results in a reasonable amount of time.

Just food for thought. Right now I have no complaints about how the system works and it looks like it's a small enough problem to take care of by hand.

Am I doing something wrong? I can't seem to get any TF assignments, even though it seems plenty should be available, I just get[quote][color=red]Sorry... No available exponents which match your criteria.[/color][/quote]

[QUOTE=kjaget;289448]Just food for thought. Right now I have no complaints about how the system works and it looks like it's a small enough problem to take care of by hand.[/QUOTE]

Great minds think alike!!! :smile: That is exactly where my thinking was converging.

However, we still have the issue of the new user. In the past we've had some new users appear who have some serious firepower available, but were only allowed to reserve 400 GDs of work initially. Bad -- this new user had a discouraging initial experience.

On the other hand, only early this morning a new user signed up and reserved 99999997952 GDs of work (100 candidates pledged to be taken to 255 bits), and then tried to get some more. Good -- this new user was probably not serious about helping the project.

The Internet is an interesting place.... :wink:

[QUOTE=James Heinrich;289449]Am I doing something wrong? I can't seem to get any TF assignments, even though it seems plenty should be available, I just get[/QUOTE]

Sorry... Stupid programmer error.

After the Anonymous new user this morning pledged to take 100 candidates to 255 bits, I added a conditional on the highest that could be pledged. But rather than the pledge, the test was against the maximum exponent range...

Note to self: never make code changes before your first cup of coffee.... :no:

[QUOTE=chalsall;289450]
On the other hand, only early this morning a new user signed up and reserved 99999997952 GDs of work (100 candidates pledged to be taken to 255 bits), and then tried to get some more. Good -- this new user was probably not serious about helping the project.

The Internet is an interesting place.... :wink:[/QUOTE]

That bespeaks either extreme ignorance, or perhaps an attempt to sabotage or sandbag the project. SHEESH!
(Not that I should be too harsh on ignorance. I am too well supplied with that myself.:cmd:)

hmm 99999997952GhZ-day? even with 1000 nucleaon farm ( if i remember right, he produce around 1600 Ghz-day by day) it would take 173 years and 146 days

[QUOTE=chalsall;289377]
Because I'm sure everyone will be interested in the results, I've added a new graph to everyone's [URL="http://www.gpu72.com/reports/worker/fc9f090d094ad7c7eff10a39caffe3a4/"]Individual reports -- GHz Days per Day[/URL].
[/QUOTE]
I like that a lot, big thank you!

[URL="http://www.gpu72.com/reports/worker/5b6f7bd5a6b6e7e6988c81e70d6cd07d/"]My graph[/URL] is quite spiky ... I could use a running average :smile:

Or, maybe add a column to the top table like "avg. GHz days per day" - for each work type and the total?

And another request would help me: Could you turn the exponents in the "View Assignments" page into links like [url]http://www.mersenne.org/report_exponent/?exp_lo=45065851[/url] ? This way I could verify a little easier if assignments have been returned to primenet by mprime, or if some that I assigned to "manual" machines have been reassigned by primenet.

[QUOTE=Bdot;289496]Or, maybe add a column to the top table like "avg. GHz days per day" - for each work type and the total?[/QUOTE]

Yeah... That's been asked for by James already. It's on my todo list. It's a bit of work.

[QUOTE=Bdot;289496]And another request would help me: Could you turn the exponents in the "View Assignments" page into links like [url]http://www.mersenne.org/report_exponent/?exp_lo=45065851[/url] ? This way I could verify a little easier if assignments have been returned to primenet by mprime, or if some that I assigned to "manual" machines have been reassigned by primenet.[/QUOTE]

That's easy to do, and has just been done. Both for Assigned and Completed.

[QUOTE=chalsall;289504]
That's easy to do, and has just been done. Both for Assigned and Completed.[/QUOTE]
Very nice, and very quick -thanks!

IDEA Idea idea: For "Completed Assignments" which found a factor, can it link instead to mersenne-aries? (The site's down ATM though...)

[QUOTE=Dubslow;289509]IDEA Idea idea: For "Completed Assignments" which found a factor, can it link instead to mersenne-aries? (The site's down ATM though...)[/QUOTE]

Sure.

What have we been doing from the [URL="http://www.gpu72.com/reports/largest_factors/"]Top 100 Factors Found[/URL] report for quite some time?

Edit: BTW, James... What's up (or, more accurately, down) with your site?

[QUOTE=James Heinrich] I'm battling valiantly to re-index the 33-million-record table of known factors. It's going poorly, unfortunately. I hope to have it back up and running properly within a day or so, but who knows. I didn't want to risk losing any data which is why I disabled submissions, and purposely took down the site for some time.[/QUOTE]

A few hours ago.

[QUOTE=Dubslow;289514]A few hours ago.[/QUOTE]

Ah... Thanks. I didn't see that.

Reindexing a 33 million row table can take some time....

[QUOTE=chalsall;289515]Ah... Thanks. I didn't see that.
Reindexing a 33 million row table can take some time....[/QUOTE]You didn't see that cause you didn't ask (Dubslow did, in a PM). :smile:

Monkeying with the tables on my home machine / development server (Sandy-E, OCZ Vertex 3) works fine, albeit still slow (a few dozen minutes to complete). On my production server it's nigh impossible to work with that table anymore. Oh sure, selecting is fine, and inserting a few records at a time is no problem, but major operations take 5+ hours (let it run overnight, then find the ISP killed the process after ~5 hours cause it still hadn't finished).

So I'm taking a new approach: split it into 101 tables, one for each 10M range (plus one for >=1000M) and now it's a [b]much[/b] more manageable ~300k-500k records per table. And except for a couple rare cases, it's no worse, in fact it's better off since it's querying a much more-specific smaller table.

If all goes well my site should be back up by the end of tonight...

[QUOTE=James Heinrich;289517]If all goes well my site should be back up by the end of tonight...[/QUOTE]Apparently it went well. :cool:

It should be 99% functional now, the last 1% can regenerate while the site is running. Please let me know if anything's broken, cause it shouldn't be.

[QUOTE=James Heinrich;289517]
Monkeying with the tables on my home machine / development server (Sandy-E, OCZ Vertex 3) works fine, albeit still slow (a few dozen minutes to complete). On my production server it's nigh impossible to work with that table anymore. Oh sure, selecting is fine, and inserting a few records at a time is no problem, but major operations take 5+ hours (let it run overnight, then find the ISP killed the process after ~5 hours cause it still hadn't finished).
[/QUOTE]
Get a better server? Or is the obvious solution one that doesn't work?

chalsall, why has the LLTF reserved count dropped from >30K to <27K? I didn't see any major spike in the throughput graphs...

[QUOTE=Dubslow;289543]chalsall, why has the LLTF reserved count dropped from >30K to <27K? I didn't see any major spike in the throughput graphs...[/QUOTE]

Expired exponents perhaps?

-- Craig

[QUOTE=Dubslow;289543]chalsall, why has the LLTF reserved count dropped from >30K to <27K? I didn't see any major spike in the throughput graphs...[/QUOTE]

With our two big guns fighting it out in the DC range (hopefully temporarily), I was uncomfortable holding >30K assignments. So I had the system throw back to PrimeNet a few thousand which had already been TFed to 71.

[QUOTE=Bdot;289496]I like that a lot, big thank you!

[URL="http://www.gpu72.com/reports/worker/5b6f7bd5a6b6e7e6988c81e70d6cd07d/"]My graph[/URL] is quite spiky ... I could use a running average :smile:

Or, maybe add a column to the top table like "avg. GHz days per day" - for each work type and the total?[/QUOTE]

Or overlay some colored lines on top of the bars showing some sort of moving average? Something like [url]https://chart.googleapis.com/chart?chs=200x125&chds=0,100,0,100&cht=bvs&chd=t1:43,35,48,57,67,60,70|10,18,12,16,16,23,30&chco=78c2f4,003971&chbh=15,10&chm=D,003971,1,0,3|@a,000000,0,.25:.75,7|@tExpected,000000,0,.35:.85,10[/url] (first example I could find, but some imagination will get you to what I was thinking of).

[QUOTE=kjaget;289578]Or overlay some colored lines on top of the bars showing some sort of moving average?[/QUOTE]

OK. That is actually quite easy to do. Five minutes, in fact.

I'm only rendering a total running average, rather than a seperate line for each work type. I think the graphs would get too cluttered with five lines.

[QUOTE=chalsall;289580]OK. That is actually quite easy to do. Five minutes, in fact.

I'm only rendering a total running average, rather than a seperate line for each work type. I think the graphs would get too cluttered with five lines.[/QUOTE]
YES! That's perfectly what I had thought of ... Thanks!

EDIT: However, the line disagrees with what the "View Assignments" page says: "... you have done on average 224.105 GHz Days of work per day." But my avg. line seems to end at ~175.

[QUOTE=Bdot;289584]EDIT: However, the line disagrees with what the "View Assignments" page says: "... you have done on average 224.105 GHz Days of work per day." But my avg. line seems to end at ~175.[/QUOTE]

That language is actually inaccurate. The 224 GD value is what you've done on average per day in the last 30 days (or since someone started the project if less than 30).

Once I have the expanded metrics exposed it will make more sense.

Edit: And I've modified the language to indicate that the value being presented is the average over the last 30 days. Thanks for pointing that out Bdot.

[QUOTE=chalsall;289589]The 224 GD value is what you've done on average per day in the last 30 days (or since someone started the project if less than 30).[/QUOTE]I think that is the more interesting number. Would it be possible to present the average line in the graph as a 30-day moving average rather than start-to-now average? I'm not sure if now-30 or now+/-15 is a more interesting number for graphing purposes, although sticking with now-30 to match the wording elsewhere might be prudent.

[QUOTE=James Heinrich;289597]I think that is the more interesting number. Would it be possible to present the average line in the graph as a 30-day moving average rather than start-to-now average? I'm not sure if now-30 or now+/-15 is a more interesting number for graphing purposes, although sticking with now-30 to match the wording elsewhere might be prudent.[/QUOTE]

Sigh... Like a poem, [URL="http://linuxdevcenter.com/pub/a/linux/2000/09/15/blackhole.html?page=5"]no software is finished, only abandoned[/URL].

I'll look into it.

[QUOTE=chalsall;289601]I'll look into it.[/QUOTE]It's our universe: we imagine, you create. :smile:

Seriously, your efforts are appreciated!

Suggestion: Either in the various "Worker's Progress" reports, or in personal stats pages, add a metric that shows how much work has been saved by each worker. I say this not for myself, but because such a metric would be better for Xyzzy/nucleon to compete on, namely because it would be heavily weighted towards LLTF factors (where nucleon has a more-than-healthy lead).

[QUOTE=Dubslow;289615]I say this not for myself, but because such a metric would be better for Xyzzy/nucleon to compete on, namely because it would be heavily weighted towards LLTF factors (where nucleon has a more-than-healthy lead).[/QUOTE]

An excellent suggestion!!! :smile:

Work saved is a far more important metric that simply the number of factors found.

Perhaps this will help get our two giants back to the more important work before us....

Heh, right now I am #1 in work saved according to the website, but something must be wrong, because that cannot possibly be true, just by the # of LL factors found.

It's different now than it was ten minutes ago, and you're no longer #1, and nucleon is now much further ahead of Xyzzy (I remember thinking it was odd that nucleon was only ahead of Xyzzy by 200 GD, but now he's ahead by 2000 GD). I think chalsall fixed it.

[QUOTE=Dubslow;289625]It's different now than it was ten minutes ago, and you're no longer #1, and nucleon is now much further ahead of Xyzzy (I remember thinking it was odd that nucleon was only ahead of Xyzzy by 200 GD, but now he's ahead by 2000 GD). I think chalsall fixed it.[/QUOTE]

As always, my glory was both undeserved and temporary :smile:

[QUOTE=chalsall;289618]Work saved is a far more important metric that simply the number of factors found.[/QUOTE]

OK... This has been implemented on the various [URL="http://www.gpu72.com/reports/workers/"]Workers' Progress Reports[/URL].

Unfortunately, for those who don't understand what we're doing, some will ask "Why are they spending more time than they're saving?" since we're mostly comparing apples and oranges (GPUs and CPUs).

But for those who do understand, the results are interesting. Particularily, take a look at GDs Done vs Saved between Pete, Greg and Kyle.

Craig and Xyzzy -- you two still want to fight it out in the DC range??? :wink:

[QUOTE=Dubslow;289625]I think chalsall fixed it.[/QUOTE]

Just getting the SQL query "sane" on the fly. It's correct now.

Craig and Xyzzy are neck-and-neck. But surprisingly, Kyle with 28% of Craig's throughput, is not that far behind them in Savings....

[QUOTE=chalsall;289629]
Craig and Xyzzy are neck-and-neck. But surprisingly, Kyle with 28% of Craig's throughput, is not that far behind them in Savings....[/QUOTE]

That's because he only does one TF level above the current available. Look at each TF level completion count. The only reason he has any 70->71s is because we've mostly run out of exponents at 69.

[QUOTE=chalsall;289627]
Unfortunately, for those who don't understand what we're doing, some will ask "Why are they spending more time than they're saving?" since we're mostly comparing apples and oranges (GPUs and CPUs).
[/QUOTE]

Perhaps a quick one-liner at the top of the report?

[QUOTE=Dubslow;289631]That's because he only does one TF level above the current available. Look at each TF level completion count. The only reason he has any 70->71s is because we've mostly run out of exponents at 69.[/QUOTE]

Just asking.....taking LLTF to 72 is still the encouraged level, isn't it?

[QUOTE=kladner;289635]Just asking.....taking LLTF to 72 is still the encouraged level, isn't it?[/QUOTE]

Yes, definitely. He's been doing that since the start.

Just a quick eyeball it looks like to 72 is more effecient than >72.

[QUOTE=kladner;289635]Just asking.....taking LLTF to 72 is still the encouraged level, isn't it?[/QUOTE]

I know what you are saying. Greg is probably the best example of people who are under-appreciated by any metric outside of 'how many exponents did they release back to PrimeNet for LL'.

But at the end of the day, people have to do what makes them happy. So if our two biggest guys want to do some DC factoring, that's fine. I like to find LL factors. It just so happens that what I like to do happens to be measured by this new metric.

It isn't a measure of worth to the project or anything.

Edit: Who is Greg by the way? I know everyone else's handle in the top 8 on these boards. Is he just an infrequent poster?

[QUOTE=kladner;289635]Just asking.....taking LLTF to 72 is still the encouraged level, isn't it?[/QUOTE]

Indeed it is. That's where we release back to PrimeNet (after P-1, if needed), and where the majority of people are pledging to.

Some are choosing to do a "breadth first" search instead. I.e. only taking candidates up to 70 or 71. Nothing I can really do to stop that, nor (in my opinion) should I try to. At the end of the day, all of this work needs to be done.

For those pledging to go to 72, you can increase your chances of finding a factor (as a function of effort expended) by choosing the "Lowest TF Level" from the options menu. This will give you candidates only TFed to 70 (or 69 if available).

[QUOTE=oswald;289637]Just a quick eyeball it looks like to 72 is more effecient than >72.[/QUOTE]

Each level is slightly less than half as efficient as the previous level.

[QUOTE=KyleAskine;289638]Greg is probably the best example of people who are under-appreciated by any metric outside of 'how many exponents did they release back to PrimeNet for LL'.[/QUOTE]

Chuck and Roy too. They're focusing on the more expensive "last step" from 71 to 72.

[QUOTE=chalsall;289627]OK... This has been implemented on the various [URL="http://www.gpu72.com/reports/workers/"]Workers' Progress Reports[/URL].
[/QUOTE]
Nice one. Can we have that sortable by #, Fact, Saved or Done? :grin:

I like the new metric because suddenly people who run (mostly) AMD are on #3-5 of the charts :bow wave:

(there may be more AMD-GPUers that I don't know of ?)

[QUOTE=KyleAskine;289638]Edit: Who is Greg by the way? I know everyone else's handle in the top 8 on these boards. Is he just an infrequent poster?[/QUOTE]
Nice to make your acquaintance. :smile:

[QUOTE=chalsall;289640]Indeed it is. That's where we release back to PrimeNet (after P-1, if needed), and where the majority of people are pledging to.

Some are choosing to do a "breadth first" search instead. I.e. only taking candidates up to 70 or 71. Nothing I can really do to stop that, nor (in my opinion) should I try to. At the end of the day, all of this work needs to be done.

For those pledging to go to 72, you can increase your chances of finding a factor (as a function of effort expended) by choosing the "Lowest TF Level" from the options menu. This will give you candidates only TFed to 70 (or 69 if available).[/QUOTE]

No criticism, implied or otherwise was intended. I only meant to verify my own choices relative to the project.

Note: Been quite a spell since I saw a 69, except in DCTF.

If you check it religiously, a few appear every few days. I reserved the only one I saw today a few hours ago. :smile:

[QUOTE]Craig and Xyzzy -- you two still want to fight it out in the DC range??? :wink:[/QUOTE]The new "Saved" metric is exactly what we were hoping for. After our current run of DCTF work is done we will tackle this challenge aggressively!

:mike:

[QUOTE=frmky;289645]Nice to make your acquaintance. :smile:[/QUOTE]

Looks like I'm losing #3, did you add something or switch something over?

[QUOTE=bcp19;289666]Looks like I'm losing #3, did you add something or switch something over?[/QUOTE]
The older Tesla S1070 became free, so I'm doing some on it to 71-bits. It's only CC 1.3, so at 72 bits it switches from a mul24 kernel to a less efficient mul32 kernel. I've been using two GTX 480's for a while.

@chalsall: just a small cosmetic, does not seems quite normal to me to click on "workers" column header, to have the tables sorted according with... the output, which is a totally different column. The "worker" should sort the table alphabetically, for the case I am looking for an user. And maybe make the column headers of "saved", "factors", "ghzdays" whatever, clickable too, and sort accordingly when clicked (eventually with increasing/decreasing option, the second click changes the sort direction, and also the perfect thing would be to have different links on the last three column heders, depending on the fact if we are in P1, DC, LL, DCTF or LLTF "modes", you know what I mean)

[QUOTE=chalsall;289580]OK. That is actually quite easy to do. Five minutes, in fact.

I'm only rendering a total running average, rather than a seperate line for each work type. I think the graphs would get too cluttered with five lines.[/QUOTE]

Nice, and the data is different than what I expected which means it's giving useful info.

Agree on the separate lines - I thought it would be cool. But looking at what you've done there would be one readable line for GPU-TF and a bunch of overlapping lines near 0 for the rest. One line makes it easier to see what's actually happening.

[QUOTE=KyleAskine;289626]As always, my glory was both undeserved and temporary :smile:[/QUOTE]

14 minutes 15 seconds of fame remaining - use them wisely :)

[QUOTE=frmky;289681]The older Tesla S1070 became free, so I'm doing some on it to 71-bits. It's only CC 1.3, so at 72 bits it switches from a mul24 kernel to a less efficient mul32 kernel. I've been using two GTX 480's for a while.[/QUOTE]

I always wondered if the Tesla would work on this and what the throughput would be. Maybe when I win the lottery... Or find M48.

New individual graphs: GHz Days of Work Saved.
 

Just so you know, I've added a new graph to everyone's [URL="http://www.gpu72.com/reports/worker/fc9f090d094ad7c7eff10a39caffe3a4/"]Individual Worker's Overall Statistics Page[/URL] -- GHz Days of Work Saved per Day. :smile:

And a question for everyone... For those with sparce results (like, for example, [URL="http://www.gpu72.com/reports/worker/7e6a2e592a37a719fac4f765eb0f6ca8/"]Xyzzy[/URL], what do you think about my spreading the results across the previous days which didn't have any results (up to a limit of the result being no earlier than the assigned date)? This would lessen the extreme vertical scaling for people like Xyzzy who only check in every few days, and Carsten who lost access to his machine for a couple of weeks. This would make the charts more readable.

Anyone against this idea?

According to my graph of [url=http://www.gpu72.com/reports/worker/56f1b7572536a14513b08c88b2ba9578/]GHz Days per Day of Work Saved[/url] I've saved LLs and DCs, but no P-1s? Surely a TFLL factor would save 1 each of P-1, LL and DC?

[QUOTE=James Heinrich;289750]According to my graph of [url=http://www.gpu72.com/reports/worker/56f1b7572536a14513b08c88b2ba9578/]GHz Days per Day of Work Saved[/url] I've saved LLs and DCs, but no P-1s? Surely a TFLL factor would save 1 each of P-1, LL and DC?[/QUOTE]

Absolutely, and the graph is actually taking that into account. The problem is that a P-1 is so small in comparison to a LL/DC that it is scaled down so much that it is nearly invisible.

Edit: I'm not sure I like it, but if I turn off the rendering of the bar borders the P-1's are [I]just[/I] visible.

[QUOTE=chalsall;289751]The problem is that a P-1 is so small in comparison to a LL/DC that it is scaled down so much that it is nearly invisible.[/QUOTE]Oh... silly me. Somehow I was thinking number of tests saved, not effort saved. Thanks for making the P-1 savings visible.

[QUOTE=chalsall;289748]Just so you know, I've added a new graph to everyone's [URL="http://www.gpu72.com/reports/worker/fc9f090d094ad7c7eff10a39caffe3a4/"]Individual Worker's Overall Statistics Page[/URL] -- GHz Days of Work Saved per Day. :smile:

And a question for everyone... For those with sparce results (like, for example, [URL="http://www.gpu72.com/reports/worker/7e6a2e592a37a719fac4f765eb0f6ca8/"]Xyzzy[/URL], what do you think about my spreading the results across the previous days which didn't have any results (up to a limit of the result being no earlier than the assigned date)? This would lessen the extreme vertical scaling for people like Xyzzy who only check in every few days, and Carsten who lost access to his machine for a couple of weeks. This would make the charts more readable.

Anyone against this idea?[/QUOTE]

I'm not super keen on this idea, though I wouldn't complain if you did it. If you do this you should label it something else, since that chart would stop being what it seems it should be.

You could also make a separate scale on the right side just for the average GHz-d/saved and done lines so they aren't stuck to the bottom on people like xyzzy and me.

[QUOTE=KyleAskine;289766]You could also make a separate scale on the right side just for the average GHz-d/saved and done lines so they aren't stuck to the bottom on people like xyzzy and me.[/QUOTE]

Yeah, I don't really like altering true data either. And I actually wouldn't -- it would be a seperate field in the records for that table. But point taken.

The problem with a seperate axis is the GD::Graph module doesn't handle that properly for cumulative graphs, but I agree with you that it's the better solution. Maybe I need to climb into that code base and debug it....

In the overall system progress reports, the number of expos to each level per day are not bar graphs, and therefore don't have a regression. Is is possible to put the regression on there without the bar graph, and if not, change them to bar graphs?


[QUOTE=chalsall;289769]Yeah, I don't really like altering true data either. And I actually wouldn't -- it would be a seperate field in the records for that table. But point taken.

The problem with a seperate axis is the GD::Graph module doesn't handle that properly for cumulative graphs, but I agree with you that it's the better solution. Maybe I need to climb into that code base and debug it....[/QUOTE]
For me at least, at [url]http://gpu72.com/reports/worker/829a683f5d991e17d4cca0453117d491/[/url] , my Work Completed graph scale is all out of whack because my initial batch of work was done over week-long Thanksgiving break -- you can hardly see the rest of the graph.

[QUOTE=Dubslow;289781]In the overall system progress reports, the number of expos to each level per day are not bar graphs, and therefore don't have a regression. Is is possible to put the regression on there without the bar graph, and if not, change them to bar graphs?[/QUOTE]

Just so everyone knows, Dubslow has once again beaten me (:smile:) to announcing that I've added an overall GHz Days per Day of Work Saved graph, and a Linear Regression Trend line to many of the graphs, on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL] page.

I've been thinking about how to do this for the TF Depth graphs. The problem I'm having is what would I regress?

The aggregate of each completion type?

Those that have been TFed to the release level?

I need to run some experiments, and see what visually communicates the information best.

Whoops :razz: I thought that was part of the stuff discussed above my post. Didn't mean to steal your thunder :P

Good point, I hadn't thought about that. My initial suggestion would be just regress the 72, but if your experiments show something else is best, then whatever works.

I probably just missed the announcement of a GPUto72 feature, but I just noticed that now, clicking on an exponent in the View Assignments page plugs it into the PrimeNet "Exponent Status" widget.

Another great convenience! Many thanks, chalsall.

[QUOTE=chalsall;289787]Just so everyone knows, Dubslow has once again beaten me (:smile:) to announcing that I've added an overall GHz Days per Day of Work Saved graph, and a Linear Regression Trend line to many of the graphs, on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL] page.
[/QUOTE]

All you need to do is find the webcam he stashed in your room so he can watch what you are doing and beat you to the punch.

[QUOTE=chalsall;289751]

Edit: I'm not sure I like it, but if I turn off the rendering of the bar borders the P-1's are [I]just[/I] visible.[/QUOTE]

I don't like the way the graphs look without the border.

Brent-Suyama 0_o

[url]http://mersenne-aries.sili.net/exponent.php?exponentdetails=52827883[/url]


Also: [URL="http://gpu72.com/reports/worker/69e746069963cd4101e668076c65188f/"]suspicious[/URL]

[QUOTE=Dubslow;289828]Brent-Suyama 0_o
[url]http://mersenne-aries.sili.net/M52827883[/url][/QUOTE]Parsing data from PrimeNet I don't know what bounds were used to find a P-1 factor, or even that P-1 was used at all. If you can submit you results.txt to the site then you'll get the pretty P-1 graph that clearly shows the factor outside the used P-1 bounds.

[QUOTE=chalsall;289787]Just so everyone knows, Dubslow has once again beaten me (:smile:) to announcing that I've added an overall GHz Days per Day of Work Saved graph, and a Linear Regression Trend line to many of the graphs, on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL] page.
[/QUOTE]

That graph looks highly suspicious... Just roughly adding the DC saved in the graph would give about 30,000 GD in the last 30 days, but if we look at the overall report it shows we have only saved about 16,925 GD for DC since the project started.

[QUOTE=Xyzzy;289655]The new "Saved" metric is exactly what we were hoping for. After our current run of DCTF work is done we will tackle this challenge aggressively!

:mike:[/QUOTE]

Ok, if you go back to LL TF, I guess I will as well.

-- Craig

On optimizing for metrics, here's what I've found:

To optimize for:
1) Done GHZ-days/day:
Do LL TF, with x,y bit levels with the "Stages=0" command in mfaktc.ini, with x being the lowest bit level you can get your hands on, and y being the highest bit level you're prepared to work on. For me generally, it's been bit levels 70 to 72.

2) Factors found
Do the lowest single bit level on DCTF. Generally I've been doing 68 to 70 (or 67 to 70 if I can get them). Mainly I go the 'to 70' method as if I did single bit level, the managment overhead is too much.

3) Saved GHZ-days/day
Do the lowest single bit level on LLTF generally that will be 70-71.

These are incompatible strategies.

Before I embark on (3), can I confirm that's what is in the best interests of the project. Or do I keep going with (1)? The difference between (1) and doing (3) as 70-71 then 71-72 is only a few percent. But that adds up on a farm my size.

-- Craig

[QUOTE=nucleon;289880]These are incompatible strategies.

Before I embark on (3), can I confirm that's what is in the best interests of the project. Or do I keep going with (1)? The difference between (1) and doing (3) as 70-71 then 71-72 is only a few percent. But that adds up on a farm my size.[/QUOTE]

The best thing for [I][U]GIMPS[/U][/I] (which is what the project was created to help) is to do as much TFing (and P-1ing) as we're going to do, and then get candidates back into the PrimeNet pool as quickly as possible. Thus, in the LL range, TFing to 72 is the best thing.

Having said that, TFing from 71 to 72 takes twice as long as TFing from 70 to 71, with approximately the same chance of finding a factor. This is why many people are doing lower bit-levels; and I have no problem with that -- some enjoy finding factors and the work has to be done.

For people like you Craig, I'd recommend you use the "Lowest TF Level" option in the Get Assignments pages, but (if you would be so kind) take them up to 72 bits (with the "Stages=0" option which as you point out is more efficient).

As an aside, there is really no reason to do DC TF work at the moment, although I know some people enjoy doing so. We are so far ahead of the "wave" that we could do no DC TF work for several months, and there would still be no DC assignments from PrimeNet which were not already at at least 69 bits.

Quote chalsall: " (with the "Stages=0" option which as you point out is more efficient)."

Craig- What is your setting for StopAfterFactor? It seems that it has to be 0 or 2. Are you letting them run all the way (0) on the chance of finding another factor?

[QUOTE=James Heinrich;289597]I think that is the more interesting number. Would it be possible to present the average line in the graph as a 30-day moving average rather than start-to-now average?[/QUOTE]

This has been done on the GHz Days of Work Done graphs. I'll do it on the GHz Days of Work Saved graphs shortly.

[QUOTE=diamonddave;289869]That graph looks highly suspicious... Just roughly adding the DC saved in the graph would give about 30,000 GD in the last 30 days, but if we look at the overall report it shows we have only saved about 16,925 GD for DC since the project started.[/QUOTE]

I think he's counting an LLTF factor saves like 90 GHz days LL, and 90 GHz days DC.

[QUOTE=James Heinrich;289861]Parsing data from PrimeNet I don't know what bounds were used to find a P-1 factor, or even that P-1 was used at all. If you can submit you results.txt to the site then you'll get the pretty P-1 graph that clearly shows the factor outside the used P-1 bounds.[/QUOTE]
It was P-1, but I'm not at my desktop for the weekend, and can submit the file when I get back Sunday night. (I usually submit P95 results files every month or two.) The bounds would be whatever MPrime chose at the given TF level, assuming "up to 10000 MB" of memory. (I think in this case B1 is either 505K or 510K.)

[QUOTE=Dubslow;289889]I think he's counting an LLTF factor saves like 90 GHz days LL, and 90 GHz days DC.[/QUOTE]

That's correct. But I'm going to do an audit of that data shortly just to make sure it's sane.

I just noticed the URL for the "GPU to 72" team in PrimeNet is still [url]http://gpu.mersenne.info/[/url]
You may want to change that to [url]http://www.gpu72.com/[/url] ?

[QUOTE=James Heinrich;289895]I just noticed the URL for the "GPU to 72" team in PrimeNet is still [url]http://gpu.mersenne.info/[/url]
You may want to change that to [url]http://www.gpu72.com/[/url] ?[/QUOTE]

Thanks James. Had totally missed that.

And was that your subtle way of letting me announce that the GPU to 72 team is now #1 for Trial Factoring, and #3 for P-1 Factoring??? :smile:

Thanks for all the cycles everyone! :cool:

[QUOTE=chalsall;289898]Thanks James. Had totally missed that.

And was that your subtle way of letting me announce that the GPU to 72 team is now #1 for Trial Factoring, and #3 for P-1 Factoring??? :smile:

Thanks for all the cycles everyone! :cool:[/QUOTE]
I didn't say anything because it was kinda cool that the last-modified date was the same as the created date :P

Oh well. Awesome!

[QUOTE=kladner;289883]Craig- What is your setting for StopAfterFactor? It seems that it has to be 0 or 2. Are you letting them run all the way (0) on the chance of finding another factor?[/QUOTE]

StopAfterFactor=2

Once I've found a factor - I'm outta here.

-- Craig

[QUOTE=chalsall;289882]The best thing for [I][U]GIMPS[/U][/I] (which is what the project was created to help) is to do as much TFing (and P-1ing) as we're going to do, and then get candidates back into the PrimeNet pool as quickly as possible. Thus, in the LL range, TFing to 72 is the best thing.

Having said that, TFing from 71 to 72 takes twice as long as TFing from 70 to 71, with approximately the same chance of finding a factor. This is why many people are doing lower bit-levels; and I have no problem with that -- some enjoy finding factors and the work has to be done.

For people like you Craig, I'd recommend you use the "Lowest TF Level" option in the Get Assignments pages, but (if you would be so kind) take them up to 72 bits (with the "Stages=0" option which as you point out is more efficient).

As an aside, there is really no reason to do DC TF work at the moment, although I know some people enjoy doing so. We are so far ahead of the "wave" that we could do no DC TF work for several months, and there would still be no DC assignments from PrimeNet which were not already at at least 69 bits.[/QUOTE]

Basically you said what I was thinking of anyhow. I'll finish what I have allocated (as it's a pain to return 5000+ candidates across 18 instances :)

I'll move onto 'x to 72' after the current allocation is finished.

-- Craig

[QUOTE=chalsall;289882](with the "Stages=0" option which as you point out is more efficient).
[/QUOTE]
Man, how did I miss this one?

I just picked up some speed. :smile:

[QUOTE=nucleon;289911]StopAfterFactor=2

Once I've found a factor - I'm outta here.

-- Craig[/QUOTE]

Thanks!

[QUOTE=oswald;289918]Man, how did I miss this one?

I just picked up some speed. :smile:[/QUOTE]

I just made this change also.

[QUOTE=chalsall;289882]with the "Stages=0" option which as you point out is more efficient[/QUOTE]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?

[QUOTE=James Heinrich;289935]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?[/QUOTE]

It's something I played with in testing. I don't understand the how/why mechanics on why it's faster.

There maybe certain combinations where it's not faster. I'm not sure what combos these are. As a general rule, it's something I've been doing.

-- Craig

[QUOTE=James Heinrich;289935]Assuming an assignment of 69-71 (for example) then I can see that being potentially more efficient. But if you have an assignment like 70-72, wouldn't you also [i]lose[/i] some efficiency by having to use the 79-bit core on the 70-71 segment instead of the 71-bit core?[/QUOTE]

On CC 2.0+ cards, I think the barret79_mul32 kernel is used regardless of the bit level. But this could be a concern for people with older cards (GTX 2xx and older) which a different kernel for < 72 bit tests.

[QUOTE=James Heinrich;289861]Parsing data from PrimeNet I don't know what bounds were used to find a P-1 factor, or even that P-1 was used at all. If you can submit you results.txt to the site then you'll get the pretty P-1 graph that clearly shows the factor outside the used P-1 bounds.[/QUOTE]

[url]http://mersenne-aries.sili.net/exponent.php?factordetails=35555090100297483645409[/url]

Weekend activities...
 

Hey all. Just so people know, over the weekend I:

- Added a "Released Trend" (Linear Regression) line to the Trial Factoring Depth per Day graphs on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL].

- Tweeked the LR lines on the other graphs so the current day is not including in the linear regression. This is to prevent the trend line varying during the day, and tending to be a lower slope than it should be.

- Made both of the daily GHz Days graphs on the [URL="http://www.gpu72.com/reports/worker/4d89b8ff781e27a0fe80450cd4cd74b6/"]Individual Stats[/URL] pages have a 30 day moving average rather than an overall running average.

- Added a conditional for the Individual graphs so the X-axis date labels don't bunch up / overwrite for those who have been with the project for while.

- Fell off a Segway at 15 km/h onto coral stone. Three times... Semi-serious abrasions on both arms, and possibly a broken toe... Boy was it fun!!! :smile:

[QUOTE=chalsall;290079]Hey all. Just so people know, over the weekend I:

- Added a "Released Trend" (Linear Regression) line to the Trial Factoring Depth per Day graphs on the [URL="http://www.gpu72.com/reports/overall/graph/month/"]Overall System Progress Graphs[/URL].

- Tweeked the LR lines on the other graphs so the current day is not including in the linear regression. This is to prevent the trend line varying during the day, and tending to be a lower slope than it should be.

- Made both of the daily GHz Days graphs on the [URL="http://www.gpu72.com/reports/worker/4d89b8ff781e27a0fe80450cd4cd74b6/"]Individual Stats[/URL] pages have a 30 day moving average rather than an overall running average.

- Added a conditional for the Individual graphs so the X-axis date labels don't bunch up / overwrite for those who have been with the project for while.

- Fell off a Segway at 15 km/h onto coral stone. Three times... Semi-serious abrasions on both arms, and possibly a broken toe... Boy was it fun!!! :smile:[/QUOTE]
While I really appreciate what you're doing, I think the last item could have been done a bit differently ...

The linear trend in "work saved" is falling. What is the expected date when GPU to 72 crosses the zero line?

[QUOTE=MrHappy;290334]The linear trend in "work saved" is falling. What is the expected date when GPU to 72 crosses the zero line?[/QUOTE]

It's temporary... A couple of our "big guns" went over to DCTFing fighting for the Factor's Found metric. Then Dubslow pointed out that perhaps GHz Days Saved was a better metric.

Nothing happens fast here. But keep an eye on that trend line over the next month. It will become positive again in about two weeks... :smile:

[QUOTE=chalsall;290341][strike] It[/strike] [u]The derivative[/u] will become positive again in about two weeks... :smile:[/QUOTE]
:smile::smile: #iamsuchanerd #nerdorgeek?

[QUOTE=Dubslow;290364]:smile::smile: #iamsuchanerd #nerdorgeek?[/QUOTE]
Then, it will hold water again in about one week. Or does it hold water already?

So PrimeNet is assigning TF in the 56M range, and I just got a 54.9M P-1 assignment. I think we should seriously consider how necessary it is to reserve assignments >55M or >56M as LLs via the GPU 2 72 system.

Well, it was fun as long it lasted... :P

Now joking apart, we would need a "system" to coordinate at least the LLTF and DCTF assignments for GPUs. Primenet does not always give you lowest assignments, I got TF on 68M and higher... You can be lucky when someone drops a big bunch of lower stuff just before you ask Primenet for more work, but this is seldom. A system of trust on primenet (in fact, p95 doing the job gpu272 is doing now, assigning lower expos to more-trusted users) would be fine, but as long as we do not have it....

And moreover, is more fun competing on the closer circle of gpu272, with 30 users, instead of primenet with 5000 users :D

Something wrong with the assignment system for DC (and LL, P-1, perhaps)?
 

I just randomly checked what primenet thinks about some of my assignments, and I noticed that almost all of my DC assignments have been assigned to other people by primenet ...

For example [B][URL="http://www.mersenne.org/report_exponent/?exp_lo=26173363"]26173363[/URL] [/B]was assigned to me by GPU272 on 2012-02-03. Primenet assigned it as Double-checking to "KYOJI_KAMEI" on 2012-02-03 (which is not me :smile:).

[B][URL="http://www.mersenne.org/report_exponent/?exp_lo=26087387"]26087387[/URL][/B] was assigned to be by GPU272 on 2012-01-11. Primenet lists it as Double-checking to "ANONYMOUS" on 2012-02-22 --- if that is me, then why was it assigned today? I assume it was reassigned to someone else.

I already unreserved a few of my DC's from GPU272 when I noticed that many of them are almost complete on machines that have no internet access.

I now decided to kick all DC assignments that have no or less than 10% of their work done. Assignments that have more than 75% done already will keep going (there were none between 10-75%).

But what is happening here? And do I need to check each of my GPU272 assignments if they are still valid? Or just DC and LL which are supposed to be assigned to ourselves (which is not happening for machines with no internet)? What about P-1?

Is there some way GPU272 could help identifying cases where primenet reassigned stuff differently than GPU272?

[QUOTE=Bdot;290449]...[/QUOTE]
Go see the last 5 or so posts in the [URL="http://www.mersenneforum.org/showthread.php?t=16352&page=3"]assignment discrepancy thread[/URL] (starting from #54).

[QUOTE=LaurV;290421]

Now joking apart, we would need a "system" to coordinate at least the LLTF and DCTF assignments for GPUs. Primenet does not always give you lowest assignments, I got TF on 68M and higher... You can be lucky when someone drops a big bunch of lower stuff just before you ask Primenet for more work, but this is seldom. A system of trust on primenet (in fact, p95 doing the job gpu272 is doing now, assigning lower expos to more-trusted users) would be fine, but as long as we do not have it....

And moreover, is more fun competing on the closer circle of gpu272, with 30 users, instead of primenet with 5000 users :D[/QUOTE]

I do agree that we still need it for DCTF and for the lower LLTF -- but not necessarily the higher stuff. Perhaps other users can see what sort of TF they get from PrimeNet?