| Author |
Message |
|---|
|
|
|
Noticed the 321 Prime Sieve "coming soon". Great news! Will this wait until the conclusion of the current challenge? |
|
|
 Michael Goetz Volunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
                               
|
Noticed the 321 Prime Sieve "coming soon". Great news! Will this wait until the conclusion of the current challenge?
Certainly.
There's off-line preparatory steps that won't be finished until at least the 24th so it can't start before then.
Current thinking is that we'll probably wait until after TdP and start in mid-March, but our plans are tentative and might change.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Soon...
 |
|
|
|
|
|
chip wrote: Soon...
:)
____________
"Accidit in puncto, quod non contingit in anno."
Something that does not occur in a year may, perchance, happen in a moment. |
|
|
|
|
|
Thank you for the concise answer as usual Michael. Would one be wise to assume a "30 day notice" for GCW Sieve will be concurrent with the start of the 321 Sieve? |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Thank you for the concise answer as usual Michael. Would one be wise to assume a "30 day notice" for GCW Sieve will be concurrent with the start of the 321 Sieve?
No. Unless there's some reason for a significant delay to the start of the 321 sieve, there will be significantly more than 30 days until the start of 321 Sieve and the end of GCW sieve.
____________
My lucky number is 75898524288+1 |
|
|
tngSend message
Joined: 29 Aug 10
Posts: 500
ID: 66603
Credit: 50,920,062,473
RAC: 28,053,389
                                                   
|
|
Would anyone from the project care to comment on why the 321 sieve is being restarted (besides giving me the opportunity to improve my badge)?
____________
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Would anyone from the project care to comment on why the 321 sieve is being restarted?
321 is currently sieved up to n=25M. The current leading edge is n=14.6M. We're going to sieve 25M < n < 50M. That would bring the 321 sieve up to the same point to which we've sieved the conjecture projects. The sieving should take several years, and we'd like to get the sieving done before LLR reaches 25M. 321, having just a single k, and the smallest of all possible k's, could advance very quickly if people concentrated on it.
Additionally, with GCW sieve likely to be ending sometime this year, we did want to have another CPU sieve project to take its place. It's a good time, therefore. to reopen 321 sieving.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Excellent news!...in a sense. While I look forward to moving that bronze stain off my badge list and getting something brighter, I have one pre-AVX cpu left: A Xeon X5675. It's been relegated to sieving only (if there isn't an SGS/PPSE challenge) and I was going to finally retire the system (most of it still being the original i7-920 build from 2009) after GCW sieve ended, but now, I suppose it's gotten a stay of execution so long as we're using the old sieve program. Or is mtsieve going to make its debut here?
____________
Eating more cheese on Thursdays. |
|
|
compositeVolunteer tester
Send message
Joined: 16 Feb 10
Posts: 1172
ID: 55391
Credit: 1,219,074,377
RAC: 1,402,532
                   
|
Excellent news!...in a sense. While I look forward to moving that bronze stain off my badge list and getting something brighter, I have one pre-AVX cpu left: A Xeon X5675. It's been relegated to sieving only (if there isn't an SGS/PPSE challenge) and I was going to finally retire the system (most of it still being the original i7-920 build from 2009) after GCW sieve ended, but now, I suppose it's gotten a stay of execution so long as we're using the old sieve program. Or is mtsieve going to make its debut here?
It's not a stain to me. I'm trying to retain the whole gamut of badge levels.
It hasn't worked too well with challenges, and I was a bit disappointed when the badge upgrades happened a number of years ago. Probably the only person who was disappointed LOL. |
|
|
JimBHonorary cruncher
Send message
Joined: 4 Aug 11
Posts: 920
ID: 107307
Credit: 989,981,867
RAC: 47,580
           
