| Author |
Message |
|---|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
                               
|
|
Tour de Primes 2018
Welcome to the 10th annual Tour de Primes. 2 is the first prime number...and the only even one. This makes it unique among prime numbers. Therefore, February is declared Prime month...being the 2nd month of the year. :) And there's no better way to pay homage to a prime number than to go out and find one. :) More precisely, a Top 5000 prime.
For the month of February, an informal competition is offered. There are no challenge points to be gained... just a simple rare jersey at the end of the month to add to your badge list. No pressure or stress other than what you put on yourself. :)
For 2018, we're adding four new badges you can win -- and these are available to everyone!
 Red Jersey -- discoverer of largest prime
 Yellow Jersey -- prime count leader (tiebreaker will be prime score)
 Green Jersey -- points (prime score) leader
 Polk-a-dot Jersey -- on the 19th of February we'll have a "Mountain Stage" and award the Polk-a-dot Jersey to the one who finds the most primes on that day (tiebreaker will be prime score for that day).
 Prime badge -- awarded to everyone who finds an eligible prime during the month of February. This is a counter badge, so if you find more than one prime it will show how many you've found, up to 99.
 Mega prime badge -- awarded to everyone who finds a mega prime during February. This is a counter badge.
 Mountain Stage prime badge -- awarded to everyone who finds an eligible prime during the Mountain Stage. This is a counter badge.
 Mountain Stage mega prime badge -- awarded to everyone who finds a mega prime during the Mountain Stage. This is a counter badge.
Results will be available at http://www.primegrid.com/challenge/tdp_2018.php.
As with the last few years, for all primes (BOINC and PRPNet) we're using the new reporting system whereby the prime's date of discovery determines whether it's eligible for the Tour de Primes. Prior to 2014, the date of verification for BOINC primes was used while the discovery date was used for PRPNet primes. The current system is more intuitive and fairer.
Note that SGS-LLR and GFN-15 are too small to be reported to the Top 5000 primes list and are therefore not eligible for the 2018 Tour de Primes.
Currently, the fastest opportunities to find Top 5000 primes is with the PPSE (LLR), and GFN-16 (65536) projects. Of course, should someone find a prime in the mega-prime searches, this would certainly give them a good shot at the green jersey. Not a guarantee, however, as in 2017 there were several mega primes found in the Tour de Primes. Overall, in 2017 we averaged more than one mega prime per week for the entire year, so you might need more than "merely" a mega prime to take home green. In 2017 there were 10 mega primes found during Tour de Primes.
At the current time, PRPNet is not running. If that changes, all ports in PRPNet would be available for the competition.
To participate in BOINC PPSE (LLR), GFN-16, or any other eligible LLR or Genefer project, all you have to do is select it in your PrimeGrid preferences. AP27 sequences are not reportable at T5K, so are not eligible for Tour de Primes.
Good Luck, have fun, and enjoy! :D
Previous Winners
 - wdethomas
 - tng*
 - wdethomas
 - tng*
 - boss
 - Scott Brown
 - boss
 - Orange_1050
 - Scott Brown
 - Randall J. Scalise
 - vmc
 - [DPC]x-RaY99_the_one_man_team
 - [DPC]x-RaY99_the_one_man_team
 - Lonnie Christensen
 - [DPC]x-RaY99_the_one_man_team
 - [DPC]x-RaY99_the_one_man_team
 - PBT_marian_boss
 - Scott Brown
 - Usucapio Libertatis
 - Scott Brown
 - shanky123
 - [BOINCstats] LostBoy
 - Snf*
 - lennart
 - lennart
 - [SG]marodeur6
 - lennart
 - s-yama
 - lennart
Full rankings can be seen here: 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017
Totals by Year
2009 2010 2011 2012 2013 2014 2015 2016 2017
Total Primes found 212 309 766 646 238 254 254 346 246
Total Score 457.30 2663.27 21803.72 20727.04 15614.83 20982.77 30268.46 43656.50 40201.94
Tips and Strategies:
Tip #1: He (or she) who finds the prime FIRST is the discover of the prime. It's a competition between you and your wingman. While having a fast computer helps, your computer is only useful when it's running a task. If you have a cache of tasks sitting on your computer waiting to run, chances are your wingman will return the task before you've even started it. Setting both BOINC cache settings to "0 days" is strongly recommended. People with slow computers find primes all the time because their wingman downloaded the task yesterday but won't start running it until tomorrow. Set your cache to 0 days!
If you're going to ignore tip #1, don't even bother reading the rest. Seriously.
Tips for LLR:
- Your mileage may vary. What works for me may not work for you. Before TdP starts, take some time and experiment and see what works best on your computer.
- If you have an Intel CPU with hyperthreading, either turn off the hyperthreading in the BIOS, or set BOINC to use 50% of the processors. (But see below for exceptions.)
- If you're using a GPU for other tasks, it may be beneficial to leave hyperthreading on in the BIOS and instead tell BOINC to use 50% of the CPU's. This will allow one of the hyperthreads to service the GPU.
- Use LLR's multithreaded mode. It requires a little bit of setup, but it's worth the effort. Follow these steps:
Tips for GFN:
- Only run GFN on a GPU. Use your CPU for LLR tasks where it will be much more efficient.
- Unless you have a really slow GPU and a really fast CPU, leave a CPU core free to service the GPU. You'll want the more powerful GPU running at full speed, even if it slows down the CPU somewhat. A hyperthread should be sufficient if your CPU supports hyperthreading. For example, on a 4 core CPU (without hyperthreading), you could set BOINC to "use 75% of the CPUs" to reserve one core for the GPU.
____________
My lucky number is 75898524288+1
|
|
|
Scott BrownVolunteer moderator
Project administrator
Volunteer tester
Project scientist
Send message
Joined: 17 Oct 05
Posts: 2392
ID: 1178
Credit: 18,631,505,153
RAC: 7,088,033
                                               
|
The first time BOINC downloads an SoB task, it may act a little strange and download 4 tasks instead of 1. The run times on this first set of tasks may look a bit strange too. This is normal. This will also occur anytime BOINC downloads more than one task at a time.
For this tip, I thought an example might be helpful. So...
Example:
Computer A (an i5 running 100% CPUs) is reset to use 4-core multi-thread LLR for ESP tasks. The first time the config file is read, Computer A will download 4 ESP tasks and begin working on 1 task on 4 cores while the other 3 tasks are waiting (one would want to abort these three extra tasks for the TDP).
Computer A then is switched to PPSE for tasks. As the ESP completes, it will download and run 4 PPSE tasks all at the same time (assuming that PPSE has NOT been set to run 4-core multi-thread).
Computer A then is switched back to ESP. In this case, Computer A will again download 4 ESP tasks and begin a single task with 4-core multi-thread while the other 3 wait.
As Mike noted above, one can avoid the extra downloads with his suggestion. Of course, another option is to have all applications that will be used running the same multi-thread settings (i.e., in the above example, if PPSE were set to run 4-core multi-thread, then switching between it and ESP would not result in extra task downloads).
|
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3206
ID: 130544
Credit: 2,284,240,700
RAC: 922,232
                    
