[QUOTE=VBCurtis;451348]For a single k, use sr1sieve?[/QUOTE]

Yes. sr2sieve is build to deal more k´s.

[QUOTE=MisterBitcoin;451347]Taking R867 to nmax=1M. Using the "old" srsieve to avoid any problems.[/QUOTE]
[QUOTE=VBCurtis;451348]For a single k, use sr1sieve?[/QUOTE]
[QUOTE=MisterBitcoin;451349]Yes. sr2sieve is build to deal more k´s.[/QUOTE]
That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) [B]srsieve[/B], not knowing that you should only sieve low n values with [B]srsieve [/B]and then switch to [B]sr1sieve[/B] which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):
[CODE]srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
# and observe

[B]awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg[/B]

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine...
# ... but you have to know how/what you are doing
[/CODE]

[QUOTE=Batalov;451350]That's not what VBCurtis meant.
He meant "Are you trying to sieve with (old or whatnot) [B]srsieve[/B], not knowing that you should only sieve low n values with [B]srsieve [/B]and then switch to [B]sr1sieve[/B] which is many times faster?"

In fact one should sieve like follows (pay attention to the middle step which removes 25% of candidates and makes next step faster):
[CODE]srsieve -g -n200000 -N1000000 -P1e6 "8*867^n-1"
# optional:
# awk 'NF==2 {print $2%3}' t17_b867_k8.npg | sort | uniq -c
# and observe

[B]awk 'NF!=2 || $2%3!=0' t17_b867_k8.npg > t17_b867_k8.A.npg[/B]

sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
sr1sieve -t 4 -P 1e13 -i t17_b867_k8.1e11.npg -o t17_b867_k8.1e13.npg

# even more optimal is to sieve ranges on 1 CPU each, then combine...
# ... but you have to know how/what you are doing
[/CODE][/QUOTE]

I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.]

[QUOTE=MisterBitcoin;451351]I always sieve to 50M using srsieve, not deeper. After sieving to this value sr1sieve catches the factors.

[Its not my first sieve I´m doing. I probably misunderstood Curtis.][/QUOTE]

neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.

[QUOTE=VBCurtis;451354]neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.[/QUOTE]

Once the kinks are worked out of the newest srsieve, it will eliminate those terms.

[QUOTE=VBCurtis;451354]neither old srsieve nor sr1sieve is going to remove the perfect-cube-minus-1 composites. Are you ignoring Batalov's awk advice because you already knew to remove those candidates, or did you not understand the importance of his point?

If the power is a multiple of 3, then the number is composite (because 8 is also a 3rd power). This is precisely the point Batalov has been trying to make all week- the tools as CRUS uses them miss these algebraic factors, so you should remove them yourself (with Batalov's script, or via fancy awk as he wrote it).

Serge- Thanks for the awk tip, and for translating my too-short post about sr1.[/QUOTE]


Oh, your talking about algebraic factors...............I´ll check with the script.
Your reply was so confusing, just say what you want.
Sry that I falsely understand it, I should stop sieving until all problem solved.

:sad:

[QUOTE=Batalov;451350]
sr1sieve -t 4 -P 1e11 -i t17_b867_k8.A.npg -o t17_b867_k8.1e11.npg
[/QUOTE]

When you use -t 4 what is slowdown comparing to t 1 * 4 instances?

For me on R3, -t 4 is just a bit faster than 3 instances of single-threaded. So, about 20% wasted for convenience. But that's on a hyperthreaded machine; ubuntu doesn't schedule awesomely, so even with 6 tasks running it sometimes doubles up tasks on a single core whilst leaving another core idle.

That info is same for me- one instance gives me 53Mp/s but t 4 gives me 169 Mp/s

R867 finished to p=50T. File attached.

As I stated there are a lot of under sieved files for single-k Bases.
Reserving S406 (1k) from n=200K to N=1M. planned pmax=50T

[QUOTE=MisterBitcoin;451849]R867 finished to p=50T. File attached.[/QUOTE]

1157 algebraic factors removed
corrected sieve file attached