Primegrid discussions

[pacionet]

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

[MooooMoo]

Originally Posted by pacionet

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.

[Rytis]

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

[gribozavr]

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.

[MooooMoo]

Originally Posted by Rytis

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.

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.

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

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

[jasong]

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!!!

[Rytis]

:)

[Padanian]

Originally Posted by MooooMoo

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.

Originally Posted by MooooMoo

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.

Originally Posted by MooooMoo

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.

Originally Posted by MooooMoo

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

[MooooMoo]

I've moved all primegrid discussions to this thread.

[MooooMoo]

Originally Posted by Padanian

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

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.

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.

[Rytis]

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.