PrimeGrid
Please visit donation page to help the project cover running costs for this month

Toggle Menu

Join PrimeGrid

Returning Participants

Community

Leader Boards

Results

Other

drummers-lowrise
1) Message boards : Sieving : BOINC Seiving - Preferences (Message 6979)
Posted 5063 days ago by Aaron FinneyProject donor
I only want to Sieve Cullen work. (or I only want to Sieve Woodall's)

Please allow for me to differentiate between the two.
2) Message boards : Sieving : Sieving Discussion (Message 6829)
Posted 5075 days ago by Aaron FinneyProject donor

x86-64 Linux: gcwsieve-1.0.20 (~2X faster than 32 bit)
x86 Linux: gcwsieve-1.0.18
x86 Windows: gcwsieve-1.0.18


version 1.0.20: 64 bit only



Why no 64-bit Windows app?
3) Message boards : Cullen/Woodall prime search : What are Cullen numbers good for? (and woodalls?) (Message 6513)
Posted 5099 days ago by Aaron FinneyProject donor
What (exactly) could cullen and woodall numbers be used for?

Are there uses for these numbers or is this just a mathematical timesink?
4) Message boards : Sieving : Sieving Discussion (Message 6506)
Posted 5099 days ago by Aaron FinneyProject donor
I've noticed that the name of the sieve file changes each day. Does that mean that it's a whole new sieve file, or just that it's renamed?

I kind of liked the previous naming scheme for the sieve file--it tells you right in the name what the current sieving depth is.

Not daily...but it has been frequent these past few days. This file will last at least a week or so.

Yes, it's a whole new sieve file...minus the returned factored n to date. Since sieve time is related to the # of n remaining, it makes sense to remove n from the sieve file to speed the sieve up.

I agree, the previous naming convention was nice and I liked it. However, it wasn't completely accurate. Outstanding ranges prevented the naming convention from including all completed ranges.

For example, currently the highest the sieve could be right now is p=320G for the Cullen 2M range. However, all the ranges between 330G-505G are completed. Calling the new sieve file cullen2M_p320G.txt would not be completely accurate...and leaving out the factors in the completed ranges would not be efficient.

So the current naming convention is sieve file, date created, and # of candidates remaining. I'll add a "mostly sieved to" section to the post...maybe that will help.

Any suggestions on how to improve this is greatly appreciated.


I think that using the date for the sieve file name is much more preferable than the original nomenclature, as sieving may be completed and returned out of sequence.
5) Message boards : Sieving : Sieving Stats? (Message 6287)
Posted 5115 days ago by Aaron FinneyProject donor
Are there stats for Sieving? lol
6) Message boards : Sieving : Questions about sieving process.. (Message 6260)
Posted 5118 days ago by Aaron FinneyProject donor
So then, to *FIRST* sieve 110M-140M, and then going back and sieve (for the first time) 0-110M using the sieve file from 110M-140M would be improper?

Case in question :
current sieve file and corresponding gcwsieve-command-line file: woodall10M_p170Gplus520G.zip (291767 candidates remaining at p=170G including 200G-520G factors)

Yet, 192-200G has not been sieved yet... I'm not understanding why the results from the 200G-520G sieve are being removed from the list of candidates for 192-200G....?

We are working with one master sieve file, Woodall10M (2000000<n<10000000), and running factor ranges against it. As we run factor ranges (p; example 200G-520G or 200000000000-520000000000) it removes candidates (n) from the master sieve file in which sieving finds factors for.

Since p=200G-520G was already completed, I decided to remove the candidates (n) in which factors were found, from the master sieve file...so the sieve would run faster. 11033 candidates (n) were removed from master file Woodall 10M which represented about 4% decrease in candidates.

edit: factor ranges 192G-200G will still find factors for the remaining n.


So... ok.. it doesn't really matter what order they are removed in, those numbers are discarded.. it's the remaining numbers that we really care about, correct?

(sorry, I know very little about what we're doing here, I just wanted to help out cuz this is 'the boincstats co-project')
7) Message boards : Sieving : Questions about sieving process.. (Message 6257)
Posted 5118 days ago by Aaron FinneyProject donor
So then, to *FIRST* sieve 110M-140M, and then going back and sieve (for the first time) 0-110M using the sieve file from 110M-140M would be improper?

Case in question :
current sieve file and corresponding gcwsieve-command-line file: woodall10M_p170Gplus520G.zip (291767 candidates remaining at p=170G including 200G-520G factors)

Yet, 192-200G has not been sieved yet... I'm not understanding why the results from the 200G-520G sieve are being removed from the list of candidates for 192-200G....?
8) Message boards : Sieving : Questions about sieving process.. (Message 6253)
Posted 5118 days ago by Aaron FinneyProject donor
1. Am I right in assuming that you are looking for lowest possible p for a given n, or is there only one possible combination, or does the p even matter? If lowest, then I am confused as to why the woodall sieve has been sieved with so high a p before the low range p was sieved...? Won't you miss lower p's for the n's? - Or am I misunderstanding the goal entirely, and that's not to identify the p's at all, it's merely to remove the n's from the sieve file once a possible p is discovered?

2. Does the Sieve time per p decrease slightly with each factor discovered? (and subsequently smaller sieve file..)
9) Message boards : Number crunching : Note to project participants. (Message 6244)
Posted 5118 days ago by Aaron FinneyProject donor
I recall a bug in one version of the client when the 'Maintain enough work for an additional x days' preference was first introduced that caused it to over-request work by a very large factor. But this has since been fixed in the latest versions.


Stick with 5.10.7, the problem is only appearing in later versions AFAIK.
10) Message boards : Number crunching : Note to project participants. (Message 6213)
Posted 5124 days ago by Aaron FinneyProject donor
Please keep your queue low when attached to this project.

I discovered a new bug with the BOINC software this evening when connected to projects that give large amounts of work to connected clients.

Basically, the larger the queue you have in your system the more CPU time that boinc takes up trying to update the queue. Eventually (depending on your system) boinc and boinc manager will take up 100% of the CPU time updating themselves and no scientific work can get through because boinc and boinc manager have higher priority levels.

PLEASE keep your queue low for now if you attach to this project and are using a client that supports the 'GRID LAYOUT'. Even if you don't have the grid layout open or displayed boinc will take up 100% of the CPU time.

Try to keep less than 50 tasks in your queue at all times until this bug is fixed, and you can avoid having your credit stolen by BOINC.


Next 10 posts
[Return to PrimeGrid main page]
DNS Powered by DNSEXIT.COM
Copyright © 2005 - 2021 Rytis Slatkevičius (contact) and PrimeGrid community. Server load 6.26, 4.41, 3.88
Generated 29 Jul 2021 | 2:24:08 UTC