|
Excellent news!...in a sense. While I look forward to moving that bronze stain off my badge list and getting something brighter, I have one pre-AVX cpu left: A Xeon X5675. It's been relegated to sieving only (if there isn't an SGS/PPSE challenge) and I was going to finally retire the system (most of it still being the original i7-920 build from 2009) after GCW sieve ended, but now, I suppose it's gotten a stay of execution so long as we're using the old sieve program. Or is mtsieve going to make its debut here?
I don't see an mtsieve program that's appropriate. fbncsieve uses a fixed b, n and c value with variable k. fkbnsieve is fixed k, b n with variable c. None of the others are appropriate. Feel free to point out if I'm missing something there. |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3254
ID: 130544
Credit: 2,455,077,411
RAC: 4,344,791
                  
|
|
Looking forward to it & can be patient another 2 months. I need doorstop food anyway. |
|
|
rogueVolunteer developer
Send message
Joined: 8 Sep 07
Posts: 1259
ID: 12001
Credit: 18,565,548
RAC: 0
|
Excellent news!...in a sense. While I look forward to moving that bronze stain off my badge list and getting something brighter, I have one pre-AVX cpu left: A Xeon X5675. It's been relegated to sieving only (if there isn't an SGS/PPSE challenge) and I was going to finally retire the system (most of it still being the original i7-920 build from 2009) after GCW sieve ended, but now, I suppose it's gotten a stay of execution so long as we're using the old sieve program. Or is mtsieve going to make its debut here?
I don't see an mtsieve program that's appropriate. fbncsieve uses a fixed b, n and c value with variable k. fkbnsieve is fixed k, b n with variable c. None of the others are appropriate. Feel free to point out if I'm missing something there.
Correct, none of the programs built upon mtsieve support fixed k/variable n sieves, aka srsieve/sr1sieve/sr2sieve. Integrating srsieve into mtsieve will take a lot of work. |
|
|
|
|
|
OK, I gotcha. I just remember reading about your new sieve program(s) awhile back and there seemed to be some optimism that we could "freshen" PG sieving with new speed/instruction support, etc.
____________
Eating more cheese on Thursdays. |
|
|
rogueVolunteer developer
Send message
Joined: 8 Sep 07
Posts: 1259
ID: 12001
Credit: 18,565,548
RAC: 0
|
OK, I gotcha. I just remember reading about your new sieve program(s) awhile back and there seemed to be some optimism that we could "freshen" PG sieving with new speed/instruction support, etc.
Both gcwsieve and mfsieve are built upon the mtsieve framework and should be faster than the previous versions.
I'm looking into the possibility of integrating srsieve/sr1sieve/sr2sieve into the framework.
It would be interesting if other developers used mtsieve as the framework for other forms to see if there is any improvement in speed, but none have shown interest. |
|
|
KEPSend message
Joined: 10 Aug 05
Posts: 303
ID: 110
Credit: 13,001,669
RAC: 23,247
        
