CADO NFS

[bur]

It seems to have to do with the params file. I sucessfully factored a C89 with the c90 of VBCurtis. But when I switched to a C112 or C138 with the respective params.c110 or params.c140 file I run into the problem.


Since it's getting late here I just started the C138 without any --parameter, which works. Any idea what could cause the error? I checked file attributes and they are the same as for the other files. Also your params.c90 is working for some reason.

[EdH]

This would be an extremely long shot, but make sure "--server" hasn't sneaked into the params file. That keeps clients from running on the host, but I think there would be an indication.

I'm guessing since it runs for other factorizations, that /etc/hosts has:

127.0.0.1   localhost

but. you might give that a quick look.

[bur]

Now it seems that as soon as I specify a --parameters file, it hangs. No matter if it is stock or VBCurtis. If I don't use --parameters it works. Do the warnings mean anything problematic?

$ ./cado-nfs.py --workdir=workdir --parameters parameters/factor/params.c90 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000031
Info:root: No database exists yet
Info:Database: Opened connection to database c90.db
Info:root: Set tasks.linalg.bwc.threads=10 based on detected physical cores
Info:root: Set tasks.threads=20 based on detected logical cpus
Info:root: tasks.threads = 20 [via tasks.threads]
Info:root: tasks.polyselect.threads = 2 [via tasks.polyselect.threads]
Info:root: tasks.sieve.las.threads = 2 [via tasks.sieve.las.threads]
Info:root: tasks.linalg.bwc.threads = 10 [via tasks.linalg.bwc.threads]
Info:root: tasks.sqrt.threads = 8 [via tasks.sqrt.threads]
Info:root: Command line parameters: ./cado-nfs.py --workdir=workdir --parameters parameters/factor/params.c90 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000031
Info:root: If this computation gets interrupted, it can be resumed with ./cado-nfs.py workdir/c90.parameters_snapshot.1
Info:HTTP server: Using non-threaded HTTPS server
Info:Lattice Sieving: param rels_wanted is 0
Warning:Complete Factorization / Discrete logarithm: Parameter tasks.filter.merge.keep = 100 was not used anywhere
Warning:Complete Factorization / Discrete logarithm: Perhaps you meant one of the following ?
Warning:Complete Factorization / Discrete logarithm:   tasks.polyselect.polyselect.keep ?
Warning:Complete Factorization / Discrete logarithm:   tasks.filter.purge.keep ?
Warning:Complete Factorization / Discrete logarithm: (If you wish to set all of these consistently, you may set tasks.keep)
Info:Complete Factorization / Discrete logarithm: Factoring 1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000031
Info:HTTP server: serving at https://florian-Precision-3640-Tower:8001 (0.0.0.0)
Info:HTTP server: For debugging purposes, the URL above can be accessed if the server.only_registered=False parameter is added
Info:HTTP server: You can start additional cado-nfs-client.py scripts with parameters: --server=https://florian-Precision-3640-Tower:8001 --certsha1=a737ab528d15c4a41ecdd0dcd60d6f97f0713979
Info:HTTP server: If you want to start additional clients, remember to add their hosts to server.whitelist
Info:Polynomial Selection (size optimized): Starting
 Info:Polynomial Selection (size optimized): 0 polynomials in queue from previous run

I have

127.0.0.1      localhost
127.0.1.1      florian-Precision-3640-Tower

in /etc/hosts. As you can see from the cado output, it uses the florian-... host. I am not 100% sure of the distinction between the two IPs, but both seem fine and changing one to the other didn't solve the problem.

[bur]

Originally Posted by charybdis

I think this could be a manifestation of this bug that was introduced by revisions 0cb1e01c and f15ee502 in November. It caused clients to die immediately and silently with certain versions of Python, and I don't think it was ever fully fixed, because I kept getting the bug with Python 3.5.2 even after the supposed fix. Never got round to talking to the developers about it.

Try building an old revision - perhaps 6605b6e4, the last one before the bug was introduced - and see if you still have problems.

I have Python 2.7.18, since the bug report talks about 3.6 and you mention 3.5.2 can it be the case?


If so, how do I build older revisions? I found git checkout 6605b6e4, but I don't think that automatically downloads these files.

[charybdis]

Originally Posted by bur

I have Python 2.7.18, since the bug report talks about 3.6 and you mention 3.5.2 can it be the case?


If so, how do I build older revisions? I found git checkout 6605b6e4, but I don't think that automatically downloads these files.

python (aka Python 2) and python3 are not the same thing. You almost certainly have both installed, but you checked the version number of python when cado-nfs.py uses python3 (although I believe the clients use python too).

In any case, I don't think my bug is the same as yours, because I saw the bug whether I specified a parameter file or not.

git checkout 6605b6e4 does download the files; it only downloads the ones that have changed, hence the much faster download time. You'll need to re-run make too. I would make a new cado-nfs directory for each version rather than having a potentially confusing mix of files.

[bur]

python3 -V reports 3.8.5, so I think that rules out the bug you experienced.

I had run make after checkout before posting, no luck. Then per your advice I built it in a new directory, still hanging as soon as I use --parameters.



Where could I report such a problem? Or is there a debug info or similar I could look for? error.log is empty.


If I don't specify --parameters, which parameters are used, the ones in parameters/factors/? And is cado then still considered faster than ggnfs?

[EdH]

The cado-nfs/parameters/factor directory holds all the params.cxx(x) files for the GNFS runs. They are chosen based on the size of the candidate, e.g. params.c120 covers the sizes 118 through 122. params.c90 has examples and info for all the possible options.

Just out of curiosity, what would happen if you tried using --parameters <default file>?

[VBCurtis]

Or, what happens when you put one of my params files into the parameters/factor folder (renamed to replace the default one)? I've always just replaced the stock files with the new ones; if you like, rename the stock ones instead of overwriting them.

Anyone else have a bug where lingen takes more time than sieving for small (under 115 digit) inputs? I can't figure out if it's a setting interacting badly with recent versions (my May2020 version never does this), or if it's a bug that isn't related to params.

[charybdis]

Originally Posted by VBCurtis

Anyone else have a bug where lingen takes more time than sieving for small (under 115 digit) inputs? I can't figure out if it's a setting interacting badly with recent versions (my May2020 version never does this), or if it's a bug that isn't related to params.

Had this happen when I got a rare opportunity to run CADO on a 144-thread cluster. As I've never seen it otherwise, I assumed it was some sort of scheduling issue, perhaps to do with how the task is distributed across multiple sockets.

[VBCurtis]

Hrm... it's happening on my single-socket 12-core, even when I invoke CADO 2- or 4- threaded. I considered maybe I was setting matrix too sparse, returned my params to factory for filtering + LA but that didn't help.

I haven't had it happen yet above 125 digits, but it's nearly every time on 100-105.

[charybdis]

There was a big update to lingen in September. Is this what sets it off?