[QUOTE=japelprime;609801]I notice trouble with the ^ sign for me in batch file. Maybe this error outcome is regarding my wrong format for k*b^n+c but I am not sure what is wrong when the output file is not the same as input.
command promt shows -s k*21964-1 (without powerfaktor ^) but my batch file is written with k*2^1964-1[/QUOTE]

Caret (^) is an escape character in .cmd or .bat batch files, try doubling it.

[QUOTE=japelprime;609801]I notice trouble with the ^ sign for me in batch file. Maybe this error outcome is regarding my wrong format for k*b^n+c but I am not sure what is wrong when the output file is not the same as input.
command promt shows -s k*21964-1 (without powerfaktor ^) but my batch file is written with k*2^1964-1

Command prompt:
C:\EB\Prime\mtsieve\fbncsieve_minus_1964>fbncsieve.exe -s k*21964-1 -k 1 -K 4000000 -P 10e14 -o remaining_faktors_prufa.txt
fbncsieve v1.4, a program to find factors of k*b^n+c numbers for fixed b, n, and c and variable k
Fatal Error: sequence must be in form k*b^n+c where you specify values for b, n and c[/QUOTE]

The ^ symbol is like an escape characters on the Window command line. You can either use -s k*2^^1964+1 or -s "k*2^1864+1".

