mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > Twin Prime Search

Reply
 
Thread Tools
Old 2007-01-09, 14:12   #1
pacionet
 
pacionet's Avatar
 
Oct 2005
Italy

3×113 Posts
Default

Uploaded 3100-3600M for PrimeGrid.

My proposal is: when PrimeGrid finish beta phase:

1) who wants to test number should go BOINC and join PrimeGrid
2) manual reservation will be stopped
3) www.twinprimesearch.org will be replaced (in some time) by a site for distribute sieving
pacionet is offline   Reply With Quote
Old 2007-01-09, 16:31   #2
MooooMoo
Apprentice Crank
 
MooooMoo's Avatar
 
Mar 2006

1C316 Posts
Default

Quote:
Originally Posted by pacionet View Post
Uploaded 3100-3600M for PrimeGrid.

My proposal is: when PrimeGrid finish beta phase:

1) who wants to test number should go BOINC and join PrimeGrid
2) manual reservation will be stopped
Yes, but I want these features implemented before PrimeGrid finishes beta phase:

1.) Treat a hyperthreaded P4 as one processor, not two. Running two instances of LLR on an HT P4 often causes overheating, and this often leads to incorrect results. For example, one of my older computers (10% overclock) was spitting out bad results almost every hour when 2 instances of LLR were run. However, when only one instance of LLR was run, the processor would become extremely stable. Even after a week's worth of 24 hour usage, the processor did not get a single wrong result on the Prime95 torture test, even though the room often reached 30 degrees (Celsius).

I dumped that computer after 2005, and the non-overclocked comps I now use no longer have that problem. However, the fan gets REALLY loud when 2 instances of LLR are run, and it's pretty quiet when only one instance of LLR is run.

2.) Separate LLR work from Primegen work, and merge the stats from the manual reservation. For example, lsoule did 100M of work a while ago, but did not join PrimeGrid. Assuming 360 candidates per 1M and 0.39 credit for each candidate tested, lsoule's PrimeGrid credit will be at 14040 (360*100*0.39). Therefore, if he does decide to join PrimeGrid, then the first workunit he completes will put him at 14040.39, not 0.39. Also, the stats should be done by total credit, not recent average credit.

3.) Let users see which k they're working on. Instead of having files called llr_TPS_512320 for 123456789*2^195000-1, the files should be named after the k values, so 123456789*2^195000-1 will look like llr_TPS_123456789.

4.) 10% or fewer candidates should be doublechecked.

Last fiddled with by MooooMoo on 2007-01-09 at 16:33
MooooMoo is offline   Reply With Quote
Old 2007-01-10, 12:05   #3
Rytis
 
Rytis's Avatar
 
Nov 2006

83 Posts
Default

1) It is already possible, however, it's never going to be an automated option, because BOINC is a multiproject platform, and most users run not only PrimeGrid. If you want the limit, go to your preferences and set BOINC to use only one processor. You may wish to assign a separate venue for P4s if you have for example P4s and Core 2 Duos.

2) Separate stats are already being collected. Just that I'm a human just like you and don't have time to create a script to display everything. As for assigning credit for old-time TPS users, it can be done, but again, not automatically, as we would need some verification that it's an old-time user and not just a new user with the same nickname. You can easily switch stats to a different method (RAC/Total). This is a default in BOINC sites, and I'm not changing that unless default changes (doubting that).

3) That's a scheduler limitation, not possible to do (ok, possible, but needs a lot of work). Don't expect this until at least summer. The easier way would be to add a basic graphics option which would display workunit data.

4) I'll correct this - 10% or less tasks to be initially doublechecked, +doublechecking possible error results (picky scheduler).
Rytis is offline   Reply With Quote
Old 2007-01-10, 16:10   #4
gribozavr
 
gribozavr's Avatar
 
Mar 2005
Internet; Ukraine, Kiev

1100101112 Posts
Default