|
|
Observation: "The first time BOINC downloads an SoB task": this paragraph is showing as being SoB specific rather than all. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Observation: "The first time BOINC downloads an SoB task": this paragraph is showing as being SoB specific rather than all.
Thanks, fixed.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I didn't see a start/end time, except 00:00 UTC for the Mountain Stage over at the stats page.
So since the start time is possibly open, I simply must suggest 00:02 UTC. ;) |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
I didn't see a start/end time
2018-2-1 00:00:00 until 2018-3-1 00:00:00
It's always the entire month of February.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Right now (well, not right now but in about 10 days), what is the most likely place to get one of these? PPSE or GFN 16? By checking the "Newly reported primes" it looks to close to call...
Edit: they are both at the opening post of this thread and I believe the answer might depend on the hardware you have. The question still stands: assuming I can crunch the same number of tasks of each sub-project, which one has been producing more primes per 100 000 tasks in the past few months?
____________
676754^262144+1 is prime |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Right now (well, not right now but in about 10 days), what is the most likely place to get one of these? PPSE or GFN 16? By checking the "Newly reported primes" it looks to close to call...
Edit: they are both at the opening post of this thread and I believe the answer might depend on the hardware you have. The question still stands: assuming I can crunch the same number of tasks of each sub-project, which one has been producing more primes per 100 000 tasks in the past few months?
Unless you've managed to build a computer with a powerful GPU and no CPU at all, I'd run both.
But to answer your question, PPSE right now is about 40K digits smaller than GFN16, so it should be somewhat easier to find primes with PPSE.
We do not keep the necessary data for PPSE to tell what the ratio of primes to composites is, but on Genefer 16 it's about 1 in every 16500 candidates.
____________
My lucky number is 75898524288+1 |
|
|
|
|
Unless you've managed to build a computer with a powerful GPU and no CPU at all, I'd run both.
.
I have 2 mid-tier GPU and CPU. My only megaprime popped during TdP 6 years ago. I’m planing to run 2 sub-projects, one for small primes and another one for mega, on the hope of being lucky again. What I haven’t decided is which sub-project to run on what (eg GFN16 on gpu and PPS mega or GFN 17mega/18 and PPSE).
Thanks for your answer and good luck everyone.
____________
676754^262144+1 is prime |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Unless you've managed to build a computer with a powerful GPU and no CPU at all, I'd run both.
.
I have 2 mid-tier GPU and CPU. My only megaprime popped during TdP 6 years ago. I’m planing to run 2 sub-projects, one for small primes and another one for mega, on the hope of being lucky again. What I haven’t decided is which sub-project to run on what (eg GFN16 on gpu and PPS mega or GFN 17mega/18 and PPSE).
Thanks for your answer and good luck everyone.
I just realized you may have asked the wrong question.
You asked, in essence, "what's the ratio of prime to composite candidates?
I think the better question is "How many primes were found?"
The important metric isn't "primes/tests", it's "primes/time". And that's exactly what the "prime score" is supposed to represent, i.e., how hard it is to find a prime. It's always easier to find smaller primes, all other things being equal.
But things are definitely not equal here, since GFN runs on the GPU. Assuming GFN16 runs faster on your GPU than PPSE does on your CPU, GFN16 probably gives you the best shot of finding a prime. You need to take into account not only speeds, but the number of CPU cores available when making that determinations. Whichever allows you to run the most tests over time is the one you should do in order to have the best shot at the TdP Prime badge.
I'm running running both. The chance of me finding any prime is small. The chance of a mega prime is much smaller. I'll maximize my chances of finding the smaller prime. Maybe I'll run a PSP and a GFN21 on the 19th. :)
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
                    
|
|
Mountain Stage prime badge -- awarded to everyone who finds a prime during the Mountain Stage. This is a counter badge.
That is 18 or 19.2?
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Mountain Stage prime badge -- awarded to everyone who finds a prime during the Mountain Stage. This is a counter badge.
That is 18 or 19.2?
I'm afraid I don't understand the question.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
|
Am I wrong or in last years there was specific date in February that will give special badge?
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Am I wrong or in last years there was specific date in February that will give special badge?
Yes, the Mountain Stage is February 19th (midnight to midnight), same as with TDP in previous years.
For the Mountain Stage, one person will win , and both and are available to all who earn them.
____________
My lucky number is 75898524288+1 |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
             
|
|
I never really paid attention to mountain stage as I had no hope of getting the polkadot jersey. However now that many more people can earn the special badge, details matter more. Does mountain stage count only primes returned during that period or must the task resulting in a prime have been issued as well as returned during that 24 hour period? That would be a significant detail for slower machines. |
|
|
tngSend message
Joined: 29 Aug 10
Posts: 486
ID: 66603
Credit: 47,275,377,117
RAC: 26,801,266
                                         
|
I never really paid attention to mountain stage as I had no hope of getting the polkadot jersey. However now that many more people can earn the special badge, details matter more. Does mountain stage count only primes returned during that period or must the task resulting in a prime have been issued as well as returned during that 24 hour period? That would be a significant detail for slower machines.
Primes retunred -- don't have to be issued during the mountain stage.
Don't write off your chances for the polka-dot jersey -- that jersey is largely a matter of randomness (aka "luck"). Last year I found three primes to take the mountain stage jersey, and the previous two years two primes took the mountain stage jersey. A single PPSe or GFN-16 could very well take it.
____________
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
I never really paid attention to mountain stage as I had no hope of getting the polkadot jersey. However now that many more people can earn the special badge, details matter more. Does mountain stage count only primes returned during that period or must the task resulting in a prime have been issued as well as returned during that 24 hour period? That would be a significant detail for slower machines.
As with the entire month-long TdP, the criteria for counting towards the Mountain Stage is the time the prime is reported to the server. It does not matter when the task was sent.
I'm not the least bit worried about people "hoarding" tasks to return during the Mountain Stage because A) the vast majority of tasks won't be prime, and, most importantly, B) if you hoard tasks that just means your wingman will most likely be the prime finder and you'll be the double checker. You have to be the prime finder for TdP. Double checkers get nothing.
____________
My lucky number is 75898524288+1 |
|
|
Sysadm@NbgVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 5 Feb 08
Posts: 1224
ID: 18646
Credit: 876,748,841
RAC: 318,180
            
|
I'm not the least bit worried about people "hoarding" tasks to return during the Mountain Stage because A) the vast majority of tasks won't be prime, and, most importantly, B) if you hoard tasks that just means your wingman will most likely be the prime finder and you'll be the double checker. You have to be the prime finder for TdP. Double checkers get nothing.
that brings me to an idea for a new rating: the most unfortunate double checker
shortest time between prime reporting and double check reporting
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
that brings me to an idea for a new rating: the most unfortunate double checker
shortest time between prime reporting and double check reporting
At least once I have had to check the web server logs to get millisecond-resolution timing to determine who was the prime finder. BOINC only records time in seconds, and both wingmen reported the tasks in the same second.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
|
Since only initial finder got something , then there is just, and only one option for increasing chance to be first one :) People can grab many results before start, process it and send it after challenge is started. That first wave can get some initial advantage, but challenge is for whole month. not for one day :)
My tactic will be: mega on CPU and GFN 16 on GPU. To earn at least one badge. It will be fair after all this years on Primegrid :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
People can grab many results before start, process it and send it after challenge is started.
All I can say is, if you're lucky enough to have a prime in that bunch of tasks, your wingmen will thank you. :)
There's several other flaws in this plan, but you're free to do it if you wish.
____________
My lucky number is 75898524288+1 |
|
|
|
|
My tactic will be: mega on CPU and GFN 16 on GPU. To earn at least one badge. It will be fair after all this years on Primegrid :)
I wouldn't be so optimistic about megaprimes. I crunched MEGA + GFN-17 (Mega) on December. No MEGA have been found for 22 days. No GFN-17 (Mega) found for 4 months. Now we have had 2 GFN-17 (Mega) and 1 PPS-MEGA within 12 days on January.
I 'm going to put my hope/hardware in PPSE and maybe GFN-16 since I don't want get mad. :D
I would like to solve the issue of OpenCL using 100% CPU though.
Last year I discovered 1 PPSE on February without knowing TdP. |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
My tactic will be: mega on CPU and GFN 16 on GPU. To earn at least one badge. It will be fair after all this years on Primegrid :)
I wouldn't be so optimistic about megaprimes. I crunched MEGA + GFN-17 (Mega) on December. No MEGA have been found for 22 days. No GFN-17 (Mega) found for 4 months. Now we have had 2 GFN-17 (Mega) and 1 PPS-MEGA within 12 days on January.
I 'm going to put my hope/hardware in PPSE and maybe GFN-16 since I don't want get mad. :D
I would like to solve the issue of OpenCL using 100% CPU though.
Last year I discovered 1 PPSE on February without knowing TdP.
All you say is right:but since ( I expect) in February number of crunched candidates will rise by factor 2 or 3more WU will be crunched in same time ( ordinary time)
Any since pure luck in only part that is always sure: I will relay on luck :)
Of course PPSE is "better choice" but,I do some initial test and cannot get 100% CPU on such short tasks doing it on multicore. Maybe every of my computers do different proth project is better option :)
I have 10 days to get better strategy or to confirm this one :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
|
I hate luck. She's not fair. :(
Maybe there will be more megaprimes, but I would not be still the discoverer. :)
I agree that wishing luck and crunching is better than not crunching.
I observed that PPSE (also SGS) multicore tasks are very very slow. I would crunch without multithreading. |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
I hate luck. She's not fair. :(
Maybe there will be more megaprimes, but I would not be still the discoverer. :)
I agree that wishing luck and crunching is better than not crunching.
I observed that PPSE (also SGS) multicore tasks are very very slow. I would crunch without multithreading.
They are slow and SGS is not even count of prime ( since it is too small for T5K) but slow is not problem: it is most important to be first :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
|
I know, Michael or someone repeated that many times.
I care if I waste ~50% energy though. I will do other tests. |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1957
ID: 352
Credit: 6,131,348,649
RAC: 2,246,119
                       