Give me advice :)
If I run srsieve1 then I got this
[QUOTE]sr1sieve145.exe -i b.txt -o b.txt -P 600000000000000 -f factors.txt
sr1sieve 1.4.5 -- A sieve for one sequence k*b^n+/-1.
Read 14081 terms for 4*395^n+1 from NewPGen file `b.txt'.
sr1sieve 1.4.5 started: 500026 <= n <= 999994, 500000000000000 <= p <= 600000000000000
p=500002651324609, 44403358 p/sec, 0 factors, 0.0% done, 0 sec/factor, ETA 15 Aug 14:50[/QUOTE]If I run latest srsieve2 (posted before few days) on six core CPU (utilization near 96%)
[QUOTE]srsieve2 -P 600000000000000 -W6 -w2500000 -i b.txt -o b1.txt -f B -O factors.txt
srsieve2 v1.6.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with single sequence c=1 logic for p >= 500000000000000
BASE_MULTIPLE = 30, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720
Split 1 base 395 sequence into 40 base 395^180 sequences.
Legendre summary: Approximately 1 B needed for Legendre tables
1 total sequences
1 are eligible for Legendre tables
0 are not eligible for Legendre tables
1 have Legendre tables in memory
0 cannot have Legendre tables in memory
0 have Legendre tables loaded from files
1 required building of the Legendre tables
518400 bytes used for congruent q and ladder indices
259200 bytes used for congruent qs and ladders
Sieve started: 5e14 < p < 6e14 with 14081 terms (500026 < n < 999994, k*395^n+1) (expecting 75 factors)
[COLOR=red]p=500016415279873, 7.969M p/sec[/COLOR], no factors found, 0.0% done. ETC 2022-07-24 19:14[/QUOTE]

And last , latest version of srsieve2cl. I use sieve file from CRUS page , sequence 4*395+1. I use countless combination of commands to get GPU work, without any success. Max speed I get is same as using 6 core GPU.
[B]GPU utilization is always 0 % [/B]. So please be kind , use same sieve as I , and run it on your GPU, and then post what commands you use to utilize GPU to work.
[QUOTE]mtsieve2022>srsieve2cl -P 600000000000000 -W 6 -g 10 -D 1 -d 0 -i b.txt -o b1.txt -f B -O factors.txt
srsieve2cl v1.6.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with single sequence c=1 logic for p >= 500000000000000
BASE_MULTIPLE = 30, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720
Split 1 base 395 sequence into 40 base 395^180 sequences.
Legendre summary: Approximately 1 B needed for Legendre tables
1 total sequences
1 are eligible for Legendre tables
0 are not eligible for Legendre tables
1 have Legendre tables in memory
0 cannot have Legendre tables in memory
0 have Legendre tables loaded from files
1 required building of the Legendre tables
518400 bytes used for congruent q and ladder indices
259200 bytes used for congruent qs and ladders
Sieve started: 5e14 < p < 6e14 with 14081 terms (500026 < n < 999994, k*395^n+1) (expecting 75 factors)
Increasing worksize to 160000 since each chunk is tested in less than a second
Increasing worksize to 2560000 since each chunk is tested in less than a second
[COLOR=red]p=500031657619723, 7.727M p/sec,[/COLOR] no factors found, 0.0% done. ETC 2022-07-24 21:51
CTRL-C accepted. Threads will stop after sieving to 500045438037643
Sieve interrupted at p=500045438037643.
CPU time: 1015.75 sec. (22.17 sieving) (5.83 cores) [COLOR=Red][B]GPU time: 0.00 sec.[/B][/COLOR]
14081 terms written to b1.txt
Primes tested: 1342496000. Factors found: 0. Remaining terms: 14081. Time: 174.24 seconds.[/QUOTE]

-W is for CPU workers. -G is for GPU workers. If you do not specify -W then it will not use a CPU worker to find factors.

Also note that the p/sec rates are computed differently. You can see that srsieve2cl will finish weeks earlier than sr1sieve for the same range.

It is possible that the calculation of time spent in the GPU is incorrect. You can use Windows Task Manager (Performance tab) to see how heavily it is using the GPU.

Based upon Task Manager's GPU utilization you should adjust -G/-g.

srsieve2cl -P 600000000000000 -G 5 -g 100 -D 1 -d 1 -i b.txt -o b1.txt -f B -O factors.txt
works on [COLOR=Red]version 1.6.2[/COLOR] and give me speed of 4.351M p/sec, GPU utilization 99%
On same settings 1.6.3 give me error
[QUOTE]srsieve2cl -P 600000000000000 -G 5 -g 100 -D 1 -d 1 -i b.txt -o b1.txt -f B -O factors.txt
srsieve2cl v1.6.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n
Sieving with single sequence c=1 logic for p >= 500000000000000
BASE_MULTIPLE = 30, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720
Split 1 base 395 sequence into 40 base 395^180 sequences.
Legendre summary: Approximately 1 B needed for Legendre tables
1 total sequences
1 are eligible for Legendre tables
0 are not eligible for Legendre tables
1 have Legendre tables in memory
0 cannot have Legendre tables in memory
0 have Legendre tables loaded from files
1 required building of the Legendre tables
518400 bytes used for congruent q and ladder indices
259200 bytes used for congruent qs and ladders
GPU primes per worker is 563200
Sieve started: 5e14 < p < 6e14 with 14081 terms (500026 < n < 999994, k*395^n+1) (expecting 75 factors)
OpenCL Error: Out of resources
OpenCL Error: Out of resources
in call to clEnqueueWriteBuffer
argument: babySteps[/QUOTE]

[QUOTE=pepi37;609924]srsieve2cl -P 600000000000000 -G 5 -g 100 -D 1 -d 1 -i b.txt -o b1.txt -f B -O factors.txt
works on [COLOR=Red]version 1.6.2[/COLOR] and give me speed of 4.351M p/sec, GPU utilization 99%
On same settings 1.6.3 give me error[/QUOTE]

"Out of resources" implies that -g or -G is too high or that -D or -d are pointing to the wrong GPU.

If you have a single GPU, I suggest not using -G at all, but adjust -g. Use -h to list the platforms and devices. Most likely you will not want to change -D or -d.

[QUOTE=rogue;609925]"Out of resources" implies that -g or -G is too high or that -D or -d are pointing to the wrong GPU.

If you have a single GPU, I suggest not using -G at all, but adjust -g. Use -h to list the platforms and devices. Most likely you will not want to change -D or -d.[/QUOTE]


Same settings on same card WORK on 1.62 without any problem.
So 1.63 is problematic, or give me error, or just exit after few seconds.


I have 3 GPU, one is intel , integrated and second and third card are Nvidia 1660 Super with 6 GB DDR6
Settings are point to "second" Nvidia

[QUOTE=pepi37;609927]Same settings on same card WORK on 1.62 without any problem.
So 1.63 is problematic, or give me error, or just exit after few seconds.


I have 3 GPU, one is intel , integrated and second and third card are Nvidia 1660 Super with 6 GB DDR6
Settings are point to "second" Nvidia[/QUOTE]

How many primes per GPU worker in 1.6.2 vs 1.6.3?

[QUOTE=rogue;609931]How many primes per GPU worker in 1.6.2 vs 1.6.3?[/QUOTE]


In both case same


GPU primes per worker is 563200

Not certain why 1.6.3 would behave differently. Can you reduce -g and try again?

The srsieve BOINC output format mask (i.e. the 257 or 258) is incompatible with LLR versions in the 4.0.x series. Jean added a new meaning for the 0x100 bit in LLR 4.0.0 that makes those sieve files process the 2[I]k[/I]*[I]b[/I]^[I]n[/I]-3 form as well. The correct values should be 1 or 2, respectively, though I did bring this up in the LLR thread in the event Jean wants to revert the change. The bit was undocumented in the LLR readme, so I don't know if he dug it out of NewPGen or somewhere.