Author |
Message |
|
Welcome to the Perseid Shower Challenge
The night sky can offer some wonderful sights, like distant stars and planets, the milkyway but also meteor showers. The Perseids are a prolific meteor shower associated with the comet Swift-Tuttle. The Perseids are so-called because the point from which they appear to come, called the radiant, lies in the constellation Perseus. The name derives in part from the word Perseides (Περσείδες), a term found in Greek mythology referring to the sons of Perseus. [wiki] This shower has been observed for approximately 2000 years, so as themes for a challenge go: it's one with a few years of history. PrimeGrid is therefor offering a 48 hour Challenge on The Riesel Problem (Sieve).
To participate in the Challenge, please select only the TRP (Sieve) project in your PrimeGrid preferences section. The Challenge will begin 12 Aug 2014 18:00 UTC and end 14 Aug 2014 18:00 UTC. Application builds are available for MacIntel, Linux 32 & 64 bit and Windows 32 & 64 bit.
Note: 64 bit builds benefit from a 1.7X speed advantage over 32 bit...so 1.7X the credit. :)
NOTE: In your PrimeGrid preferences section, set "Send work from any subproject if selected projects have no work" to no to guarantee that no other work will be sent.
Recommendation: The TRP (Sieve) application requires a one time download of a 22.2MB sieve file. Please consider running a few TRP (Sieve) WU's before the Challenge begins so your client will already have the sieve file. This way, bandwidth can be used to deliver WU's instead of the sieve file. :) Thank you!
The World Clock - Time Zone Converter
NOTE: The countdown clock on the front page uses the host computer time. Therefore, if your computer time is off, so will the countdown clock. For precise timing, use the UTC Time in the data section to the left of the countdown clock.
Scoring Information
Scores will be kept for individuals and teams. Only work units issued AFTER 12 Aug 2014 18:00 UTC and received BEFORE 14 Aug 2014 18:00 UTC will be considered for credit. Since this is a fixed credit project, we'll be using BOINC credit for scoring. A quorum of 2 is NOT needed to award Challenge score - i.e. no double checker. Therefore, each returned result will earn a Challenge score. Please note that if the result is eventually declared invalid, the score will be removed.
Clean up
Since this is the first sieving challenge being run with double checking turned on for these type of projects there will be a clean up just like with LLR and GFN challenges.
At the Conclusion of the Challenge
We would prefer users "moving on" to finish those tasks they have downloaded, if not then please ABORT the WU's instead of DETACHING, RESETTING, or PAUSING.
ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of an LLR Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.
Please consider either completing what's in the queue or ABORTING them. Thank you. :)
About The Riesel Problem
Hans Ivar Riesel (born 1929 in Stockholm) is a Swedish mathematician. In 1956, he showed that there are an infinite number of positive odd integer k's such that k*2^n-1 is composite (not prime) for every integer n>=1. These numbers are now called Riesel numbers. He further showed that k=509203 was such one.
It is conjectured that 509203 is the smallest Riesel number. The Riesel problem consists in determining that 509203 is the smallest Riesel number. To show that it is the smallest, a prime of the form k*2^n-1 must be found for each of the positive integer k's less than 509203. As of December 2013, there remain 52 k's for which no primes have been found. They are as follows:
2293, 9221, 23669, 31859, 38473, 46663, 67117, 74699, 81041, 93839, 97139, 107347, 121889, 129007, 143047, 146561, 161669, 192971, 206039, 206231, 215443, 226153, 234343, 245561, 250027, 273809, 315929, 319511, 324011, 325123, 327671, 336839, 342847, 344759, 362609, 363343, 364903, 365159, 368411, 371893, 384539, 386801, 397027, 402539, 409753, 444637, 470173, 474491, 477583, 485557, 494743, 502573
For a more detailed history and status of the Riesel problem, please visit Wilfrid Keller's The Riesel Problem: Definition and Status.
Additional Information
Riesel Number (Wolfram MathWorld)
Riesel Number (Wiki)
Riesel Number (The Prime Glossary)
The Riesel problem is to k*2^n-1 as the Sierpinski problem is to k*2^n+1. There is no equivalent to the 'prime' Sierpinski problem since k=509203, the conjectured smallest Riesel number, is prime.
What is sieving?
Sieving is the first step to prime finding. In general, a sieve separates wanted/desired elements from unwanted material using a tool such as a mesh, net or other filtration or distillation methods. The word "sift" derives from this term. (Wikipedia - Sieve)
In PrimeGrid's case, the desired elements ultimately are prime numbers and the unwanted material are composite numbers. Our tool of choice for PSP/SoB sieve is Geoff Reynolds' sr2sieve program. It eliminates possible candidates by removing numbers that have small factors. As this process is much faster than primality testing, it is good to thoroughly sieve a data set before primality testing.
Sieving removes many candidates at the beginning. However, the deeper the sieve goes, the slower the rate of removal, till eventually sieving removes candidates at the same rate as primality testing. This is sometimes referred to as "optimal depth". Primality testing is recommended at this point.
There are many factors that determine how much time and how deep to sieve. After sieving, all the remaining candidates must be primality tested to determine their "prime" status.
32 bit OS with 64 bit CPU
This is for those who are "driving with the hand brake active" (running a 32 bit OS on a 64 bit machine) ;) Wubi is a very nice tool that installs Ubuntu as a dual boot to your 64 bit machine. It's as simple as adding a program to Windows. You can even uninstall it like you would any other program. :)
Wubi - Ubuntu Installer
After getting 64 bit OS running on your machine, here's a link to ALL BOINC clients (including Linux x64): http://boinc.berkeley.edu/download_all.php If you are new to Linux and need help getting set up, let us know.
It really is simple. :) With that said, check what installations WUBI will NOT work on: Unsupported set-ups
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
We're down to 52 k's remaining. The last prime was found in December. http://www.primegrid.com/forum_thread.php?id=1731&nowrap=true#55910
____________
My lucky number is 75898524288+1 |
|
|
Sysadm@Nbg Volunteer moderator Volunteer tester Project scientist
 Send message