|
|
About luck, it can be described how difficult is to find a prime by using prime score.
PPSE - 96
GFN16 - 132
GFNMEga - 1200
PPS Mega - 1500
Finding a mega prime is 10-15x more difficult. Finding 10-15 GFN16/PPSE prime in February gives about the same chance and finding a single megaprime.
I'll push my luck AFTER I find PPSE/GFN16 prime in February and hoping I haven't been exhaused by my latest GFN16 prime.
____________
My stats |
|
|
|
|
I'll push my luck AFTER I find PPSE/GFN16 prime in February and hoping I haven't been exhaused by my latest GFN16 prime.
Same here. I will probably switch to SR5 if it happens. |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
About luck, it can be described how difficult is to find a prime by suing prime score.
PPSE - 96
GFN16 - 132
GFNMEga - 1200
PPS Mega - 1500
Finding a mega prime is 10-15x more difficult. Finding 10-15 GFN16/PPSE prime in February gives about the same chance and finding a single megaprime.
I'll push my luck AFTER I find PPSE/GFN16 prime in February and hoping I haven't been exhaused by my latest GFN16 prime.
I have 1GPU but 12 AVX/FMA3 cores :) So if we measure 1 vs 12 : for me it is same chance to find MEGA or GFN 16 :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
|
I have just realized that instead of setting CPU usage in BOINC to 50%, I can modify app config to tell BOINC that it uses more CPUs - e.g. set app to use 4 threads (-t4), and max/avg CPUs to 8. This should have the same effect as changing CPU usage to 50%, and would save me some preparation work before challenges.
____________
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
...I can modify app config to tell BOINC that it uses more CPUs - e.g. set app to use 4 threads (-t4), and max/avg CPUs to 8.
Just set <avg_ncpus>.
The "max_ncpus" tag is not used in app_config. It will be ignored if you put it in there. The computer won't care, but any human looking at that file, or anyone with whom you share the file, might get the mistaken idea that the tag does something.
____________
My lucky number is 75898524288+1 |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
|
PG message boards pretty quiet these days.
People busy tuning up their computers for optimal workload.
The calm before the TdP. |
|
|
|
|
|
I solved OpenCL 100% CPU usage issue.
I will also crunch GFN16. :) |
|
|
|
|
I solved OpenCL 100% CPU usage issue.
I will also crunch GFN16. :)
How do you fixed this? I have noticed that on my machines these tasks also uses 100% CPU.
____________
|
|
|
|
|
How do you fixed this? I have noticed that on my machines these tasks also uses 100% CPU.
https://www.primegrid.com/forum_thread.php?id=7731 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1957
ID: 352
Credit: 6,131,348,649
RAC: 2,246,119
|
|
With TdP starting in a day, I looked back at 2016 and 2017 TdP for GFN16.
During TdP 2016, GFN16 b advanced from ~6M to ~10M, a huge 4M range back then.
During TdP 2017, GFN16 b advanced from ~17M to ~22M, a 5M range.
We are 29M5, let's say ~30M.
I wouldn't be surprised if we reach b ~36M at the end of TdP 2018.
This may give us on average about 2 GFN16 primes a day.
Recent GFN16 primes are about position 2050 within T5K.
Recent PPSE primes are about position 2775 within T5K.
With SGS pushed off the T5K limit last year, PPSE primes are safe...for a considerable time. And, GFN16 primes are safe from PPSE for couple more years I guess.
____________
My stats |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
With TdP starting in a day, I looked back at 2016 and 2017 TdP for GFN16.
During TdP 2016, GFN16 b advanced from ~6M to ~10M, a huge 4M range back then.
During TdP 2017, GFN16 b advanced from ~17M to ~22M, a 5M range.
We are 29M5, let's say ~30M.
I wouldn't be surprised if we reach b ~36M at the end of TdP 2018.
This may give us on average about 2 GFN16 primes a day.
Recent GFN16 primes are about position 2050 within T5K.
Recent PPSE primes are about position 2775 within T5K.
With SGS pushed off the T5K limit last year, PPSE primes are safe...for a considerable time. And, GFN16 primes are safe from PPSE for couple more years I guess.
But if we even reach 36M as upper limit, GFN prime will not have 500K digits(it will have around 495617 digits in upper limit)
I hope that one day GFN 16 will pass 500K
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
But if we even reach 36M as upper limit, GFN prime will not have 500K digits(it will have around 495617 digits in upper limit)
I hope that one day GFN 16 will pass 500K
If I did the math right, b=42,598,524 is where we get to 500K digits. That's not all that far away.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
But if we even reach 36M as upper limit, GFN prime will not have 500K digits(it will have around 495617 digits in upper limit)
I hope that one day GFN 16 will pass 500K
If I did the math right, b=42,598,524 is where we get to 500K digits. That's not all that far away.
My calc show little lower b=42.586.410 :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
But if we even reach 36M as upper limit, GFN prime will not have 500K digits(it will have around 495617 digits in upper limit)
I hope that one day GFN 16 will pass 500K
If I did the math right, b=42,598,524 is where we get to 500K digits. That's not all that far away.
My calc show little lower b=42.586.410 :)
b > 10^(499999/65536) = 42597025.36. And I was a math teacher once ;-)
Solved b^65536 > 10^499999 by raising both sides of the inequality to the power (1/65536). That is valid since the map x ↦ x^a is strictly increasing for positive a.
(Another way of stating it: Extracting the 65536th root of both sides.)
/JeppeSN
|
|
|
dukebgVolunteer tester
Send message
Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0
               
|
|
log10(42586410^65536 + 1) ≈ 499991.9063; that means 499,992 digits
...
log10(42597025^65536 + 1) ≈ 499998.9998; that means 499,999 digits
log10(42597026^65536 + 1) ≈ 499999.0004; that means 500,000 digits
...
log10(42598522^65536 + 1) ≈ 499999.9999; that means 500,000 digits
log10(42598523^65536 + 1) ≈ 500000.0007; that means 500,001 digits
log10(42598524^65536 + 1) ≈ 500000.0013; that means 500,001 digits |
|
|
|
|
log10(42586410^65536 + 1) ≈ 499991.9063
log10(42597025^65536 + 1) ≈ 499998.9998
log10(42597026^65536 + 1) ≈ 499999.0004
log10(42598522^65536 + 1) ≈ 499999.9999
log10(42598523^65536 + 1) ≈ 500000.0007
log10(42598524^65536 + 1) ≈ 500000.0013
True, but 499999.00 is the threshold. Do not forget that 10^499999 is a figure 1 followed by 499'999 zeroes for a total of 500'000 digits.
EDIT: Ah, you already edited your message before I posted the first version of this one, so this is not really relevant anymore (because you are right now!).
/JeppeSN |
|
|
axnVolunteer developer
Send message
Joined: 29 Dec 07
Posts: 285
ID: 16874
Credit: 28,027,106
RAC: 0
       
|
But if we even reach 36M as upper limit, GFN prime will not have 500K digits(it will have around 495617 digits in upper limit)
I hope that one day GFN 16 will pass 500K
If I did the math right, b=42,598,524 is where we get to 500K digits. That's not all that far away.
The answer would be roughly the same as the starting b for GFN17-mega. However, since you did not do the math right (see dukebg/JeppeSN), does that mean GFN17-mega also omitted a few potential mega candidates? The proper starting point of GFN17-mega would be 42597774 -- was that the one used?
EDIT:- Nevermind. Got my answer. The project preferences page clearly lists the correct number. |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1957
ID: 352
Credit: 6,131,348,649
RAC: 2,246,119
|
|
So, let's have a 500k digits GFN16 prime by the end of 2018 :-)
____________
My stats |
|
|
|
|
|
How to start? |
|
|
Sysadm@NbgVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 5 Feb 08
Posts: 1224
ID: 18646
Credit: 876,748,841
RAC: 318,180
|
How to start?
see first post in this thread: klick
simple said: find a not to small prime in Feb and report 'em before your wingman
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
|
|
|
robishVolunteer moderator
Volunteer tester
Send message
Joined: 7 Jan 12
Posts: 2209
ID: 126266
Credit: 7,505,119,736
RAC: 3,500,578
          
