MisterBitcoin, I have completed R411 to n=25K. With 182 k's remaining, there are fewer remaining than any other base currently tested to only n=25K. I have started a sieve for n=25K-100K to a very small sieve depth of P=1G. The file is attached in ABCD format. Can you have Yoyo sieve it to some reasonable depth so that BOINC can eventually test it? Thanks. :smile:

[QUOTE=gd_barnes;478695]MisterBitcoin, I have completed R411 to n=25K. With 182 k's remaining, there are fewer remaining than any other base currently tested to only n=25K. I have started a sieve for n=25K-100K to a very small sieve depth of P=1G. The file is attached in ABCD format. Can you have Yoyo sieve it to some reasonable depth so that BOINC can eventually test it? Thanks. :smile:[/QUOTE]
Pmax is set to 10e13 and it is sent to YOYO. But dont expect it before one month:since there is 92 sequences in queue now :smile:

[URL]http://www.rechenkraft.net/yoyo/y_status_sieve.php[/URL]

[QUOTE=pepi37;478746]Pmax is set to 10e13 and it is sent to YOYO. But dont expect it before one month:since there is 92 sequences in queue now :smile:

[URL]http://www.rechenkraft.net/yoyo/y_status_sieve.php[/URL][/QUOTE]

OK thanks. That is fine. By the way, when you say 10e13, do you mean 1e13 or 1e14? Either one is good with me.

[QUOTE=gd_barnes;478752]OK thanks. That is fine. By the way, when you say 10e13, do you mean 1e13 or 1e14? Either one is good with me.[/QUOTE]

I´ve told yoyo to not put it into the queue now, it is only tested up to 1G!
I will sieve it to an other P-value in order to prevent yoyo@Home users from extreme long running WU´s.
More tests means more runtime, thats why R2 took over 1 day at ARM!

[QUOTE=MisterBitcoin;478782]I´ve told yoyo to not put it into the queue now, it is only tested up to 1G!
I will sieve it to an other P-value in order to prevent yoyo@Home users from extreme long running WU´s.
More tests means more runtime, thats why R2 took over 1 day at ARM![/QUOTE]

ARM?
You cannot stop users to use weak CPU, and ARM is weak, extremely weak compared to any modern CPU. Butt, those kind of members is also in very low number compared to all other users that do sieving. And last: if WU is not return in deadline it recycled immediately. So dont stop project because few users.

[QUOTE=pepi37;478783]ARM?
You cannot stop users to use weak CPU, and ARM is weak, extremely weak compared to any modern CPU. Butt, those kind of members is also in very low number compared to all other users that do sieving. And last: if WU is not return in deadline it recycled immediately. So dont stop project because few users.[/QUOTE]

Those tasks can, and will, run way faster if I remove more canidates NOW.
ARM was an examble. Try it out: Run 12T up to 12,05T with an version removed canidates from 1G up to 50G and an version without removed canidates from that range.
There will be an noticeable speed-up from about 10-15%! :smile:
(That counts for all types of CPUs anyway.)

My apologies. Yes that was a quick sieve to P=1G. I could have easily sieved it to P=10G (Would that be enough?) but I just figured that Yoyo could do it a lot faster. I also could have just handed over a k's remaining file to you and suggested that you do the initial sieve. I guess I found the worst way in between the two extremes. :-(

Since I'll likely have a few more of these this year, in the future for an n=25K-100K file, what depth should I sieve it to for Yoyo to get started on it? Or would you prefer that I just post a k's remaining file and have you take it from there?

[QUOTE=gd_barnes;478798]My apologies. Yes that was a quick sieve to P=1G. I could have easily sieved it to P=10G (Would that be enough?) but I just figured that Yoyo could do it a lot faster. I also could have just handed over a k's remaining file to you and suggested that you do the initial sieve. I guess I found the worst way in between the two extremes. :-(

Since I'll likely have a few more of these this year, in the future for an n=25K-100K file, what depth should I sieve it to for Yoyo to get started on it? Or would you prefer that I just post a k's remaining file and have you take it from there?[/QUOTE]

It´s okay. I started the sieving right after I noticed your post yesterday. I´ll sieve it to 150G, since yoyo@home has an quite large queue.
There is also no experience with so much k´s for yoyo with sr2sieve. I want to be 100% sure that this implementation works without any problems.

For the future you can also upload the files on the RKN slack "sieving" thread, I´ll take them deeper if needed.
I still can´t give you exact values, for bases with <250 remain k´s 25G should be okay. >250 and <500 k´s I think 50G should work.

[QUOTE=MisterBitcoin;478805]There is also no experience with so much k´s for yoyo with sr2sieve. I want to be 100% sure that this implementation works without any problems.[/QUOTE]
Just an observation (I don't really know what you are doing here, so if I say some stupid or unrelated stuff, forgive me).
In my experience (i.e. R66), sr2sieve is getting much slower when you deal with lots of k's, because the time to compute the tables is then comparable with the time to sieve. You should keep the number of k's in a chunk low enough to have the time for computing those tables not larger than 3-5% of the total sieving time (iirc).

Misterbitcoin, LaurV has a good point. For R411 on my machine, it took about 15-20 minutes to create the Legendre tables when using sr2sieve for the ~180 k's. You can save off one of the tables (with your first run of sr2sieve) with the -c switch but that only helps if you decide to run it a second time. You can then use the -C (upper case) switch to almost immediately load the tables upon a second run. But this only helps if someone at Yoyo is running it a second time or on more than one core.

The time taken to create the tables can vary widely. It's mostly instantaneous if there are fewer than 10 k's remaining. For R66 they would be so large that it would be impractical to use them. In that case sr2sieve with the -x switch is the way to go. It prevents the creation of the tables. It's much slower sieving than if the tables are created but is still much faster than srsieve.

The tables can be huge! Their size can vary widely even for the same number of k's. It seems to be base-specific. I had a base recently that had ~900 k's remaining at n=2500. I went to run sr2sieve on it for n=2500-10K and found that the tables took 1-2 hours to create and their size was ~3.5 GB! This did not work on that particular machine with only 4 GB of memory. So I ended up using sr2sieve with the -x switch. As a comparison R411 with ~180 k's remaining had a Legendre tables size of ~300-400 MB.

It's just something to keep in mind. The Yoyo folks might become annoyed if they have to wait too long for their sieve to start. They might not mind 15-20 minutes but if it takes an hour or more and it sucks up most of their memory on a machine that might not be good.

Good point!
I use -x an every base with more than 100 k´s remain, because it´s taking some time to build them.
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. :smile:

I know that point, LaurV. I mean I "produced" the sieve files for Base S66. :max:
I´ll find a way to sieve such big bases soon. :) It will be an very short sieving range, which also means lots of lots WU´s.
Looking forward.
Greetings from my Workplace, LOL.