Joined: 5 Feb 08 Posts: 1216 ID: 18646 Credit: 858,332,648 RAC: 171,091
                      
|
Question: current sieve file is named TRP_20121210.sieveinput ???
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Question: current sieve file is named TRP_20121210.sieveinput ???
No.
The current sieve file is "TRP_20131229.sieveinput".
____________
My lucky number is 75898524288+1 |
|
|
Sysadm@Nbg Volunteer moderator Volunteer tester Project scientist
 Send message
Joined: 5 Feb 08 Posts: 1216 ID: 18646 Credit: 858,332,648 RAC: 171,091
                      
|
thanks!
maybe include the name of the file in the first visible post and hide this one and the last two ...
____________
Sysadm@Nbg
my current lucky number: 113856050^65536 + 1
PSA-PRPNet-Stats-URL: http://u-g-f.de/PRPNet/
|
|
|
|
Am I the only cruncher that struggles with the starting time via the countdown timer and UTC time when using Windows tasks to start.
Correct me if I am wrong please.
Challenge begins Aug 14 at 18:00 UTC
I am in Halifax, or (UTC-04:00) so I begin at 14:00 or 2pm Atlantic time
For some reason my scheduled Windows task launches Boinc at the correct clock time, but one hour early for the last challenge.
Of course all the work units initially downloaded did not count towards my score as they were downloaded before the start.
Do I need to factor DST into it?
Thanks for any help,
M
____________
PrimeSearch Team |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Do I need to factor DST into it?
If you use DST where you are, and your PC's clock is set to your local time (as opposed to being set to UTC, then yes, you need to factor DST into your time calculations.
If you're on DST, then your time zone offset right now is -3:00 rather than -4:00, which is why you're off by an hour. You should be starting, therefore, at 15:00 local time (3 PM).
____________
My lucky number is 75898524288+1 |
|
|
|
DST = Daylight Savings Time
|
|
|
Monkeydee Volunteer tester
 Send message
Joined: 8 Dec 13 Posts: 532 ID: 284516 Credit: 1,428,463,889 RAC: 1,533,496
                           
|
Am I the only cruncher that struggles with the starting time via the countdown timer and UTC time when using Windows tasks to start.
Correct me if I am wrong please.
Challenge begins Aug 14 at 18:00 UTC
I am in Halifax, or (UTC-04:00) so I begin at 14:00 or 2pm Atlantic time
For some reason my scheduled Windows task launches Boinc at the correct clock time, but one hour early for the last challenge.
Of course all the work units initially downloaded did not count towards my score as they were downloaded before the start.
Do I need to factor DST into it?
Thanks for any help,
M
We are UTC-03:00 right now because UTC does not follow DST and instead remains constant. GMT does follow DST which is why UTC is not to be confused with GMT.
____________
My Primes
Badge Score: 4*2 + 6*2 + 7*4 + 8*8 + 11*3 + 12*1 = 157
|
|
|
axnVolunteer developer Send message
Joined: 29 Dec 07 Posts: 285 ID: 16874 Credit: 28,027,106 RAC: 0
            
|
GMT does follow DST
No, it doesn't. |
|
|
Ken_g6 Volunteer developer
 Send message
Joined: 4 Jul 06 Posts: 938 ID: 3110 Credit: 258,316,274 RAC: 80,668
                            