|
|
:-P
Any chance we could have an I2018 badge?
For the "Initial" finder in each project during TDP.
Then it would be possible for someone to spell PIMP with their badges!!
:-D
Having thought about it ....no it wouldn't :-(
____________
My lucky numbers 10590941048576+1 and 224584605939537911+81292139*23#*n for n=0..26 |
|
|
|
|
|
+ 1
____________
Member of Charity Team
   |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3206
ID: 130544
Credit: 2,284,240,700
RAC: 922,232
|
|
Good job my mum isn't reading this. She hates that word. |
|
|
|
|
|
US NAVY
Y
Me too
____________
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
|
With the start of the 2018 Tour de primes only minutes away, it's time for a...
* * * PUBLIC SERVICE ANNOUNCEMENT * * *
Since TdP is all about finding primes, it's a good idea to set up your prime reporting preferences now, if you haven't already done so.
To set up your prime reporting preferences, click on Your account, located on the left side menu under "Returning Participants". Then click on PrimeGrid preferences, under "Preferences". Scroll down a little bit, and click on "Primary (default) preferences: Edit PrimeGrid preferences".
Now fill in the section under "Reporting primes to the Prime Pages". Click both check boxes, and enter your REAL first and last names. They're required. Entering Daffy Duck or John Q. Public will only delay getting your primes reported. Finally, scroll all the way to the bottom of the page and click the "Update preferences" button.
Alternatively, if you wish to remain anonymous, you can write "report anonymously" in the name field, or "give to DCer" and we'll report the prime in the name of the double checker.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
|
* * * PUBLIC SERVICE ANNOUNCEMENT #2 * * *
Remember, SGS, GFN-15, AP27, GCW-Sieve and PPS-Sieve are not eligible for Tour de Primes.
____________
My lucky number is 75898524288+1 |
|
|
RogerVolunteer developer
Volunteer tester
Send message
Joined: 27 Nov 11
Posts: 1138
ID: 120786
Credit: 268,668,824
RAC: 0
      
|
|
Congratulations to Rick Reynolds for the first Prime, 29723118^65536+1 discovered 1st of February 2018 04:20:46 UTC.
http://www.primegrid.com/challenge/tdp_2018.php
Link to last years list:
http://www.primegrid.com/challenge/tdp_2017.php |
|
|
Ken_g6Volunteer developer
Send message
Joined: 4 Jul 06
Posts: 940
ID: 3110
Credit: 261,912,073
RAC: 16,532
      