|
Would anyone from the project care to comment on why the 321 sieve is being restarted?
321 is currently sieved up to n=25M. The current leading edge is n=14.6M. We're going to sieve 25M < n < 50M. That would bring the 321 sieve up to the same point to which we've sieved the conjecture projects. The sieving should take several years, and we'd like to get the sieving done before LLR reaches 25M. 321, having just a single k, and the smallest of all possible k's, could advance very quickly if people concentrated on it.
Additionally, with GCW sieve likely to be ending sometime this year, we did want to have another CPU sieve project to take its place. It's a good time, therefore. to reopen 321 sieving.
I´m sure you have thought about it, but once n>25M to n<=50M reaches the sievedepth that n<=25M were stopped at, then please include the currently unsearched n´s in the sieve file - it will save you quite a bit of WU on the n<=25M range and it won´t slowdown your sievespeed too much (if any at all). |
|
|
JimBHonorary cruncher
Send message
Joined: 4 Aug 11
Posts: 920
ID: 107307
Credit: 989,981,867
RAC: 47,580
|
I´m sure you have thought about it, but once n>25M to n<=50M reaches the sievedepth that n<=25M were stopped at, then please include the currently unsearched n´s in the sieve file - it will save you quite a bit of WU on the n<=25M range and it won´t slowdown your sievespeed too much (if any at all).
Yes, I did think of that and that's the plan. It will take slightly longer to sieve those and we'll probably have to adjust the credit rate upward. The way sieving is set up, we have control of the credit amount on every individual workunit. So when the sieve file gets n=16M-25M (16M is a guess) added to it, only those workunits using that new sieve will receive more credit. |
|
|
|
|
|
wouldn't it make more sense to sieve this first?
|
|
|
JimBHonorary cruncher
Send message
Joined: 4 Aug 11
Posts: 920
ID: 107307
Credit: 989,981,867
RAC: 47,580
|
wouldn't it make more sense to sieve this first?
I have no idea what you mean. I was hoping not to have to explain this, but:
The 321 subproject tests candidates in the form k*b^n±1 where k=3 and b=2. In the past we sieved all candidates for n less than 25 million. Sieving kept going until an optimal level - that is it would take less time to test candidates with LLR than to keep sieving. When we sieve, there's a test divisor p which is tested against every candidate to see if p divides a candidate evenly. I'm assuming the letter p is used because it's always going to be a small (under 20 digits) prime.
We're about to start sieving n values from 25 million to 50 million. The starting p value will be 50T(50 x 1012). If any candidate is evenly divisible by any p, then it's by definition not a prime and that candidate is removed from the sieve. What KEP is saying is that we're going to sieve n=25M-50M only starting at p=50T. When we reach p=61P, which is where n=0-25M stopped, we should add the remaining part of the 0-25M sieve to the 25M-50M sieve file and so sieve part of that older range at relatively little cost. Until we reach p=61P, there's no reason to be sieving that 0-25M range - it was already done. Even if a few candidates were somehow missed, that's nothing compared to having millions of workunits search a space that's already been searched. When a factor is found, the corresponding candidate is completely removed from the sieve file. Sieving any n under 25M for any p under 61P has already been done. There's nothing there to find.
Because candidates with n=50M are so much larger than n=25M (remember, n is an exponent), we'll have to sieve to a much higher p level in any case. Adding those smaller n values back into the sieve makes a lot of sense. Because we'll be sieving a larger range (n=16M-50M for example) it'll take longer than for n=25M-50M and so I was commenting that at that point the credit given will rise by some amount. I don't know how much because I don't even have the n=25M-50M initial sieve file done yet. I'm currently sieving to p=50T on one of my computers. But since it's going to take at least a year to get to p=61P, I have lots of time to work it out. |
|
|
|
|
|
oh sorry, i missunderstood the post before, thanks for the explanation |
|
|
GregCSend message
Joined: 12 Nov 18
Posts: 57
ID: 1077873
Credit: 2,321,026,077
RAC: 6,832,468
      
|
|
I see the 321 SV as an available badge. Does anyone know when WU's can be downloaded? |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
I see the 321 SV as an available badge. Does anyone know when WU's can be downloaded?
Now.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
Time to upgrade that old silver badge :) And it appears that my first wingman is Michael himself.
____________
 |
|
|
|
|
I see the 321 SV as an available badge. Does anyone know when WU's can be downloaded?
Now.
Awesome! |
|
|
Dave
Send message
Joined: 13 Feb 12
Posts: 3254
ID: 130544
Credit: 2,455,077,411
RAC: 4,344,791
|
|
Thank you gentlemen! |
|
|
|
|
|
Will there be an announcement/BOINC notice for it? I wouldn't have even known about this if I wasn't part of the PrimeGrid Discord.
____________
1 PPSE, 5 SGS, and 5 GFN-15 primes |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Will there be an announcement/BOINC notice for it? I wouldn't have even known about this if I wasn't part of the PrimeGrid Discord.
Once we're confident it's working. For now, think of it as "early access for the attentive". :)
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
And not bad run times either.
Edit: and lots of factors |
|
|
|
|
|
Does the Sieve benefit from multi-cpu? |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
|
Before anyone asks, I'm guessing 321-Sieve will last about 2 years, with two big caveats:
1) This assumes I didn't make a huge error in the calculations and be off by a factor of 10 or 100.
2) Even if I did it correctly, the calculations are based on a lot of rough estimates, so it's likely to be off by a factor of 2 or more. Realistically, I expect it to last somewhere between 1 and 5 years, with 2 years being the most likely.
EDIT: We started the sieve at p=50T, as of March 20th it's at approximately p=860T, and our rough goal is about p=167P (167000T).
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Does the Sieve benefit from multi-cpu?
Sieves:
Multi-threading is not possible.
Hyper-threading is beneficial. If you have a hyper-threaded CPU, use all of the cores.
(I'm not sure what you meant by "multi-cpu", but hopefully it was one of those two.)
____________
My lucky number is 75898524288+1 |
|
|
|
|
2) Even if I did it correctly, the calculations are based on a lot of rough estimates, so it's likely to be off by a factor of 2 or more. Realistically, I expect it to last somewhere between 1 and 5 years, with 2 years being the most likely.
Noted and thanks! |
|
|
mackerelVolunteer tester
Send message
Joined: 2 Oct 08
Posts: 2652
ID: 29980
Credit: 570,442,335
RAC: 5,621
           