|
I guess the ARM/Android build is still broken? :(
____________
|
|
|
|
Correct, GMT and UTC are the basically the same, but UTC became the preferred.
Sailors, Defence and various other organisations know it as zulu time.
But I apologise for detracting from the main subject.
And as per http://www.timeanddate.com/worldclock/canada/halifax, you are UTC -3
Regards
Tazzduke |
|
|
|
Thanks for the help, all.
Looking forward to the challenge
____________
PrimeSearch Team |
|
|
yank  Send message
Joined: 14 May 07 Posts: 111 ID: 8367 Credit: 11,474,819,218 RAC: 0
                    
|
Challenge start on Aug 12 and end Aug 14
____________
|
|
|
|
Well, as far as I know I ran some TRP-Sieves a couple of months ago and just checked, I have the correct sieve-input-file (TRP_20131229.sieveinput), but it's size is only 22.2 MB, not 32.4MB. How that? |
|
|
Tyler Project administrator Volunteer tester Send message
Joined: 4 Dec 12 Posts: 1078 ID: 183129 Credit: 1,376,122,338 RAC: 8,547
                         
|
Well, as far as I know I ran some TRP-Sieves a couple of months ago and just checked, I have the correct sieve-input-file (TRP_20131229.sieveinput), but it's size is only 22.2 MB, not 32.4MB. How that?
That is the correct size, the longer the sieve goes on the smaller the sieve file gets. My oldest sieve files in the projects diectory is 34.5MB, the newest is 22.2MB
____________
275*2^3585539+1 is prime!!! (1079358 digits)
Proud member of Aggie the Pew
|
|
|
|
Ooooops, interesting! :o
Well, I have some backups of my own, and wow, 36,1 MB in mid-2011.
Very interesting! :o
Thank you! :d: |
|
|
|
Well, as far as I know I ran some TRP-Sieves a couple of months ago and just checked, I have the correct sieve-input-file (TRP_20131229.sieveinput), but it's size is only 22.2 MB, not 32.4MB. How that?
That is because I am tad lazy and forgot to check that part of the post. Fixed it now.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|
|
I`m ready for the challenge ;-)
____________
|
|
|
|
Everyone be sure to run a few WUs ahead of time to download the current sieve file, if you haven't run TRP Sieve in the last several months. I'll have four boxes on the challenge, and two of them needed to do the download (done!). The sieve file is something like 22MB, but the WU command files are less than 100 bytes each.
I was hoping this challenge would carry me to a new turquoise TRP Sieve badge. But, given the credit rate and my resources, it looks like "not so". I'll have to keep at it afterwards doing cleanup for that. No worries. Good luck to all.
--Gary
____________
"I am he as you are he as you are me and we are all together"
87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit) |
|
|
|
I`m ready for the challenge ;-)
This is a fun challenge with a lot of points, a lot of works with a small time - the name is Shower, Yes thats true !
____________
|
|
|
|
And we're off! :)
Good luck and have fun to everyone.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|
|
launched at correct time :)
UTC -03:00
____________
PrimeSearch Team |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
10 minutes in and about 13K tasks have been sent out.
____________
My lucky number is 75898524288+1 |
|
|
|
My computer already protests vigorously! ;) |
|
|
|
averaging 17-20 minutes. each. go go go... trying to hold off on doing my VM work.. lol |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
After a little more than 2 hours:
161K tasks sent out.
17K tasks returned.
We been doing about 28K tasks per day recently.
____________
My lucky number is 75898524288+1 |
|
|
|
I'm having an unexpected problem - BOINC is completing and reporting the WUs fine, and they're showing up on my personal stats page, but I'm not on the scoreboard at all... I can't think what the problem would be, I've only got one BOINC account and my client is showing me and my team as it usually does. Any ideas? Cheers |
|
|
|
I'm having an unexpected problem - BOINC is completing and reporting the WUs fine, and they're showing up on my personal stats page, but I'm not on the scoreboard at all... I can't think what the problem would be, I've only got one BOINC account and my client is showing me and my team as it usually does. Any ideas? Cheers
All your reported tasks were downloaded before 18h00 UTC. Only work
downloaded after challenge start and reported before challenge ends will count towards leaderboards.
____________
676754^262144+1 is prime |
|
|
|
Gah, I think I aborted only tasks which were visible in my client before the challenge started (I was already running TRP Sieve), but there were more offscreen. I was in a hurry earlier... ah well, annoying, but cheers for clearing up the "mystery". |
|
|
|
gazzyk1ns,
+ 03 Minutes Server-time !
____________
|
|
|
|
Gah, I think I aborted only tasks which were visible in my client before the challenge started (I was already running TRP Sieve), but there were more offscreen. I was in a hurry earlier... ah well, annoying, but cheers for clearing up the "mystery".
If you have your host permanently connected to the internet, a 0 caches is probably the best option to start a challenge with small WUs. But you still have time to climb the scoreboard. Good luck!
____________
676754^262144+1 is prime |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
We have observed that some sieve tasks were being completed in very short periods of time. Perhaps due to overclocking, or for some other reason, on some hosts the sieve is failing in a very short period of time. We have, therefore, started marking all tasks with either an elapsed time or cpu time of less than 12 minutes as invalid.
I do not believe it's possible for any CPU running at less than about 6.0 GHz to actually complete a sieve task in 12 minutes, but if you have a computer that is able to complete the tasks in 12 minutes, please let me know.
Tasks that have already been validated will not be affected, even if they completed in less than 12 minutes.
The same change has also been made to the PSP/SoB/ESP Sieve, which has slightly longer tasks.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
After 6 hours:
247184 tasks sent.
54874 results returned.
____________
My lucky number is 75898524288+1 |
|
|
|
Gah, I think I aborted only tasks which were visible in my client before the challenge started (I was already running TRP Sieve), but there were more offscreen. I was in a hurry earlier... ah well, annoying, but cheers for clearing up the "mystery".
If you have your host permanently connected to the internet, a 0 caches is probably the best option to start a challenge with small WUs. But you still have time to climb the scoreboard. Good luck!
I've brain-faded on the vertical scrolling myself once or twice, so you're not the only one, gazzyk1ns. The other thing that has bitten me in the past is that "show active tasks" / "show all tasks" button on the gui client. It's usually in the context of "why in blazes am I not downloading new work??". It's not a very useful feature IMHO but I guess *somebody* must like it.
Anyway, very smooth challenge so far.
--Gary
____________
"I am he as you are he as you are me and we are all together"
87*2^3496188+1 is prime! (1052460 digits)
4 is not prime! (1 digit) |
|
|
streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1022 ID: 301928 Credit: 543,195,386 RAC: 2
                        