|
|
I decided to change my avatar for at least the duration of the Tour de Primes. :)
____________
|
|
|
|
|
|
Ken_g6 wrote: I decided to change my avatar for at least the duration of the Tour de Primes. :)
LOL
|
|
|
|
|
|
What are hidden primes, mentioned in the results page ? |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
What are hidden primes, mentioned in the results page ?
There's a variety of steps that need to be taken before we can display a prime to the public. For small primes, this usually takes less than a day. For large primes, it can take a week or more.
It also depends on whether the person who discovered the prime has set their prime reporting preferences. If they haven't done so, or have not granted us permission to report for them, we have to wait for them. This can delay reporting the prime by more than a month in the worst case scenario.
While a prime prime discovered during February counts as of the time of its discovery, we may not be able to display the prime until later. That's what I mean by "hidden prime".
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I see.
And I assume all these steps are taken only after a wingman has double checked the result.
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
I see.
And I assume all these steps are taken only after a wingman has double checked the result.
You know what they say about "assume". :)
As long as we don't have reason to suspect a false prime, i.e., that an error caused the computer to incorrectly say the candidate is prime, we'll start some of those steps as soon as we see the first prime result.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Michael Goetz wrote: ... As long as we don't have reason to suspect a false prime, i.e., that an error caused the computer to incorrectly say the candidate is prime, we'll start some of those steps as soon as we see the first prime result.
Thanks for the clarification.
Michael Goetz wrote: Eudy wrote: I see.
And I assume all these steps are taken only after a wingman has double checked the result.
You know what they say about "assume". :)
I had to Google for this one, had no idea.
I suppose / imagine / believe / think you're referring to this.
LOL
It's never too late to learn something new ! |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
I had to Google for this one, had no idea.
I suppose / imagine / believe / think you're referring to this.
LOL
It's never too late to learn something new !
You never heard that one? It's a great way to teach people never to assume anything, and to verify everything. Stops you from making a lot of mistakes.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Anyone seeing issues with GEN 16-17 MEGA not getting Tasks ATM?
Looking like only One of my Rigs are not getting any PG GPU Task.
Other BOINC GPU Tasks run fine. Going to remove and add PG see if that fixes is.
Thanks for the Reply ^^
Odd that I can get CPU Tasks but not GPU ATM.
http://www.primegrid.com/show_host_detail.php?hostid=920343
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
Anyone seeing issues with GEN 16-17 MEGA not getting Tasks ATM?
No, GFN 16 is issuing fine for me.
So far I've lost 59.4% of result races in the challenge. Time to fine-tune my workload. |
|
|
|
|
Anyone seeing issues with GEN 16-17 MEGA not getting Tasks ATM?
Looking like only One of my Rigs are not getting any PG GPU Task.
Other BOINC GPU Tasks run fine. Going to remove and add PG see if that fixes is.
Thanks for the Reply ^^
Odd that I can get CPU Tasks but not GPU ATM.
http://www.primegrid.com/show_host_detail.php?hostid=920343
Could be this (This was my issue) Running fine now.
<no_alt_platform>1</no_alt_platform>
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Anyone seeing issues with GEN 16-17 MEGA not getting Tasks ATM?
Looking like only One of my Rigs are not getting any PG GPU Task.
Other BOINC GPU Tasks run fine. Going to remove and add PG see if that fixes is.
Thanks for the Reply ^^
Odd that I can get CPU Tasks but not GPU ATM.
http://www.primegrid.com/show_host_detail.php?hostid=920343
Could be this (This was my issue) Running fine now.
<no_alt_platform>1</no_alt_platform>
To be clear to anyone else reading this, you do NOT want this tag. It's presence was causing the problem. Don't add this to your setup!
____________
My lucky number is 75898524288+1 |
|
|
Ken_g6Volunteer developer
Send message
Joined: 4 Jul 06
Posts: 940
ID: 3110
Credit: 261,912,073
RAC: 16,532
|
So far I've lost 59.4% of result races in the challenge. Time to fine-tune my workload.
How did you figure that out so precisely?
I've got some tricks that have me winning a large majority of my races. (Except probably the GFN ones.)
____________
|
|
|
|
|
|
Ken_g6 wrote: ... How did you figure that out so precisely? ...
Good question.
I'd also like to know.
Ken_g6 wrote: I've got some tricks that have me winning a large majority of my races. (Except probably the GFN ones.)
Mind to share ?
The only thing I do is set cache to zero days
|
|
|
|
|
|
Ouch - I missed (my first) mega prime!
Just read in the Genefer prime thread I DCed a GFN17 Mega (48643706^131072 + 1) by two minutes on GTX1080.
Being the double checker stings when evenly matched.
BOINC downloads WU a couple minutes before starting WU immediately with 0 cache when running 5 GPUs.
Good job primary finder (a GTX1080) edging me to the punch .
http://www.primegrid.com/workunit.php?wuid=554039611 |
|
|
|
|
|
It´s like a lottery |
|
|
Ken_g6Volunteer developer
Send message
Joined: 4 Jul 06
Posts: 940
ID: 3110
Credit: 261,912,073
RAC: 16,532
|
Ken_g6 wrote: I've got some tricks that have me winning a large majority of my races. (Except probably the GFN ones.)
Mind to share ?
Yes. :) Somebody's gotta be
<-- that guy. Better you than me! ;)
____________
|
|
|
|
|
How did you figure that out so precisely?
For example you can parse hostid results by a programming language. Not fine for the server because you should open one new page per workunit, but that's it.
It would be better parsing xml files than html pages, it the server supplies them.
|
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
How did you figure that out so precisely?
For example you can parse hostid results by a programming language. Not fine for the server because you should open one new page per workunit, but that's it.
It would be better parsing xml files than html pages, it the server supplies them.
If you want to use a screen scraper to gather data, that's fine, as long as it's single threaded. I.e., don't start scaping a second page until you're finished with the first page.
____________
My lucky number is 75898524288+1 |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
So far I've lost 59.4% of result races in the challenge. Time to fine-tune my workload.
How did you figure that out so precisely?
I've got some tricks that have me winning a large majority of my races. (Except probably the GFN ones.)
#!/usr/bin/perl -w
use strict;
use LWP::Simple qw( $ua get );
$ua->timeout(15);
$ua->agent('composite');
... and 103 lines more
|
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
How did you figure that out so precisely?
For example you can parse hostid results by a programming language. Not fine for the server because you should open one new page per workunit, but that's it.
It would be better parsing xml files than html pages, it the server supplies them.
If you want to use a screen scraper to gather data, that's fine, as long as it's single threaded. I.e., don't start scaping a second page until you're finished with the first page.
It is sufficient to parse the workunit pages. They have the timing data for all the results for each workunit and even say with the "canonical result" which one is the winner. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
It´s like a lottery
It's closer to having loaded dice, in favor of the faster processors and more knowledgeable participants. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
Ken_g6 wrote: I've got some tricks that have me winning a large majority of my races. (Except probably the GFN ones.)
Mind to share ?
Yes. :) Somebody's gotta be
<-- that guy. Better you than me! ;)
Ken_g6 is has won 79.2% of TdP races he has participated in, so far. Man, that took a long time to load 1661 validated results (1517 of them from the challenge; 1202 winners). I should add an optional starting date to limit the work for measuring challenge data. |
|
|
|
|
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
You virtually had that one in the bag.
Your task took 63 seconds less time to run than Scott and you received the task more than 6 minutes before he did. |
|
|
|
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
You virtually had that one in the bag.
Your task took 63 seconds less time to run than Scott and you received the task more than 6 minutes before he did.
Maybe but it is Scott and I dear say nothing
For some reason mine was not reported in time, that is how it is.
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
You virtually had that one in the bag.
Your task took 63 seconds less time to run than Scott and you received the task more than 6 minutes before he did.
Maybe but it is Scott and I dear say nothing
For some reason mine was not reported in time, that is how it is.
I don't know, does <report_results_immediately/> as the second-last line in app_config.xml have any effect?
EDIT: It's a new tag as of BOINC client version 7.8
BOINC Client Configuration
EDIT EDIT: Oops, is that supposed to be a high performance secret? |
|
|
|
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
You virtually had that one in the bag.
Your task took 63 seconds less time to run than Scott and you received the task more than 6 minutes before he did.
Maybe but it is Scott and I dear say nothing
For some reason mine was not reported in time, that is how it is.
I don't know, does <report_results_immediately/> as the second-last line in app_config.xml have any effect?
EDIT: It's a new tag as of BOINC client version 7.8
BOINC Client Configuration
EDIT EDIT: Oops, is that supposed to be a high performance secret?
cc_config.xml
<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
If this is True then this is all a lie Or Cheat
EDIT: Oops, is that supposed to be a high performance secret?
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
At lest I got to be a Doublechecker for Scott Brown today.
http://www.primegrid.com/workunit.php?wuid=554094321
You virtually had that one in the bag.
Your task took 63 seconds less time to run than Scott and you received the task more than 6 minutes before he did.
Maybe but it is Scott and I dear say nothing
For some reason mine was not reported in time, that is how it is.
I don't know, does <report_results_immediately/> as the second-last line in app_config.xml have any effect?
EDIT: It's a new tag as of BOINC client version 7.8
BOINC Client Configuration
EDIT EDIT: Oops, is that supposed to be a high performance secret?
cc_config.xml
<cc_config>
<options>
<report_results_immediately>1</report_results_immediately>
</options>
</cc_config>
If this is True then this is all a lie Or Cheat
EDIT: Oops, is that supposed to be a high performance secret?
Both are valid. app_config.xml is easier to configure.
How about this one:
#!/bin/bash
set -o pipefail
set -e
function get_more_work {
boinccmd --project www.primegrid.com allowmorework
echo get more work
}
function no_more_work {
boinccmd --project www.primegrid.com nomorework
echo no more work
}
t=$(mktemp -d -t BOINC-XXXXXX)
trap "rm -rf $t && get_more_work" EXIT
deadline=1
while true; do
echo sleeping $deadline
sleep $deadline
boinccmd --get_state | grep remaining | cut -d : -f 2 | sed '/0.0/d' | sort -n >$t/times
if [[ 0 == $(wc -l $t/times) ]]; then
echo no work remaining
exit 0
fi
deadline=$(head -n 1 $t/times)
deadline=$(dc -e "$deadline 2 / p")
if (( $deadline < 10 )); then
get_more_work
sleep 10
else
no_more_work
fi
done
Doesn't quite work correctly. Fixable. |
|
|
|
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer.
Consider this strategy: Every time you notice that the other person has already handed in some well-formed result (now pending validation by you), you just abort that job and pick a new one.
That would be destructive to the community. Seen from a global perspective, a lot of computation would be wasted. And if too many people used that strategy, we would never have enough validations, so we would end up with an ever increasing number of work units (tasks) that would be in limbo and waiting for their second result indefinitely.
/JeppeSN
|
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer.
Consider this strategy: Every time you notice that the other person has already handed in some well-formed result (now pending validation by you), you just abort that job and pick a new one.
That would be destructive to the community. Seen from a global perspective, a lot of computation would be wasted. And if too many people used that strategy, we would never have enough validations, so we would end up with an ever increasing number of work units (tasks) that would be in limbo and waiting for their second result indefinitely.
/JeppeSN
Similar to the tragedy of the commons. Resource shortage is validations.
EDIT: If this becomes a problem, the solution is for the server to hide the status of all other tasks of a workunit from a participant who has a task in progress.
This policy should be applied universally, stop the problem from ever occuring. Hide all other tasks of a workunit from a participant who has a task in progress for the workunit. However this could be circumvented by a confederation of participants advising on each others' tasks. So I'm not sure what to do about it. |
|
|
dukebgVolunteer tester
Send message
Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0
|
|
That's way too tedious, though. The beauty of boinc is being fully transparently automated for people, so they don't have to bother with anything. Don't expect 80% of people to have any custom settings at all. Doing something this actively, with this much involvement – I doubt even 1% would go for it.
As an example: there are 344045 crunchers according to the front page (although maybe that is all ever registered, not active users, I don't know). Manual Sieving has only 154 unique people that have done it. Just 0.04% of all users. |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer.
Consider this strategy: Every time you notice that the other person has already handed in some well-formed result (now pending validation by you), you just abort that job and pick a new one.
That would be destructive to the community. Seen from a global perspective, a lot of computation would be wasted. And if too many people used that strategy, we would never have enough validations, so we would end up with an ever increasing number of work units (tasks) that would be in limbo and waiting for their second result indefinitely.
/JeppeSN
I really doubt that strategy will be destructive for community. More like, community will not noticed that strategy at all.
Why, answer is given below: only 0.0x% of all users will do that.
In the past ( and I can assume right now) there is few hosts that produce 1 second error and those host in combination with big cache can do many invalid WU per day. Did that behavior do anything (wrong or bad) to Primegrid. Is not in past and will not in future.
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer.
Consider this strategy: Every time you notice that the other person has already handed in some well-formed result (now pending validation by you), you just abort that job and pick a new one.
That would be destructive to the community. Seen from a global perspective, a lot of computation would be wasted. And if too many people used that strategy, we would never have enough validations, so we would end up with an ever increasing number of work units (tasks) that would be in limbo and waiting for their second result indefinitely.
/JeppeSN
I really doubt that strategy will be destructive for community. More like, community will not noticed that strategy at all.
Why, answer is given below: only 0.0x% of all users will do that.
In the past ( and I can assume right now) there is few hosts that produce 1 second error and those host in combination with big cache can do many invalid WU per day. Did that behavior do anything (wrong or bad) to Primegrid. Is not in past and will not in future.
That's a reasonable argument under ordinary (past) conditions. However, when there's a bot available to do all the work of aborting units, the proportion of people using it could rise significantly because of the badge incentive.
|
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
There's also a strategy of aborting sure losers to gain an edge, ie. less effort spent on tasks that will not win means more time spent on tasks that may win. But it requires you to sit there and monitor each work unit in progress. It could be done effectively with software. I don't think many people are doing that.
The chances of finding a prime are unchanged, merely the chance of being the discoverer.
Consider this strategy: Every time you notice that the other person has already handed in some well-formed result (now pending validation by you), you just abort that job and pick a new one.
That would be destructive to the community. Seen from a global perspective, a lot of computation would be wasted. And if too many people used that strategy, we would never have enough validations, so we would end up with an ever increasing number of work units (tasks) that would be in limbo and waiting for their second result indefinitely.
/JeppeSN
I really doubt that strategy will be destructive for community. More like, community will not noticed that strategy at all.
Why, answer is given below: only 0.0x% of all users will do that.
In the past ( and I can assume right now) there is few hosts that produce 1 second error and those host in combination with big cache can do many invalid WU per day. Did that behavior do anything (wrong or bad) to Primegrid. Is not in past and will not in future.
That's a reasonable argument under ordinary (past) conditions. However, when there's a bot available to do all the work of aborting units, the proportion of people using it could rise significantly because of the badge incentive.
Bot can do this: but: someone need to write bot for that, install it.Future is coming, and soon or later it will become reality. But even in that case, you cannot do nothing: and again how many in % users of Primegrid will do that?
Targeted area of those users is obviously prime finding. So those users know something about math. In that case, when all program needed for sieving and processing are available free, who will do such extra work for nothing?
Those users like me ( I am prime hunting users, not badge/score hunting user) will make own sieve , make own range and process it at home. In that case Primegid is last place to be visited.
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
I don't know, does <report_results_immediately/> as the second-last line in app_config.xml have any effect?
EDIT: It's a new tag as of BOINC client version 7.8
What?
I use that on v7.2.42 and it works. You have to set 1 as value.
Not good at all if your client has delayed the next update. A script forcing the update when a task is completed would be better. |
|
|
|
|
Similar to the tragedy of the commons. Resource shortage is validations.
Yes.
There are various degrees of "selfishness" that comes from wanting to optimize the chance of being the discoverer (as opposed to wingman) instead of optimizing the credit.
Choosing multi-threading in a case that lowers the overall throughput, is a milder example.
(Concrete example: If you can choose between running four tasks simultaneously, each task on its own processor core, and running one task at a time (multi-threading so all cores participate in this single task). And if for the sake of this example, we assume that in the first setup, you can finish the four tasks in half an hour, while in the multi-threading setup, the one tasks finishes in ten minutes. Then if you choose the first configuration, you contribute a total of 8 tasks per hour. But it takes 30 minutes for each task, so you will often be a wingman. If you choose the other configuration, where each task is returned after ten minutes, you will more often be the discoverer, but here you decide to contribute only 6 tasks per hour. This is why choosing the second option may be considered somewhat selfish, in some people's opinion.)
"Rewards" that encourage optimizing the overall throughput: The credit system (wingman gets same credit) and all badges that depend on credit score.
"Rewards" that may encourage "selfish" behavior: Associating more "fame" to the discoverer than to the double checker (Top 5000 proof-codes), badges that are awarded (for particular prime finds) to the discoverer but not to the wingman, and challenges in the style of Tour de Primes.
/JeppeSN
|
|
|
|
|
That would be destructive to the community.
/JeppeSN
It would be a tragedy if all the users did it so. It's not our case. There are a lot of random doublecheckers.
Besides it would be destructive to everyone not to be doublechecker for conjectures primes. We would lose a lot of points. I think that strategy would be useful for slower hosts. My host completes almost 500 tests everyday (I have to calculate first reporter ratio). I don't care if a dozen of them had already completed when they were sent to my host.
I agree about multithreading selfishness on small FFT sizes, but we don't pay for their electric energy. They could object that there are people running tests on inefficient/old computers or that our energy produced by coal is worse. They would be right too.
We could call it "freedom of wasting". |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
Similar to the tragedy of the commons. Resource shortage is validations.
Yes.
There are various degrees of "selfishness" that comes from wanting to optimize the chance of being the discoverer (as opposed to wingman) instead of optimizing the credit.
Choosing multi-threading in a case that lowers the overall throughput, is a milder example.
(Concrete example: If you can choose between running four tasks simultaneously, each task on its own processor core, and running one task at a time (multi-threading so all cores participate in this single task). And if for the sake of this example, we assume that in the first setup, you can finish the four tasks in half an hour, while in the multi-threading setup, the one tasks finishes in ten minutes. Then if you choose the first configuration, you contribute a total of 8 tasks per hour. But it takes 30 minutes for each task, so you will often be a wingman. If you choose the other configuration, where each task is returned after ten minutes, you will more often be the discoverer, but here you decide to contribute only 6 tasks per hour. This is why choosing the second option may be considered somewhat selfish, in some people's opinion.)
"Rewards" that encourage optimizing the overall throughput: The credit system (wingman gets same credit) and all badges that depend on credit score.
"Rewards" that may encourage "selfish" behavior: Associating more "fame" to the discoverer than to the double checker (Top 5000 proof-codes), badges that are awarded (for particular prime finds) to the discoverer but not to the wingman, and challenges in the style of Tour de Primes.
/JeppeSN
You use word "selfish": but I dont like that word. Why? If all users ( and that will never be) have same hardware then it will be truly selfish.
But many here has old CPU, and slow GPU-S, and yes, like many times before those host can and are faster then "faster" host but those cases are in extremely low number.
So those users with old CPU and GPU have very low chance to be initial finder.
Everyone of us here need and it is natural to got fame of initial discoverer. And that is nothing wrong with that. So multi-threaded option is not selfish.
I didnot know any of initial discoverer that look at host of wingman, and if conclude that host is old and slow transfer to him "fame" of initial discoverer. Are you?
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
I don't know, does <report_results_immediately/> as the second-last line in app_config.xml have any effect?
EDIT: It's a new tag as of BOINC client version 7.8
What?
I use that on v7.2.42 and it works. You have to set 1 as value.
Not good at all if your client has delayed the next update. A script forcing the update when a task is completed would be better.
v7.8 introduces that tag into app_config.xml, it already existed in cc_config.xml much earlier. Are you sure you are talking about app_config.xml?
The script is trying to solve the issue of the client downloading the next task too early, so that tasks have a better chance of winning a race. There's probably another way to do that. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
Similar to the tragedy of the commons. Resource shortage is validations.
Yes.
There are various degrees of "selfishness" that comes from wanting to optimize the chance of being the discoverer (as opposed to wingman) instead of optimizing the credit.
Choosing multi-threading in a case that lowers the overall throughput, is a milder example.
(Concrete example: If you can choose between running four tasks simultaneously, each task on its own processor core, and running one task at a time (multi-threading so all cores participate in this single task). And if for the sake of this example, we assume that in the first setup, you can finish the four tasks in half an hour, while in the multi-threading setup, the one tasks finishes in ten minutes. Then if you choose the first configuration, you contribute a total of 8 tasks per hour. But it takes 30 minutes for each task, so you will often be a wingman. If you choose the other configuration, where each task is returned after ten minutes, you will more often be the discoverer, but here you decide to contribute only 6 tasks per hour. This is why choosing the second option may be considered somewhat selfish, in some people's opinion.)
"Rewards" that encourage optimizing the overall throughput: The credit system (wingman gets same credit) and all badges that depend on credit score.
"Rewards" that may encourage "selfish" behavior: Associating more "fame" to the discoverer than to the double checker (Top 5000 proof-codes), badges that are awarded (for particular prime finds) to the discoverer but not to the wingman, and challenges in the style of Tour de Primes.
/JeppeSN
Agreed, except that some computers with large cache have a superscalar effect, so that multithreading actually increases the throughput for large tasks like SoB by reducing the RAM bandwidth requirement. I have one such machine. |
|
|
|
|
v7.8 introduces that tag into app_config.xml, it already existed in cc_config.xml much earlier. Are you sure you are talking about app_config.xml?
The script is trying to solve the issue of the client downloading the next task too early, so that tasks have a better chance of winning a race. There's probably another way to do that.
Sorry, I did not notice app_ instad of cc_. You are right.
Of course. That's the most important issue to me.
Just saying that reporting immediately doesn't work when your client has stated for some reason (e.g. no internet connection for a while) to wait for X minutes before communicating with project server again. |
|
|
|
|
except that some computers with large cache have a superscalar effect, so that multithreading actually increases the throughput for large tasks like SoB by reducing the RAM bandwidth requirement. I have one such machine.
Absolutely; I was not referring to that situation. In that case, choosing multithreading clearly optimizes the total throughput, the amount of "utility" you contribute to the "community".
/JeppeSN |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
The script is trying to solve the issue of the client downloading the next task too early, so that tasks have a better chance of winning a race. There's probably another way to do that.
Of course. That's the most important issue to me.
Just saying that reporting immediately doesn't work when your client has stated for some reason (e.g. no internet connection for a while) to wait for X minutes before communicating with project server again.
I think you are talking about deplayed reporting. That's a different issue than I am trying to solve. With constant internet connection, the BOINC client may download a new task minutes before it starts to execute. That's enough delay on short tasks like GFN16 and PPSE to lose a first-reporter race against similar speed machines. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
That's way too tedious, though. The beauty of boinc is being fully transparently automated for people, so they don't have to bother with anything. Don't expect 80% of people to have any custom settings at all. Doing something this actively, with this much involvement – I doubt even 1% would go for it.
As an example: there are 344045 crunchers according to the front page (although maybe that is all ever registered, not active users, I don't know). Manual Sieving has only 154 unique people that have done it. Just 0.04% of all users.
I love the fine print LOL. I guess you were trying to make a footnote, but it comes across on my system like the tiny tiny swindle notes you see at the bottom of a contract. |
|
|
|
|
The script is trying to solve the issue of the client downloading the next task too early, so that tasks have a better chance of winning a race. There's probably another way to do that.
Of course. That's the most important issue to me.
Just saying that reporting immediately doesn't work when your client has stated for some reason (e.g. no internet connection for a while) to wait for X minutes before communicating with project server again.
I think you are talking about deplayed reporting. That's a different issue than I am trying to solve. With constant internet connection, the BOINC client may download a new task minutes before it starts to execute. That's enough delay on short tasks like GFN16 and PPSE to lose a first-reporter race against similar speed machines.
I know. My hosts are not affected by that. ;) |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
My host completes almost 500 tests everyday (I have to calculate first reporter ratio). I don't care if a dozen of them had already completed when they were sent to my host.
I could calculate that for you in several minutes if you unhide your computers. Or maybe you have that capability already.
|
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
Just saying that reporting immediately doesn't work when your client has stated for some reason (e.g. no internet connection for a while) to wait for X minutes before communicating with project server again.
The fix for that is a daemon that listens for network connection events and causes the BOINC client to update if there are any tasks in completed state waiting to be returned. I would have to do some research to figure out the first part. I think udev events on Linux can do that, but I would have to play around with those. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1149
ID: 55391
Credit: 1,093,130,952
RAC: 700,004
|
the BOINC client may download a new task minutes before it starts to execute
I know. My hosts are not affected by that. ;)
How in the world did you manage to do that?
One option I have been playing with is telling BOINC that it has only 2 CPUs (via % CPU option) and setting app_config.xml so that each app requires 1 CPU (even the GPU app); the "-t" command line option is unchanged. All this solved was the initial download of many multithreaded tasks on startup. But then BOINC estimates that multithreaded CPU tasks will take many multiples longer to run than they actually do ( like 1 hour 20 minutes instead of 5 minutes 30 seconds). |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
the BOINC client may download a new task minutes before it starts to execute
I know. My hosts are not affected by that. ;)
How in the world did you manage to do that?
One option I have been playing with is telling BOINC that it has only 2 CPUs (via % CPU option) and setting app_config.xml so that each app requires 1 CPU (even the GPU app); the "-t" command line option is unchanged. All this solved was the initial download of many multithreaded tasks on startup. But then BOINC estimates that multithreaded CPU tasks will take many multiples longer to run than they actually do ( like 1 hour 20 minutes instead of 5 minutes 30 seconds).
Before version 7 , even in version 6: that "bug" appear: before BOinc download work only few seconds before old is finished. I try, I ask, but all answers goes to BOINC developer. And of course I never got answer why BOINC must download even two minutes before task will be finished.
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
With constant internet connection, the BOINC client may download a new task minutes before it starts to execute. That's enough delay on short tasks like GFN16 and PPSE to lose a first-reporter race against similar speed machines.
I know. My hosts are not affected by that. ;)
Do you mind to share how you do it? Even with additional cache set to 0, Boinc will download a new GFN 16 several minutes before the previous one is completed.
____________
676754^262144+1 is prime |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
|
Some of you have been around long enough to remember when a change was made in BOINC that permits me to set <report_results_immediately> FROM THE SERVER SIDE.
It's always turned on for PrimeGrid tasks no matter what you do. You shouldn't be able to turn it off. I won't swear it's impossible to turn off because I've never tried, but certainly, if you do nothing, it's ALWAYS ON. You don't need to put it in cc_config. You don't need to put it in app_info. You don't need to put it in app_config.
____________
My lucky number is 75898524288+1 |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
Some of you have been around long enough to remember when a change was made in BOINC that permits me to set <report_results_immediately> FROM THE SERVER SIDE.
It's always turned on for PrimeGrid tasks no matter what you do. You shouldn't be able to turn it off. I won't swear it's impossible to turn off because I've never tried, but certainly, if you do nothing, it's ALWAYS ON. You don't need to put it in cc_config. You don't need to put it in app_info. You don't need to put it in app_config.
Mike I agree with you, but even set is off or on nothing is changes: that is not problem. Problem is download task before old is finished. On other project minute or two is not "problem" here is "big problem" :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
Some of you have been around long enough to remember when a change was made in BOINC that permits me to set <report_results_immediately> FROM THE SERVER SIDE.
It's always turned on for PrimeGrid tasks no matter what you do. You shouldn't be able to turn it off. I won't swear it's impossible to turn off because I've never tried, but certainly, if you do nothing, it's ALWAYS ON. You don't need to put it in cc_config. You don't need to put it in app_info. You don't need to put it in app_config.
Mike I agree with you, but even set is off or on nothing is changes: that is not problem. Problem is download task before old is finished. On other project minute or two is not "problem" here is "big problem" :)
One of my GPUs takes 3 minutes and 10 seconds to crunch a GFN 16. Boinc will download a new task around 1 minute after the previous one has started crunching, so a bit over 2 minutes before it was needed. This increases the time between download and upload to well over 5 minutes. Crawling trough some of my tasks I've seen a few wingman who don't seem to have this issue.
____________
676754^262144+1 is prime |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
One of my GPUs takes 3 minutes and 10 seconds to crunch a GFN 16. Boinc will download a new task around 1 minute after the previous one has started crunching, so a bit over 2 minutes before it was needed. This increases the time between download and upload to well over 5 minutes. Crawling trough some of my tasks I've seen a few wingman who don't seem to have this issue.
Someone on the Discord server dug through the BOINC client code and found that 3:00 minutes is hard coded into the software. It affects everyone, unless you do one of two things:
* Recompile the BOINC client yourself to remove that code.
* Set up PrimeGrid as a backup project, i.e., 0 share. BOINC won't download a new task until the previous task finishes. This means down time between tasks when the GPU will be idle until the next task is downloaded and ready to run, so your throughput will go down and you'll be running fewer tests overall.
The number of people doing either of those is going to be small, so while that delay might be undesirable, it affects everyone, so everyone is on a level playing field.
Since most people don't optimize the last second out of their systems, the hardest part is finding the prime. I've got five computer running, and I'll be lucky to find even one prime before the month ends. I'm more worried about that than I am about being the finder vs. the DC.
____________
My lucky number is 75898524288+1 |
|
|
HonzaVolunteer moderator
Volunteer tester
Project scientist
Send message
Joined: 15 Aug 05
Posts: 1957
ID: 352
Credit: 6,131,348,649
RAC: 2,246,119
|
The number of people doing either of those is going to be small, so while that delay might be undesirable, it affects everyone, so everyone is on a level playing field.
Since most people don't optimize the last second out of their systems, the hardest part is finding the prime. I've got five computer running, and I'll be lucky to find even one prime before the month ends. I'm more worried about that than I am about being the finder vs. the DC.
The hardest part is finding the prime.
While preparing for TdP, I got one PPSE on 2018-01-29 and one GFN16 on 2018-01-31, couple hours early you may say.
Considering this situation, my worry was if I hadn't run out of luck and not to come dry during TdP - be it prime finder or wingman.
But I understand that finally finding a huge prime and being doublechecker may feel kind of missed opportunity.
EDIT: On a side note - I was always ready to be doublechecker of very old WUs and challenge cleanup with some of my slower computers (like 4-years old server) - IF there was a chance to provide those cleanup boxes that would always get oldest tasks.
____________
My stats |
|
|
Scott BrownVolunteer moderator
Project administrator
Volunteer tester
Project scientist
Send message
Joined: 17 Oct 05
Posts: 2392
ID: 1178
Credit: 18,631,505,153
RAC: 7,088,033
|
|
I hope no one thinks I am doing anything unusual to game the system. I have been playing with some different multi-thread options to see how it affects numerous systems, but that is about it.
And if you take a look at that Top Prime Finders link on the left of your screen, guess who is the top ranked DC'er (with more than double 2nd place!)? :)
|
|
|
dukebgVolunteer tester
Send message
Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0
|
Someone on the Discord server dug through the BOINC client code and found that 3:00 minutes is hard coded into the software.
Second time I've been refered on forums just as "someone on the Discord", hmm
Here's the full message, for history:
every now and then (every WORK_FETCH_PERIOD=60 seconds + "piggybacking" on result reporting and manual "update project" by user) BOINC is looking if the work buffer is saturated according to the preferences (WORK_FETCH class in the code). That is, wether there is enough work for the next work_buf_min() + work_buf_additional(), in seconds.
Here is how those functions look
inline double work_buf_min() {
double x = global_prefs.work_buf_min_days * 86400;
if (x < 180) x = 180;
return x;
}
inline double work_buf_additional() {
return global_prefs.work_buf_additional_days *86400;
}
As you can see in the first function, BOINC does not "respect" work buffers smaller than 180 sec = 3 minutes. Thus, when the estimated remaining time in a task goes below 3 minutes, it will think that there is spare place to fill in the work buffer and will fetch the next task from whatever project it deems necessary (there are internal measures of how much was "done" for a project and what its share is). It also has the clause that Michael discribed (from compute_rsc_project_reason()):
// if project has zero resource share,
// only fetch work if a device is idle
//
if (p->resource_share == 0 && rwf.nidle_now == 0) {
return DONT_FETCH_ZERO_SHARE;
}
This clause exempts the zero_share project from filling the 3-minute work buffer (and downloading next task 2-3 minutes early), but also prevents filling the work buffer specified in preferences with tasks of that project. It gets a task to run when idle, but once it got it – it's no longer idle and won't fill the buffer with next ones.
The reasoning behind 180 seconds of min buffer is quite valid for general projects, IMHO. Tasks can take some time to download, doing it few minutes in advance is good thinking on the developer's side. Since boinc is open source you can always change the constant to a smaller one and build your own "faster" version, if you're familiar with how that is done and deem that necessary. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
Someone on the Discord server dug through the BOINC client code and found that 3:00 minutes is hard coded into the software.
Second time I've been refered on forums just as "someone on the Discord", hmm
Official promotion:
By royal proclamation, ye art awarded, and shall from this point forward, in all means and communications, be officially referred to as:
"Someone on the forums"
Seriously, though, thanks for digging that up. I had always thought it was a 2 minute lead time, based on mk1 eyeball observations. I appreciate the research.
Point of note: Anything I say or do in the morning before the first cup of coffee should be considered unreliable and the product of a diseased mind.
____________
My lucky number is 75898524288+1 |
|
|
dukebgVolunteer tester
Send message
Joined: 21 Nov 17
Posts: 242
ID: 950482
Credit: 23,670,125
RAC: 0
|
Seriously, though, thanks for digging that up. I had always thought it was a 2 minute lead time, based on mk1 eyeball observations. I appreciate the research.
No problem, I was bored at work at the time!
I've initially eyeballed it to be 2 minutes myself too and searched the code for constants like 120 :]
Since it only runs the check every 60 seconds (unless intervention of user or reporting result), the lead time is going to be random from 2 to 3 minutes. That means, if we suppose that we randomly open the BOINC window and saw the new task already downloaded and grunted under our breath, the most likely remaining time on the previous task would be 1 to 1.5 minutes. Including standard deviation, that's 0.5 to 2 minutes. So most likely we would convince ourselves that the value is 2 minutes.
Also, just wanted to note composite's message above. If boinc is fooled to believe that the estimated remaining times are larger (we're looking: larger than 3 minutes), it won't do the early download too (it's sense of work buffer becoming empty only coming in on the result reporting). |
|
|
Crun-chiVolunteer tester
Send message
Joined: 25 Nov 09
Posts: 3233
ID: 50683
Credit: 151,443,349
RAC: 125,986
|
The number of people doing either of those is going to be small, so while that delay might be undesirable, it affects everyone, so everyone is on a level playing field.
It affects everyone, but we dont crunch at same time same WU on same hardware :)
But as you wrote solution is here: so lets play :)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! |
|
|
|
|
|
dukebg wrote: Also, just wanted to note composite's message above. If boinc is fooled to believe that the estimated remaining times are larger (we're looking: larger than 3 minutes), it won't do the early download too (it's sense of work buffer becoming empty only coming in on the result reporting).
I don't understand why my host always downloads 2 GFN-16 tasks when the work buffer is empty, although the estimated time is 6:38 (398s). Project server should send only 1 task.
composite wrote: I could calculate that for you in several minutes if you unhide your computers. Or maybe you have that capability already.
Yes, I can. Maybe later.
composite wrote: How in the world did you manage to do that?
One option I have been playing with is telling BOINC that it has only 2 CPUs (via % CPU option) and setting app_config.xml so that each app requires 1 CPU (even the GPU app); the "-t" command line option is unchanged. All this solved was the initial download of many multithreaded tasks on startup. But then BOINC estimates that multithreaded CPU tasks will take many multiples longer to run than they actually do ( like 1 hour 20 minutes instead of 5 minutes 30 seconds).
Something similar.
"Usucapio Libertatis" wrote: Do you mind to share how you do it? Even with additional cache set to 0, Boinc will download a new GFN 16 several minutes before the previous one is completed.
No. :)
My script doesn't work with GFN-16 at all. My host gets 2 new tasks every time. From my perspective I don't know if it's better to receive 2 tasks and immediately start the first one or to receive 1 task and start every task after 1 minute. My GPU is a 750 Ti and takes almost ~394s per task. |
|
|
|
|
|
So much info here, so we should use or should not use
<report_results_immediately/>
in our app_config.xml file?
I did not mean start a big discussion on this but thank you for reviewing this.
Who has this BOT that we could all use if it is the correct thing to do.
So we should watch our computer and abort any tasks waiting to start seem a little over the top. I have 4 Tasks Running and 4 Waiting and cannot sit their deleting tasks every 5 seconds that sound pointless only to make sure your completed tasks uploads before some one else's complete.
This Seems a little extreme for me just to get a Prime Number and Jersey.
Scott is the GOD when to Primes and this BOINC Project that is the truth.
Maybe he can lend a hand here?
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
Ken_g6Volunteer developer
Send message
Joined: 4 Jul 06
Posts: 940
ID: 3110
Credit: 261,912,073
RAC: 16,532
|
So much info here, so we should use or should not use
<report_results_immediately/>
in our app_config.xml file?
I did not mean start a big discussion on this but thank you for reviewing this.
As I understand it, the PrimeGrid server is configured to send results immediately whether or not you set this. So it doesn't matter here.
____________
|
|
|
|
|
So much info here, so we should use or should not use
<report_results_immediately/>
in our app_config.xml file?
I did not mean start a big discussion on this but thank you for reviewing this.
As I understand it, the PrimeGrid server is configured to send results immediately whether or not you set this. So it doesn't matter here.
Thanks and to funny on your Avatar
Under Version 7.6.31 I get this anyway
PrimeGrid: Notice from BOINC
Unknown tag in app_config.xml: report_results_immediately/
Sat 03 Feb 2018 10:30:29 AM MST
____________
Crunching@EVGA The Number One Team in the BOINC Community. Folding@EVGA The Number One Team in the Folding@Home Community. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14011
ID: 53948
Credit: 430,792,981
RAC: 1,088,994
|