|
|
Very roughly it looks like HT (on -lake CPUs) gives about 30% more throughput than not using it. |
|
|
|
|
Very roughly it looks like HT (on -lake CPUs) gives about 30% more throughput than not using it.
No question HT is the way to go.
On my Skylakes, I have precisely the same performance between 321 Sieve and GCW Sieve but with a nice bonus of about 11% in favour of 321 Sieve with respect to credit. |
|
|
|
|
|
I'm crunching some 321 sieve tasks and noted (or noticed?) that stderr output contains many lines like these:
Unrecognized XML in parse_init_data_file: xxxx
Skipping: nnnnn
Skipping: /xxxx
The tasks finish just fine (no errors).
So I guess it's not something to worry about, right ?
____________
"Accidit in puncto, quod non contingit in anno."
Something that does not occur in a year may, perchance, happen in a moment. |
|
|
JimBHonorary cruncher
Send message
Joined: 4 Aug 11
Posts: 920
ID: 107307
Credit: 989,981,867
RAC: 47,580
|
So I guess it's not something to worry about, right ?
Exactly. |
|
|
|
|
|
When you first turned this back on, the dc rate was almost 100% as if no dc was being done. Now that more users are jumping on it's fallen down some. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
When you first turned this back on, the dc rate was almost 100% as if no dc was being done. Now that more users are jumping on it's fallen down some.
Probably because you were double checking tasks run by admins before it was opened up to the public.
DC is always turned on.
____________
My lucky number is 75898524288+1 |
|
|
|
|
When you first turned this back on, the dc rate was almost 100% as if no dc was being done. Now that more users are jumping on it's fallen down some.
Probably because you were double checking tasks run by admins before it was opened up to the public.
DC is always turned on.
I knew dc was on.. but it was sure nice to see them validate almost immediately. Your explanation makes a lot of sense. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
|
For Windows only, we've release a "new" version of the 321 Sieve app. This is the 1.14 version of the app.
The sieve itself is unchanged. The wrapper, however, is actually a slightly older version of the wrapper. The older wrapper is the same as was used for the TRP and SoB/PSP/ESP sieves. This should fix the problem causing negative time estimates when a task starts.
The Linux and Mac apps are unchanged. They already are using the same wrapper as was used in the TRP and SoB/PSP/ESP sieves.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I have been running 321 Sieve tasks on my PC. When a 321 Sieve task downloads from BOINC, it has a Remaining (estimated) Time of -0d 00:08.08. When I have 321 Sieve tasks in the BOINC Queue, I have very few other PrimeGrid tasks from other Subprojects. When there are no 321 Sieve tasks in the BOINC queue, I have the usual PrimeGrid tasks from other Subprojects. |
|
|
VatoVolunteer tester
Send message
Joined: 2 Feb 08
Posts: 861
ID: 18447
Credit: 880,988,443
RAC: 1,443,058
    
|
|
This has been fixed on Windows by JimB.
Just suspend other tasks to force them to run, unsuspend once they're running, and you shouldn't have this problem again for any new tasks.
____________
 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