|
We have observed that some sieve tasks were being completed in very short periods of time. Perhaps due to overclocking, or for some other reason, on some hosts the sieve is failing in a very short period of time. We have, therefore, started marking all tasks with either an elapsed time or cpu time of less than 12 minutes as invalid.
Not either, check both times! It could be another problem, but, for example, this and this tasks are correct! The corruption of run time happened somewhere on the way to server or on server side. In the local log file, run time was reported correctly (ct=cpu time, et=elapsed/run time):
1407916511 ue 2082.216174 ct 1779.220000 fe 7312212404730 nm TRP_sieve_7258361_0 et 1790.918814 es 0
1407925200 ue 2082.216174 ct 1753.410000 fe 7312212404730 nm TRP_sieve_7270267_0 et 1763.859896 es 0
And most suspicious that each such workunit had very strange error when reporting result to server:
crunchy PrimeGrid 13.08.2014 13:21:41 Started download of TRP_sieve_7270267_cmd
crunchy PrimeGrid 13.08.2014 13:21:43 Finished download of TRP_sieve_7270267_cmd
crunchy PrimeGrid 13.08.2014 13:50:34 Starting task TRP_sieve_7270267_0
crunchy PrimeGrid 13.08.2014 14:19:59 Computation for task TRP_sieve_7270267_0 finished
crunchy PrimeGrid 13.08.2014 14:20:01 Started upload of TRP_sieve_7270267_0_0
crunchy PrimeGrid 13.08.2014 14:20:04 Finished upload of TRP_sieve_7270267_0_0
crunchy PrimeGrid 13.08.2014 14:20:06 Sending scheduler request: To report completed tasks.
crunchy PrimeGrid 13.08.2014 14:20:06 Reporting 1 completed tasks
crunchy PrimeGrid 13.08.2014 14:20:06 Requesting new tasks for CPU
crunchy PrimeGrid 13.08.2014 14:21:40 Scheduler request completed: got 1 new tasks
crunchy PrimeGrid 13.08.2014 14:21:40 Resent lost task TRP_sieve_7270267_0
crunchy PrimeGrid 13.08.2014 14:21:40 [error] Already have task TRP_sieve_7270267_0
Also note unexpectedly high server processing time (between "reporting/requesting" and "request completed"). I don't know is it Boinc client or server bug, or server problem, but workunits are correct regardless of wrong "run time" value stored in server database.
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
We have observed that some sieve tasks were being completed in very short periods of time. Perhaps due to overclocking, or for some other reason, on some hosts the sieve is failing in a very short period of time. We have, therefore, started marking all tasks with either an elapsed time or cpu time of less than 12 minutes as invalid.
Not either, check both times! It could be another problem, but, for example, this and this tasks are correct! The corruption of run time happened somewhere on the way to server or on server side. In the local log file, run time was reported correctly (ct=cpu time, et=elapsed/run time):
They'll validate fine. The boinc client frequently messes up the elapsed time and we take that into account.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
For the remainder of this challenge, the challenge statistics will be produced once an hour rather than every 15 minutes.
There are some performance issues on the slave DB server, and the challenge statistics are one of the causes.
For those curious about the technical details, the slave DB has very fast disks (SSD) but a comparatively small amount of memory. The amount of memory may be too small for the challenge queries being run with the large number of tasks being generated for this challenge. Not only are the tasks short, but because it's a sieve, people with Hyperthreaded CPUs are probably running all cores rather than only half of the cores like they would with an LLR challenge. We've sent out about 400K tasks in 18 hours. We don't keep statistics like that, but if it's not a record, it's close to it.
____________
My lucky number is 75898524288+1 |
|
|
|
After 6 hours:
247184 tasks sent.
54874 results returned.
At that rate there should be lots of wu for the World Animal Day TRP LLR Challenge and well beyond. lol
____________
PrimeSearch Team |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
After 6 hours:
247184 tasks sent.
54874 results returned.
At that rate there should be lots of wu for the World Animal Day TRP LLR Challenge and well beyond. lol
Not exactly...
1) Sieve tasks REMOVE LLR candidates, so the more sieving we do, the fewer LLR tasks there are. That's the purpose of sieving. :) In theory, if we did enough sieving, we'd eventually eliminate every LLR candidate except for the ones that are prime. (That works in theory, but not in practice. The universe is literally too small to actually do that.)
2) Usually we're sieving a different range than we're testing with LLR, so the sieving we're doing now won't affect what we're testing with LLR for a while.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
At the halfway point:
509643 tasks have been sent out.
284078 (56%) have been successfully returned.
That's almost exactly 10 times the normal rate of processing. Well done! Can we keep up this pace for the second day of the challenge?
____________
My lucky number is 75898524288+1 |
|
|
|
Not exactly...
1) Sieve tasks REMOVE LLR candidates, so the more sieving we do, the fewer LLR tasks there are. That's the purpose of sieving. :) In theory, if we did enough sieving, we'd eventually eliminate every LLR candidate except for the ones that are prime. (That works in theory, but not in practice. The universe is literally too small to actually do that.)
Challenge accepted. :D |
|
|
|
Not only are the tasks short, but because it's a sieve, people with Hyperthreaded CPUs are probably running all cores rather than only half of the cores like they would with an LLR challenge.
Aw, heck. I've been running LLR tasks for so long that I forgot to re-enable Hyperthreading for this challenge.
Fixed. |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Not only are the tasks short, but because it's a sieve, people with Hyperthreaded CPUs are probably running all cores rather than only half of the cores like they would with an LLR challenge.
Aw, heck. I've been running LLR tasks for so long that I forgot to re-enable Hyperthreading for this challenge.
Fixed.
It could be worse. I bought an i5 because I knew I wouldn't be using hyperthreading, so I can't turn it on even if I wanted to.
____________
My lucky number is 75898524288+1 |
|
|
Ken_g6 Volunteer developer
 Send message
Joined: 4 Jul 06 Posts: 938 ID: 3110 Credit: 258,316,274 RAC: 80,668
                            