3) I don't really want this feature, but maybe you could add k and keep old information too? So that the name becomes llr_TPS_111__222_333_444
where 111 is k, and 222 333 444 is any other information sheduler needs.
gribozavr is offline   Reply With Quote
Old 2007-01-10, 16:31   #5
MooooMoo
Apprentice Crank
 
MooooMoo's Avatar
 
Mar 2006

45110 Posts
Default

Quote:
Originally Posted by Rytis View Post
1) It is already possible, however, it's never going to be an automated option, because BOINC is a multiproject platform, and most users run not only PrimeGrid. If you want the limit, go to your preferences and set BOINC to use only one processor. You may wish to assign a separate venue for P4s if you have for example P4s and Core 2 Duos.
Fine with me. I just wanted people to have an opportunity to get only one instance of LLR running, without having to turn off hyperthreading in the BIOS.

Quote:
Originally Posted by Rytis
2) Separate stats are already being collected. Just that I'm a human just like you and don't have time to create a script to display everything. As for assigning credit for old-time TPS users, it can be done, but again, not automatically, as we would need some verification that it's an old-time user and not just a new user with the same nickname. You can easily switch stats to a different method (RAC/Total). This is a default in BOINC sites, and I'm not changing that unless default changes (doubting that).
I guess PrimeGrid could finish beta without showing these stats. However, once we move to the next n, people (including old-timers) should be able to see their total TPS stats for n=195,000.

Quote:
Originally Posted by Rytis
3) That's a scheduler limitation, not possible to do (ok, possible, but needs a lot of work). Don't expect this until at least summer. The easier way would be to add a basic graphics option which would display workunit data.
OK, but I want this feature there eventually. It's perfectly understandable if you don't have time now, but I want to see the feature there in a reasonable amount of time (hopefully before the end of this year).

Quote:
Originally Posted by Rytis
4) I'll correct this - 10% or less tasks to be initially doublechecked, +doublechecking possible error results (picky scheduler).
Looks good I just don't want more than a 10% initial doublecheck, but doublechecking possible error results is fine (I'm assuming that usually, less than 10% of all results returned will be possible error results).
MooooMoo is offline   Reply With Quote
Old 2007-01-10, 22:20   #6
jasong
 
jasong's Avatar
 
"Jason Goatcher"
Mar 2005

5·701 Posts
Default

Since Rytis is, in fact, donating his free time to this project, I would like to celebrate this with 5(count 'em, 5) dancing bananas!!!

You rock, Rytis!!!
jasong is offline   Reply With Quote
Old 2007-01-11, 10:43   #7
Rytis
 
Rytis's Avatar
 
Nov 2006

83 Posts
Default

:)
Rytis is offline   Reply With Quote
Old 2007-01-11, 15:05   #8
Padanian
 
Jan 2007

2·3 Posts
Default

Quote:
Originally Posted by MooooMoo View Post
Yes, but I want these features implemented before PrimeGrid finishes beta phase:

1.) I dumped that computer after 2005, and the non-overclocked comps I now use no longer have that problem. However, the fan gets REALLY loud when 2 instances of LLR are run, and it's pretty quiet when only one instance of LLR is run.
I don't think that your personal experience with badly assembled hardware shall affect other users or require more work from developers.
And it is already possible to activate 1 single CPU on HT processor via the user preferences in your account page.
I have an overclocked 3.4GHz at 3.8GHz and happily running without errors at 48°C of CPU temperature and it is not even running at full speed. The cpu fan is an arctic freezer pro 7 which can be barely heard. As you see, YMMV.

Quote:
Originally Posted by MooooMoo View Post
2.) Separate LLR work from Primegen work, and merge the stats from the manual reservation. For example, lsoule did 100M of work a while ago, but did not join PrimeGrid. Assuming 360 candidates per 1M and 0.39 credit for each candidate tested, lsoule's PrimeGrid credit will be at 14040 (360*100*0.39). Therefore, if he does decide to join PrimeGrid, then the first workunit he completes will put him at 14040.39, not 0.39.
If I'd joined let's say DC.net they will not credit me the work done for SETI. I don't see why the database should merge. Afterall we are not crunching for credits, but for finding a twin.

