CLLR Bug

[LaurV]

I found an interesting bug in CLLR. I have a series of .prp files coming from sieving, all about a thousand lines long, in the right (pfgw) format. They are for different bases and contain different thingies inside, so they can not be combined in a single file. Therefore, I launch cllr with the (dos) command:

> for %p in (*.prp) do cllr64 -d -oStopOnSuccess=1 %p

This works perfectly as long as I do not find any prime (and I am always happy with a single prime per file). The command goes through all files with .prp extension, in sequence; for people who are not fans of old dos batches, it is equivalent with the series of commands (assuming I put all in a batch file):

>cllr64 -d -oStopOnSuccess=1 file1.prp
>cllr64 -d -oStopOnSuccess=1 file2.prp
>cllr64 -d -oStopOnSuccess=1 file3.prp
...etc

but it is more convenient if i have a thousand such files.

The problems start when I find a prime. Because the cllr makes its ini file in which it saves the current line number in the current prp file, when a prime is found (say at line 600 in the file1.prp) than the job is done, and cllr moves to file2.prp, etc., but it continues the second file from line 601 !!!

It took me a while to find out what happens. The "PgenOutputFile=" and "PgenInputFile=" lines (and other lines) in the .ini are rewritten with the new files, but the "PgenLine=" is not, and the beginning of the second file up to the line PgenLine (600 in the example) is skipped.

This doesn't happen if no prime is found in a file; in this case work completed is set to 1, and the ini file is completely rewritten when the base (file) is changes, so the second file is tested from the first line (as it is supposed to be).

At least PFGW is more clever in this direction, as it makes a checksum of the current line, and if there is no match, it starts from scratch. This is very good in case some stupid thing happens (like me editing the file, deleting it, PEBCAK, or whatever). Some work may be doubled if the user doesn't know what he is doing, but no work is skipped, like it just happened to me right now, skipping a prime (2*1487^36432-1) which should have been found few days ago.

[Batalov]

CLLR likely inherits this bug from LLR.

If plain LLR is started in a folder with existing llr.ini which has PgenLine=63 (for example) and WorkDone=0, then it will continue from line 63 even if you change the name of the file. This should be corrected in both programs.

(Also, if you edit or completely replace the file, a similar thing will happen. This one is a more subtle bug - we can call it a feature. You cannot fix that without checksums.).

Workarounds: One solution is to remove llr.ini after each run. This can be undesirable if you have some special options set (error check or FFTIncrement or other); in this case, you can have a master llr.ini with only persistent options and copy it over from master location before each LLR launch.

[LaurV]

Originally Posted by Batalov

you can have a master llr.ini with only persistent options and copy it over from master location before each LLR launch.

...or use a lot of -oOption=value switches, if you want to keep all in a single line command (like I wanted, to be able to write it down every time, and not put it in a file which I will forget how to call, if it has parameters, etc, hehe, actually you are a genius! You gave me the idea! Thanks!)

I found out that the -o overwrites physically the correspondent lines in the ini file, so I just modified my command line into:

>for %p in (*.prp) do cllr64 -d -oStopOnSuccess=1 -oPgenLine=0 %p

and now it works perfectly, every time a job is finished, with or without success, the incriminated line is overwritten and the next file starts from scratch.

Call it a feature...

Test case (it runs in about 2 minutes all together, you need srsieve.exe and cllr64.exe in the folder or accessible in the path):

Preliminary, a batch file called testsieve.bat (or 3 individual commands):

srsieve -p 2 -P 1e9 -S 2 -n 2 -N 1e3 -m 1e7 -G "2*67^n-1"
srsieve -p 2 -P 1e9 -S 2 -n 2 -N 1e3 -m 1e7 -G "2*152^n-1"
srsieve -p 2 -P 1e9 -S 2 -n 2 -N 1e3 -m 1e7 -G "2*284^n-1"

Not working (one prime missed):

for %p in (*.prp) do cllr64 -d -oStopOnSuccess=1 %p

rename lresults.txt into lresults.bad (to avoid overwriting)

Working (no primes missed, correct ini file):

for %p in (*.prp) do cllr64 -d -oStopOnSuccess=1 -oPgenLine=0 %p

Compare the two lresult files.

edit: of course, in that case you have to take care what files and what lines from the last-worked file you delete when you resume (like when the work was interrupted by electricity break, whatever). Otherwise you will involuntarily do all the work again from scratch (but this is not a problem anymore for me - of course, it should be better if this "little feature" is fixed, but for now, I can handle it).

[pepi37]

Maybe it is not irrelevant, but one option that remove processed candidate from prp file will be good one.I am sure many of us will use such feature and it not be too hard to implement. ( like Prime95 do)

[Jean Penné]

Hi,
Now, if the input file name (PgenInputFile parameter) has changed while working with the same .ini file, the PgenLine parameter is forced to one.
I made this update to fix the "CLLR bug" found by LaurV.
I think it will be satisfactory.
Regards,
Jean