|
I bought an i5, and I turned on hyper-threading. :D
Hint: What I did won't help your i5, and your i5 will be faster than mine.
____________
|
|
|
|
At the Conclusion of the Challenge
We would prefer users "moving on" to finish those tasks they have downloaded, if not then please ABORT the WU's instead of DETACHING, RESETTING, or PAUSING.
ABORTING WU's allows them to be recycled immediately; thus a much faster "clean up" to the end of a Challenge. DETACHING, RESETTING, and PAUSING WU's causes them to remain in limbo until they EXPIRE. Therefore, we must wait until WU's expire to send them out to be completed.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|
|
Hand full of factors and silver badge in TRP s.
Fun challenge
____________
PrimeSearch Team |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
End of challenge stats:
Challenge: Perseid Shower
(As of 2014-08-14 18:35:54 UTC)
810562 tasks have been sent out. [CPU/GPU/anonymous_platform: 810562 (100%) / 0 (0%) / 0 (0%)]
Of those tasks that have been sent out:
25623 (3%) came back with some kind of an error. [25623 (3%) / 0 (0%) / 0 (0%)]
595231 (73%) have returned a successful result. [595231 (73%) / 0 (0%) / 0 (0%)]
168809 (21%) are still in progress. [168499 (21%) / 0 (0%) / 0 (0%)]
Of the tasks that have been returned successfully:
129910 (22%) are pending validation. [129771 (22%) / 0 (0%) / 0 (0%)]
465315 (78%) have been successfully validated. [465454 (78%) / 0 (0%) / 0 (0%)]
2 (0%) were invalid. [2 (0%) / 0 (0%) / 0 (0%)]
4 (0%) are inconclusive. [4 (0%) / 0 (0%) / 0 (0%)]
Just under 600K tasks were returned during the challenge. Well done!
____________
My lucky number is 75898524288+1 |
|
|
|
Tasks less than last year, I reckon. Perhaps that "super-cruncher" using "the cloud" last year is the reason for it.
Personally, everything went well. Two factors in from my side. Computer ultrastable using all 8 nominal cores; i don't do that this often.
One technical question: I have a AMD-Bulldozer-Type computer of 8 nominal cores,which each core having an integer unit, but two cores each sharing a floating point unit. I made the experience, that this Sieve challenge used these 8 logic cores almost to the optimum, whereas at the latest SR5 LLR challenge it didn't make much difference weather using 8 or just 4 cores.
Now my question: Is LLR using more floating point units and sieving more integer units? Or is there another explanation for my experience? |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Now my question: Is LLR using more floating point units and sieving more integer units? Or is there another explanation for my experience?
LLR (and Genefer) are almost all floating point (double precision floating point, to be specific.)
Sieves are almost all integer.
So LLR is totally dependent on your floating point speed, while the sieves are totally dependent on your integer speed. That's why you see better performance using all 8 cores on the sieve, while with LLR you get the same performance with either 4 or 8 cores.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
|
I do not see my name on the list, maybe I need glasses? Sun Badger* |
|
|
|
I do not see my name on the list, maybe I need glasses? Sun Badger*
The challenge ended yesterday, August 14, 18h00 UTC. Do you have any WUs uploaded before that?
____________
676754^262144+1 is prime |
|
|
|
This WU seems a bit odd It may be that I rebooted the machine while it was running, but I am unsure of that, according to the Validation process it took an unusually short amount of time to run it for this machine but it came back as Valid. I did see where it was mentioned there was a problem with short runtime. If the runtime is correct I very seriously doubt this Valid status is correct.
http://www.primegrid.com/workunit.php?wuid=402260432
canonical result 565491504
Work Unit 402260432 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
This WU seems a bit odd It may be that I rebooted the machine while it was running, but I am unsure of that, according to the Validation process it took an unusually short amount of time to run it for this machine but it came back as Valid. I did see where it was mentioned there was a problem with short runtime. If the runtime is correct I very seriously doubt this Valid status is correct.
http://www.primegrid.com/workunit.php?wuid=402260432
canonical result 565491504
Work Unit 402260432
Indeed, that computer had caught our attention.
It's not working correctly. If it's overclocked, it's overclocked way too high. If it's not overclocked, something is broken. (My first guess would be memory, but it could be anything, really.)
Most of the tasks are dying well before they complete. We have some 'sanity checks' in place to catch tasks with unreasonably short run times, but there's computers much faster than this one that can complete these tasks in about 20 minute, so we can't set those thresholds very high or we'll be tossing out perfectly good tasks.
Assuming the result is still correct , some of this computer's tasks would be marked invalid, and some (which ran longer before failing) would be marked valid and would receive credit. (We're not thrilled with this, and may seek to improve the validation at some point.)
This computer (and one other) got the benefit of the doubt as far as credit is concerned. (The tracking for the challenge leaderboards is more strict since it's not fair to other participants to have faulty tasks get challenge points.)
The bottom line is this computer isn't working correctly and you should take a look at it.
____________
My lucky number is 75898524288+1 |
|
|
|
This WU seems a bit odd It may be that I rebooted the machine while it was running, but I am unsure of that, according to the Validation process it took an unusually short amount of time to run it for this machine but it came back as Valid. I did see where it was mentioned there was a problem with short runtime. If the runtime is correct I very seriously doubt this Valid status is correct.
http://www.primegrid.com/workunit.php?wuid=402260432
canonical result 565491504
Work Unit 402260432
Indeed, that computer had caught our attention.
It's not working correctly. If it's overclocked, it's overclocked way too high. If it's not overclocked, something is broken. (My first guess would be memory, but it could be anything, really.)
Most of the tasks are dying well before they complete. We have some 'sanity checks' in place to catch tasks with unreasonably short run times, but there's computers much faster than this one that can complete these tasks in about 20 minute, so we can't set those thresholds very high or we'll be tossing out perfectly good tasks.
Assuming the result is still correct , some of this computer's tasks would be marked invalid, and some (which ran longer before failing) would be marked valid and would receive credit. (We're not thrilled with this, and may seek to improve the validation at some point.)
This computer (and one other) got the benefit of the doubt as far as credit is concerned. (The tracking for the challenge leaderboards is more strict since it's not fair to other participants to have faulty tasks get challenge points.)
The bottom line is this computer isn't working correctly and you should take a look at it.
Yes it is a 48 core Opteron overclocked to 3.9Ghz . Are these WU's more sensitive to overclock than others. This machine has run Many other Boinc and Primgrid projects without problems at the current settings. I will fix the OC on this Machines while it is running the clean up or remove them and put them running something else if it can not be fixed.
This computer (and one other) got the benefit of the doubt as far as credit is concerned. (The tracking for the challenge leaderboards is more strict since it's not fair to other participants to have faulty tasks get challenge points.)
Is this other one you are refuring to one of my computers, If it is, I can not find another one with short run times for some reason. If it is mine do you know the Machine ID number ? so I can monitor it and fix it.
One of the things I am a little worried about is that the WU was validated against another computer which I do not believe was correct it should have come up as invalid. Is there also something wrong with the normal Validation process on these WU's, I think it should have failed validation when checked against another computers results. I would think this could really be messing up the projects results.
Name TRP_sieve_7436884_1
Workunit 402260432
Created 14 Aug 2014 | 8:44:16 UTC
Sent 14 Aug 2014 | 10:21:36 UTC
Received 14 Aug 2014 | 12:49:00 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 418989
Report deadline 18 Aug 2014 | 11:21:36 UTC
Run time 2,404.61
CPU time 2,400.95
Validate state Valid
Credit 120.14
Application version The Riesel Problem (Sieve) v1.12
Name TRP_sieve_7436884_2
Workunit 402260432
Created 15 Aug 2014 | 16:06:39 UTC
Sent 15 Aug 2014 | 16:14:47 UTC
Received 15 Aug 2014 | 16:31:39 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 432611
Report deadline 19 Aug 2014 | 17:14:47 UTC
Run time 913.15
CPU time 872.70
Validate state Valid
Credit 120.14
Application version The Riesel Problem (Sieve) v1.07 |
|
|
streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1022 ID: 301928 Credit: 543,195,386 RAC: 2
                        
|
This WU seems a bit odd It may be that I rebooted the machine while it was running, but I am unsure of that, according to the Validation process it took an unusually short amount of time to run it for this machine but it came back as Valid. I did see where it was mentioned there was a problem with short runtime. If the runtime is correct I very seriously doubt this Valid status is correct.
http://www.primegrid.com/workunit.php?wuid=402260432
If you'll look at sterr output (in "Task Details"), it's quite clear that sieve program has been was aborted at ~25%:
Progress: 0.258672
Factors file not found
called boinc_finish
While second task was at least somewhere near 100% and most probably finished just fine:
.927531
.952566
Factors file not found
called boinc_finish
As for overclocking, CPU temperatures during sieve are significantly lower then on short LLR. But don't forget that each TRP Sieve task requires ~160 Megabytes of memory, so your 48 cores will use almost 8 Gigabytes only for Boinc, not counting other tasks and services run on this host.
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Yes it is a 48 core Opteron overclocked to 3.9Ghz . Are these WU's more sensitive to overclock than others.
It's hard to really say, but my guess is that in general sieve tasks are LESS sensitive to errors than LLR. The CPU is running cooler and using less power.
One of the problems is that it's comparatively more difficult to detect problems in sieves than in LLR, so we've kind of been operating with our collective heads in the sand as far as sieve reliability goes. Perhaps it is more sensitive on certain systems. I really don't know.
Is this other one you are refuring to one of my computers
No, it was somebody else's.
One of the things I am a little worried about is that the WU was validated against another computer which I do not believe was correct it should have come up as invalid. Is there also something wrong with the normal Validation process on these WU's, I think it should have failed validation when checked against another computers results. I would think this could really be messing up the projects results.
On this particular project, it's difficult to detect bad results because most results, whether the processing failed or not, are the same. It's therefore difficult, at least right now, to detect bad results as well as we would like to. This may change in the future. We knew these two computers were failing on almost every task only because someone brought to our attention the widely varying run times of each task. These tasks will take the same amount of time for each task, so it was obvious from the times that the tasks were failing in the middle. Looking at the stderr output confirmed that the tasks were dying in the middle. The validator doesn't normally look at stderr, however.
____________
My lucky number is 75898524288+1 |
|
|
streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1022 ID: 301928 Credit: 543,195,386 RAC: 2
                        
|
The sr2sieve output seems to have enough information to detect successful completion of workunit. I think wrapper could handle this. Example:
./sr2sieve -p372044660e8 -zz -P372044661e8 -iinput.txt -S 60
sr2sieve 1.8.2 -- A sieve for multiple sequences k*b^n+/-1 or b^n+/-k.
Reading `input.txt' ...
WARNING: --pmin=37204466000000000 from command line overrides pmin=1594683353 from `input.txt'
Read 6128950 terms for 52 sequences from ABCD format file `input.txt'.
Split 52 base 2 sequences into 611 base 2^360 subsequences.
Expecting to find factors for about 0.00 terms in this range.
sr2sieve 1.8.2 started: 6673294 <= n <= 49999994, 37204466000000000 <= p <= 37204466100000000
p=37204466089916231, 1499703 p/sec, 0 factors, 89.9% done, ETA 15 Aug 22:58
sr2sieve 1.8.2 stopped: at p=37204466100000000 because range is complete.
Found factors for 0 terms in 72.852 sec. (expected about 0.00)
Did the wrapper looking for and validates two last lines?
EDIT: the sr2sieve.log file contains the same information, it could be at least sent to server for future analysis:
Fri Aug 15 22:57:35 2014 WARNING: --pmin=37204466000000000 from command line overrides pmin=1594683353 from `input.txt'
Fri Aug 15 22:57:41 2014 sr2sieve 1.8.2 started: 6673294 <= n <= 49999994, 37204466000000000 <= p <= 37204466100000000
Fri Aug 15 22:58:48 2014 sr2sieve 1.8.2 stopped: at p=37204466100000000 because range is complete.
Fri Aug 15 22:58:48 2014 Found factors for 0 terms in 72.852 sec. (expected about 0.00)
|
|
|
|
As for overclocking, CPU temperatures during sieve are significantly lower then on short LLR. But don't forget that each TRP Sieve task requires ~160 Megabytes of memory, so your 48 cores will use almost 8 Gigabytes only for Boinc, not counting other tasks and services run on this host.
Temps are not a problem on that machine it is liquid cooled so even LLR task can not get it hot current temps are good while running these I have never seen anything above 42C when running any Primgrid work on it..
Detected processor: Family 15h (Bulldozer/Interlagos/Valencia) Processor
Machine has 8 nodes
Processor has 6 cores
Processor has 7 p-states
Processor has 2 boost states
Processor temperature slew rate:9.0°C
Temperature table:
Node 0 C0:36 C1:36 C2:36 C3:36 C4:36 C5:36
Node 1 C0:36 C1:36 C2:36 C3:36 C4:36 C5:36
Node 2 C0:38 C1:38 C2:38 C3:38 C4:38 C5:38
Node 3 C0:37 C1:37 C2:37 C3:37 C4:37 C5:37
Node 4 C0:37 C1:37 C2:37 C3:37 C4:37 C5:37
Node 5 C0:38 C1:38 C2:38 C3:38 C4:38 C5:38
Node 6 C0:38 C1:38 C2:38 C3:38 C4:38 C5:38
Node 7 C0:37 C1:37 C2:37 C3:37 C4:37 C5:37
As far as memory goes it has 32GB and is only using 25% of total available memory. and I have recently run memtest on it with no errors. I do have the ability to adjust the Core Voltage on these chips (63xx ) so I will adjust the Voltage up on them I have run them crunching up to 4.1Ghz before without issue. I have dropped the OC a little 245 x 15.5 = 3797.5 Mhz and upped the Voltage by .0125v so we shall see if that fixes the problem or if it will need another bump.
EDIT:
I have removed this machine from TRP and aborted all of the running WU's it was still not completing 100%, for the time being. I will run it on another project Primgrid Project (Mega) for testing. to see what it does there. I ran them in the last challenge with no apparent problem so I will run a limited number of them to see if the problem exist there or not. |
|
|
|
How is possible to @ this Opteron so high, is this a some SE version? Don't you afriad of vrm on motherboard?
Damn, it's some nice oc. :D |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
EDIT:
I have removed this machine from TRP and aborted all of the running WU's it was still not completing 100%, for the time being. I will run it on another project Primgrid Project (Mega) for testing. to see what it does there. I ran them in the last challenge with no apparent problem so I will run a limited number of them to see if the problem exist there or not.
With Mega, we should see pretty quickly if it's having problems.
EDIT: The only completed LLR task currently in the database for that host is an SR5 where it returned an incorrect residue, which is consistent with the problems you're seeing on the sieve.
____________
My lucky number is 75898524288+1 |
|
|
|
EDIT:
I have removed this machine from TRP and aborted all of the running WU's it was still not completing 100%, for the time being. I will run it on another project Primgrid Project (Mega) for testing. to see what it does there. I ran them in the last challenge with no apparent problem so I will run a limited number of them to see if the problem exist there or not.
With Mega, we should see pretty quickly if it's having problems.
EDIT: The only completed LLR task currently in the database for that host is an SR5 where it returned an incorrect residue, which is consistent with the problems you're seeing on the sieve.
I have 48 of the Megas running at the moment they are at 17% they show about 4hrs to complete and I have it set to no new tasks. If the follow the same pattern they should start completing about 1/2 way through so we should see them completing in about 2 hrs which would be about 50%
How is possible to @ this Opteron so high, is this a some SE version? Don't you afriad of vrm on motherboard?
Damn, it's some nice oc. :D
No VM I am running a custom bios that allows OCing on some server boards. Although it is not needed on these chips since they are ES versions. |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
I have 48 of the Megas running at the moment they are at 17% they show about 4hrs to complete and I have it set to no new tasks. If the follow the same pattern they should start completing about 1/2 way through so we should see them completing in about 2 hrs which would be about 50%
Totally different program, and the failure mode is different. They will probably run to completion, but the residues will be wrong if the there are calculation errors.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
I have 48 of the Megas running at the moment they are at 17% they show about 4hrs to complete and I have it set to no new tasks. If the follow the same pattern they should start completing about 1/2 way through so we should see them completing in about 2 hrs which would be about 50%
Totally different program, and the failure mode is different. They will probably run to completion, but the residues will be wrong if the there are calculation errors.
Some of the results are now in, and in every case so far where there's a wingman to compare against, the residues failed to match. 100% mismatch so far. That's pretty conclusive. Not as conclusive as it will be when the third tasks on each of those workunits come back, but it's enough.
____________
My lucky number is 75898524288+1 |
|
|
|
I have 48 of the Megas running at the moment they are at 17% they show about 4hrs to complete and I have it set to no new tasks. If the follow the same pattern they should start completing about 1/2 way through so we should see them completing in about 2 hrs which would be about 50%
Totally different program, and the failure mode is different. They will probably run to completion, but the residues will be wrong if the there are calculation errors.
Some of the results are now in, and in every case so far where there's a wingman to compare against, the residues failed to match. 100% mismatch so far. That's pretty conclusive. Not as conclusive as it will be when the third tasks on each of those workunits come back, but it's enough.
Yep, I am pretty sure they are going to fail, now I just need to figure out what broke. I am happy to see that the validation process is working propeller on these. Dmeseg is not giving me any clues so I am going to have to do some digging and testing :( |
|
|
streamVolunteer moderator Project administrator Volunteer developer Volunteer tester Send message
Joined: 1 Mar 14 Posts: 1022 ID: 301928 Credit: 543,195,386 RAC: 2
                        
|
Grandpa, you could run LLR on small test units yourself and see check if all 48 results are same. No need to send possibly bad results to PG, small workunits could be used for quick test during your OC experiments.
./llr -d -q"$exp" -oNoSaveFile=1
examples of expressions for different FFT sizes (and different execution times):
case "$2" in
96 ) exp="3517*2^1283744+1";; # pps
127 ) exp="301562*5^536514-1";;
128 ) exp="1460252395065*2^1290000+1";; # sgs
191 ) exp="304004*5^716816-1";;
256 ) exp="69*2^3588662+1";; # mega (pps)
383 ) exp="64598*5^1656726-1";;
385 ) exp="92906*5^1688425+1";;
447 ) exp="273662*5^1657460-1";;
640 ) exp="3*2^11234613+1";; # 321
640m) exp="3*2^11234203-1";; # 321
1280 ) exp="11556581*2^11556581+1";; # cul
1728 ) exp="237019*2^16988182+1";; # psp
* ) echo "No test for FFT size $2 defined!"
exit 1
esac
Important: each test must be run in own working directory. You must copy LLR executable (primegrid_sllr_3.8.13_x86_64-pc-linux-gnu) to this directory or make a symlink. So you'll probably need small helper shell script to setup and run all 48 tests.
When tests finishes, analyze "lresult.txt" in each working directory and compare RES64 values reported there. Since all copies were run same test, they must match. If they're not, your system is still faulty.
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
|
Every day, (very) roughly half of the remaining tasks are cleaned up. At this rate, cleanup will be completed very soon.
Or never, if we may believe Zeno. |
|
|
|
Every day, (very) roughly half of the remaining tasks are cleaned up. At this rate, cleanup will be completed very soon.
Or never, if we may believe Zeno.
It depends on your definition of "very soon".
The Zeno reference reminds me of a book I enjoyed about 20 years ago, Gödel, Escher, Bach.
I expect the 8400 tasks still outstanding have reached their first expiry, requiring a resend.
Assuming these take up to a further 4 days to be crunched, I would think it will take until about Friday, 22 August.
So that's my prediction for clean-up completion.
____________
Warped
|
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
August 19th: Perseid Shower: 4145 tasks outstanding; 833 affecting individual (106) scoring positions; 127 affecting team (9) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
August 19th: Perseid Shower: 4145 tasks outstanding; 833 affecting individual (106) scoring positions; 127 affecting team (9) scoring positions.
August 20th: Perseid Shower: 2453 tasks outstanding; 360 affecting individual (74) scoring positions; 51 affecting team (7) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
August 19th: Perseid Shower: 4145 tasks outstanding; 833 affecting individual (106) scoring positions; 127 affecting team (9) scoring positions.
August 20th: Perseid Shower: 2453 tasks outstanding; 360 affecting individual (74) scoring positions; 51 affecting team (7) scoring positions.
August 21st: Perseid Shower: 638 tasks outstanding; 56 affecting individual (27) scoring positions; 1 affecting team (1) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
August 19th: Perseid Shower: 4145 tasks outstanding; 833 affecting individual (106) scoring positions; 127 affecting team (9) scoring positions.
August 20th: Perseid Shower: 2453 tasks outstanding; 360 affecting individual (74) scoring positions; 51 affecting team (7) scoring positions.
August 21st: Perseid Shower: 638 tasks outstanding; 56 affecting individual (27) scoring positions; 1 affecting team (1) scoring positions.
August 22nd: Perseid Shower: 185 tasks outstanding; 9 affecting individual (7) scoring positions; 1 affecting team (1) scoring positions.
____________
My lucky number is 75898524288+1 |
|
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 13951 ID: 53948 Credit: 391,788,067 RAC: 149,919
                               