I have been running 321 Sieve tasks on my PC. When a 321 Sieve task downloads from BOINC, it has a Remaining (estimated) Time of -0d 00:08.08. When I have 321 Sieve tasks in the BOINC Queue, I have very few other PrimeGrid tasks from other Subprojects. When there are no 321 Sieve tasks in the BOINC queue, I have the usual PrimeGrid tasks from other Subprojects.
Is this still happening with the newer version 1.14 tasks? 1.14 is supposed to fix that problem.
____________
My lucky number is 75898524288+1 |
|
|
|
|
I have been running 321 Sieve tasks on my PC. When a 321 Sieve task downloads from BOINC, it has a Remaining (estimated) Time of -0d 00:08.08. When I have 321 Sieve tasks in the BOINC Queue, I have very few other PrimeGrid tasks from other Subprojects. When there are no 321 Sieve tasks in the BOINC queue, I have the usual PrimeGrid tasks from other Subprojects.
Is this still happening with the newer version 1.14 tasks? 1.14 is supposed to fix that problem.
The problem has been totally fixed on all of my systems. |
|
|
|
|
|
I was finishing up the 1.13 tasks. I received the first 1.14 tasks. The problem is fixed. Thank you!!!! |
|
|
streamVolunteer moderator
Project administrator
Volunteer developer
Volunteer tester
Send message
Joined: 1 Mar 14
Posts: 1051
ID: 301928
Credit: 563,881,725
RAC: 768
 
|
|
Stupid race condition bug, causing crash of Windows sieve wrapper and out-of-bounds memory access on Linux, is still here although it's reason was found in 2016 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Stupid race condition bug, causing crash of Windows sieve wrapper and out-of-bounds memory access on Linux, is still here although it's reason was found in 2016
Noted. We're discussing our options.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Stupid race condition bug, causing crash of Windows sieve wrapper and out-of-bounds memory access on Linux, is still here although it's reason was found in 2016
Noted. We're discussing our options.
Thanks to stream stepping up and rewriting the wrapper (with help from Tern with the MAC builds), we now have a new sr2sieve wrapper, which allows me to announce:
321-sieve 2.00 is live. Same sieve, better wrapper.
Support for 32 bit Macs is officially terminated. We can't build the software anymore. We can't test the software. There's exactly one 32 bit Mac still using PrimeGrid. We'll leave the old (ancient) 32 bit Mac app for 321-sieve running, for now.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
|
More on unsupported old operating systems...
Windows 2000 (W2K), which we officially stopped supporting 5 years ago, will no longer work. We can't build software for it anymore.
Mac O.S. 10.6 and older are no longer supported and will no longer work. We can't build software that will work on anything older than 10.7.
____________
My lucky number is 75898524288+1 |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
|
After eight months, we're at 34.337P. The goal is 167P. If we don't change the goal, and extrapolate that progress, that puts the total run time for the sieve at 39 months, ending in June 2022.
Please take that prediction with a huge grain of salt. Lots of things can change.
____________
My lucky number is 75898524288+1 |
|
|
Ravi FernandoProject administrator
Volunteer tester
Project scientist
Send message
Joined: 21 Mar 19
Posts: 211
ID: 1108183
Credit: 14,576,543
RAC: 11,968
              
|
|
That's June 2022, right? |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
That's June 2022, right?
Correct, and fixed.
____________
My lucky number is 75898524288+1 |
|
|
|
|
|
I was wondering if there is a section of this website that explains nomenclature. Specifically, what does "321_sr2sieve_7124219_1 mean? I know it probably means 3*2^7124219+1, 3*2^7124219-1, or both. Thanks.
____________
|
|
|
Nick
Send message
Joined: 11 Jul 11
Posts: 2301
ID: 105020
Credit: 10,295,298,727
RAC: 38,972,175
                      