Quote:
Originally Posted by MooooMoo View Post
Also, the stats should be done by total credit, not recent average credit.
No. RAC sorting highlights the ACTUAL and PRESENT effort of the user, not the PAST effort of the user (which also depends on how much time he has been crunching since). I think RAC still is more representative than TC.

Quote:
Originally Posted by MooooMoo View Post
3.) Let users see which k they're working on. Instead of having files called llr_TPS_512320 for 123456789*2^195000-1, the files should be named after the k values, so 123456789*2^195000-1 will look like llr_TPS_123456789.
Go to primegrid slot directory and open the WU file(s) with notepad. If it's so important to know the k anybody is working on, he/she can surely make the effort to discover him/herself.


Cheers
Padanian is offline   Reply With Quote
Old 2007-01-11, 16:06   #9
MooooMoo
Apprentice Crank
 
MooooMoo's Avatar
 
Mar 2006

11×41 Posts
Default Primegrid discussions

I've moved all primegrid discussions to this thread.
MooooMoo is offline   Reply With Quote
Old 2007-01-11, 16:28   #10
MooooMoo
Apprentice Crank
 
MooooMoo's Avatar
 
Mar 2006

7038 Posts
Default

Quote:
Originally Posted by Padanian View Post
If I'd joined let's say DC.net they will not credit me the work done for SETI. I don't see why the database should merge. Afterall we are not crunching for credits, but for finding a twin.
Of course it won't, because dc.net and seti are different projects. However, the PrimeGrid reservations and the manual reservations are working on the exact, same, twin-finding project. This is why I don't see a reason why past manual reservation users should not get PrimeGrid TPS credit for their work. You may not be crunching for credits, but stats matter to a lot of crunchers (especially old manual reservation users, who feel that they were not given recognition for their previous efforts).

Quote:
No. RAC sorting highlights the ACTUAL and PRESENT effort of the user, not the PAST effort of the user (which also depends on how much time he has been crunching since). I think RAC still is more representative than TC.
There's nothing wrong with having RAC there, but total credit should be there too. The TC determines the top producer, who will share credit for the discovery of a twin prime.

Suppose user A works on the project from January to October and puts 10 comps on the project. He then quits, and a few years later, user B decides to put one comp on the project from January until February, when the twin is found. If RAC were used, user B would have a higher ranking than user A, even though it was user A who put in the most work on the project. That's why TC will be used for determining the top producer.

Quote:
Go to primegrid slot directory and open the WU file(s) with notepad. If it's so important to know the k anybody is working on, he/she can surely make the effort to discover him/herself.
Knowing what k a user is working on is not terribly important to me nor anyone else. However, being able to find out what k you're working on as soon as you look at the screen is a nice feature that should be there. It isn't a top priority, but it should be there eventually.
MooooMoo is offline   Reply With Quote
Old 2007-01-12, 19:32   #11
Rytis
 
Rytis's Avatar
 
Nov 2006

83 Posts
Default

A few highlights:

total credit is available on every stats page (whereas RAC is not) (please correct me if I'm wrong);
when a twin is found, the total contribution from both manual LLRing and PG (if the user moved over to PG) should be counted. LLR test count done is being recorded, and we can approximately calculate work done by multiplying M done in the original TPS by 360 (or dividing PG work done by 360, to get approximate M);
the option to see current k/n pair will be available some day.
Rytis is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Soapbox Discussions only_human Soap Box 41 2019-11-16 15:46
Our discussions here: how can we improve things? Brian-E Soap Box 105 2013-11-10 12:26
Sieve reservation discussions jmblazek Twin Prime Search 27 2007-01-31 21:41
Distributed sieving discussions michaf Sierpinski/Riesel Base 5 76 2006-09-12 18:37
Automated PRP discussions ltd Sierpinski/Riesel Base 5 20 2006-09-02 22:19

All times are UTC. The time now is 00:39.

Fri Nov 27 00:39:42 UTC 2020 up 77 days, 21:50, 3 users, load averages: 1.21, 1.42, 1.47

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.