Sieving for CRUS

[gd_barnes]

Originally Posted by MisterBitcoin

I almost forgot to tell yoyo about that specific detail on sr2sieve!
I´ll let him know that he should add the -x switch to .abcd files containing more than 25 k´s. That should be an fair value, I guess.

You could tell more than 100 k's. It rarely takes more than ~5 minutes for under 100 k's. But if you think any delay would concern them then maybe 25 k's is better.

[yoyo]

How big is this file uncompressed and compressed if I create it with -c for e.g. 100k's or 500k's and so on?

[gd_barnes]

Originally Posted by yoyo

How big is this file uncompressed and compressed if I create it with -c for e.g. 100k's or 500k's and so on?

If you are talking about the Legendre tables, it varies widely by base and the size of the k's (not always necessarily the number of k's). For ~900 k's for base R381, it was 3.5 GB uncompressed and took 1-2 hours to create! For R411 with ~185 k's, which is the one that MisterBitcoin is working on for you, it was 300-400 MB uncompressed and took about 15 mins. to create, which I think would be manageable for you. I had another base recently with ~270 k's remaining and it only took 5-10 mins. and the table size was < 100 MB. Compressed all files would be about 1/5th to 1/7th that size.

But that was my experience. My machines are slow and only have ~4 GB of memory. Your experience may be faster but I think the table size should be about the same on all machines. It can vary a little by O.S. for the same k's and base.

You can see that there is no set rule on how big they can be based on number of k's. There is only general estimates. Here is what I would suggest: When MisterBitcoin gives you the file for R411, at the command prompt run sr2sieve with the -c switch one time yourself with the following command:
sr2sieve -P ??e9 -c -zz -i sieve-R411-25K-100K.txt

??= just some nominal amount larger than current sieve depth

You will see the Legender tables being created. The -c switch will create a file called sr2cache.bin. Observe the screen as it scrolls through the k's while the tables are being created but do not stop it until it is done with the tables. The sr2cache.bin file will not be created until the tables are done just as the sieving actually begins. At that point you can stop the sieve and see how big the file is. If it's not too big you can zip it and attach it for others to use.

If others use a previously created file they can use the -C (must be upper case) switch and specify the file name of the tables:
sr2sieve -P ??e9 -C sr2cache.bin -zz -i sieve-R411-25K-100K.txt

Doing it this way the sieve will begin almost immediately like you were sieving only 5-10 k's.

Alternative #1 if all of this sounds a little too complicated you can simply use the -x switch, which will not create the tables:
sr2sieve -P ??e9 -x -zz -i sieve-R411-25K-100K.txt

If the -x switch is used the sieve will be a fair amount slower.

Alternative #2: Just have everyone create their own tables if they don't mind waiting for a few minutes before the actual sieving begins.

Here is the benefit to Yoyo with sieving these files with a large number of k's: Because there will be a lot of factors found very quickly the work units can potentially be smaller compared to sieving fewer k's...and that's because our optimum final sieve depth is smaller due to our sieve n-range being smaller; 25K-100K vs. 200K-500K. The drawback is potentially having to mess with these tables. But if you're willing to wait for them to be created the # of factors found very quickly can be very large and so the work units could potentially be smaller.

Perhaps what we can do is let you know ahead of time about how big the file of the tables will be. We cannot specifically send you the file because the file is different for different O.S.'s. I found this out when I tried to use one on a Windows machine that was created by a Linux machine. But...maybe the tables are the same for all Windows machines. So it might not be bad.

[yoyo]

Thanks, you answered my question already if the sr2cache.bin is portable between Windows/Linux/ARM.

[MisterBitcoin]

I suggest I´ll sieve R411 on one of my servers.
For now I wanted to take care on bases with less than 15 k´s remain. Even that will be an massive amount of CPU-years.
I still have some resources to finish this, it will take some weeks until I got an nice sieve depth.

[gd_barnes]

Originally Posted by MisterBitcoin

I suggest I´ll sieve R411 on one of my servers.
For now I wanted to take care on bases with less than 15 k´s remain. Even that will be an massive amount of CPU-years.
I still have some resources to finish this, it will take some weeks until I got an nice sieve depth.

If it just you sieving, don't sieve R411 deeply. BOINC can test it a lot faster than you can sieve it and doesn't care much if it's undersieved. Just sieve it to P=1T or something like that. I've seen them test n=25K-100K ranges that have only been sieved to P=100G.

That said, if we can easily sieve deeply with Yoyo then we should. But if it's a big hassle or requires a lot of one person's resources then we should not.

For R411 if you don't think Yoyo would care to work on the file, I feel like P=1T is reasonable.

[Felix]

when someone could build me a batch file and an understandable instruction, i could sieve sth for you

[gd_barnes]

Reserving R675 and R431 for sieving n=25K-100K.

[gd_barnes]

Reserving R495 for sieving n=25K-100K.

[gd_barnes]

R675 sieving is complete for n=25K-100K.

[MisterBitcoin]

Admin edit: Moved from another thread. This is reference base S606 testing reservation:

sieve file done in 3-4 days. Hope you still wait for it, as its reserved.