|
I was wondering if there is a section of this website that explains nomenclature. Specifically, what does "321_sr2sieve_7124219_1 mean? I know it probably means 3*2^7124219+1, 3*2^7124219-1, or both. Thanks.
I'm reasonably certain that the _1 (or _0) at the end is for the 2 times the work unit is done - first and double-check. I think _0 means first and _1 is double-check. That looks true for LLR anyway.
As for the main number referring to the number used in the calculation - from a look at some results for GFN-16, it seems that the number 7124219 (in your example) is something like a task number - not to do with the number used in the calculation.
Example I am looking at is genefer16_28847739_0
69921942^65536+1 is prime!!!
Someone who has been doing 321 sieve recently may be able to be more certain about the answer |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
I was wondering if there is a section of this website that explains nomenclature. Specifically, what does "321_sr2sieve_7124219_1 mean? I know it probably means 3*2^7124219+1, 3*2^7124219-1, or both. Thanks.
The task name never identifies the numbers being tested. Except for the last part, the names are arbitrary and assigned by us, so they can mean anything we want. For the task you asked about:
321_sr2sieve_7124219_1
"321_sr2sieve" identifies the sub-project, in this case the 321 sieve.
"7124219" is just an index to identify the task in a database table. You would need to look at the contents of that particular database record to see the details of the task. This is not something users can do. Enterprising and inquisitive users can, however, look at the files associated with the task running on their computer and can determine what's being tested in that manner.
"_1", at the end, is an ordinal number that identifies each task in a single workunit. The first task sent out for a workunit is _0, the second is _1, a third, if present, is _3, etc. Since we double check all tasks, there's always at least two tasks, so there's always a _0 and a _1.
I know it probably means 3*2^7124219+1, 3*2^7124219-1, or both.
As mentioned above, it doesn't mean that, but this is even more incorrect than that. You should probably look at the Wikipedia page for Sieve of Eratosthenes to get an understanding of what a sieve does. It doesn't test a single number. It works on all of them at once.
____________
My lucky number is 75898524288+1 |
|
|
Nick
Send message
Joined: 11 Jul 11
Posts: 2301
ID: 105020
Credit: 10,295,298,727
RAC: 38,972,175
|
|
It is Murphy's law (or something like that) that for all the examples of my results I looked at _0 was first.
Soon as I read in your reply that _0 means first sent out, I found a GFN-21:
genefer21_29567176_1 (first)
Edit. I wasn't thinking very clearly. You would need to name the task when sending it out. Doh! |
|
|
JimBHonorary cruncher
Send message
Joined: 4 Aug 11
Posts: 920
ID: 107307
Credit: 989,981,867
RAC: 47,580
|
|
The _0 task is created first (about 1/100th of a second before the _1) but isn't always sent out first. While the feeder loads jobs into the scheduler in creation order, what the scheduler sends out is more random. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
|
Progress update:
Our preliminary goal (subject to change) is a sieve depth of 167P. As of right now, we're just below 42P. We've been running the sieve for a little under 10 months.
Extrapolating those numbers, at the current *average* pace, the sieve would take a total of about 39 months. That puts the end in June of 2022. That's currently the best estimate for how long the sieve will last.
That estimate is really just an educated guess, since it includes assumptions about things that will happen in the future.
____________
My lucky number is 75898524288+1 |
|
|
|
|
Extrapolating those numbers, at the current *average* pace, the sieve would take a total of about 39 months. That puts the end in June of 2022. That's currently the best estimate for how long the sieve will last.
I am eager to see what kind of dent the 1-day challenge later this month puts into the depth sieved. |
|
|
Michael GoetzVolunteer moderator
Project administrator
Send message
Joined: 21 Jan 10
Posts: 14043
ID: 53948
Credit: 481,266,047
RAC: 509,006
|
Extrapolating those numbers, at the current *average* pace, the sieve would take a total of about 39 months. That puts the end in June of 2022. That's currently the best estimate for how long the sieve will last.
I am eager to see what kind of dent the 1-day challenge later this month puts into the depth sieved.
I'll save you the suspense: it will be a very small dent. :)
If we were trying to move the needle, the challenge would be longer.
____________
My lucky number is 75898524288+1 |
|
|