|
Cleanup Status:
August 14th: Perseid Shower: 114227 tasks outstanding; 100872 affecting individual (297) scoring positions; 60938 affecting team (85) scoring positions.
August 15th: Perseid Shower: 66577 tasks outstanding; 50779 affecting individual (291) scoring positions; 24472 affecting team (69) scoring positions.
August 16th: Perseid Shower: 36886 tasks outstanding; 22374 affecting individual (272) scoring positions; 6278 affecting team (50) scoring positions.
August 17th: Perseid Shower: 18871 tasks outstanding; 10740 affecting individual (244) scoring positions; 2491 affecting team (37) scoring positions.
August 18th: Perseid Shower: 8400 tasks outstanding; 2656 affecting individual (170) scoring positions; 571 affecting team (18) scoring positions.
August 19th: Perseid Shower: 4145 tasks outstanding; 833 affecting individual (106) scoring positions; 127 affecting team (9) scoring positions.
August 20th: Perseid Shower: 2453 tasks outstanding; 360 affecting individual (74) scoring positions; 51 affecting team (7) scoring positions.
August 21st: Perseid Shower: 638 tasks outstanding; 56 affecting individual (27) scoring positions; 1 affecting team (1) scoring positions.
August 22nd: Perseid Shower: 185 tasks outstanding; 9 affecting individual (7) scoring positions; 1 affecting team (1) scoring positions.
August 23rd: Perseid Shower: 54 tasks outstanding; 0 affecting individual (0) scoring positions; 0 affecting team (0) scoring positions.
The results are final!
____________
My lucky number is 75898524288+1 |
|
|
|
And with the conclusion of the challenge, the overall standings have also been updated.
Congratulations go out to Brilong, Grandpa and zunewantan for ending in first, second and third place respectively.
For the team event [H]ard|OCP, Sicituradastra. and Czech National Team have earned the medals.
____________
PrimeGrid Challenge Overall standings --- Last update: From Pi to Paddy (2016)
|
|
|