CADO NFS

[VBCurtis]

I don't know how I would test to answer that question.

Also, it may be that I updated from Ubuntu 18.04 to 20.04 some time between building the May '20 version and the newer ones, so gcc version may have changed.

I think I have a remote machine still on 18.04; I'll try building the current GIT there and see if I get similar problems.

[charybdis]

Originally Posted by VBCurtis

I don't know how I would test to answer that question.

Use git checkout [revision] to revert the files (don't do this with your main CADO installation!), then run make as usual. You can find the list of revisions here. Try revisions shortly before and after the lingen update, say 5c9a47f1 and e7ef93d8.

[bur]

Ok, so if I don't specify --parameters, then it will use the ones in ./parameters/factor/ ? Then the bug is fortunately just an inconvenience, but nothing dramatic, I will replace the stock files with VBCurtis ones and omit --parameter.

Or, what happens when you put one of my params files into the parameters/factor folder (renamed to replace the default one)?

It doesn't matter which files are there, I just cannot specify --parameters.

I will report the problem at https://gitlab.inria.fr/cado-nfs/cado-nfs/-/issues. Are there any files/logs that I can include?

[charybdis]

Originally Posted by bur

I will report the problem at https://gitlab.inria.fr/cado-nfs/cado-nfs/-/issues. Are there any files/logs that I can include?

The preferred method for reporting issues is to use the mailing list, which you can sign up to from this page.

It would be a good idea to attach the main logfile, which should be called something like c110.log. For this specific bug, it would also be useful to give details of the contents of the "client" directory inside the workdir, and to attach client/localhost.work/localhost.log if it exists.

[bur]

Ok, I'll gather everything and post it there. Thanks for the help.

[bur]

I startet a C133 yesterday evening and now 12 hours later I find it has produced these messages for the last 6 hours:

Info:Linear Algebra: lingen ETA: not available yet

top shows all cores fully utilized including hyperthreading. No files other than c135.log were changed since Linear Algebra started.

Is that normal behavior? Especially the lack of an ETA makes me suspicious. I'm not sure about the expected ETA of a C133 on that system (i9-10900) though.


Apart from that, since hyperthreading tends to increase power consumption strongly, is there a way to tell cado-nfs not to make use of it? I started with -t 10 but apparently that isn't sufficient.

[bur]

I had mprime running at the same time with one worker/thread. As soon as I stopped that, LA continued normally. I have no idea what happened, since mprime was using one core and cado-nfs the remaining ones. I could even reproduce the behavior with a c105.

[VBCurtis]

Originally Posted by bur

I startet a C133 yesterday evening and now 12 hours later I find it has produced these messages for the last 6 hours:

Info:Linear Algebra: lingen ETA: not available yet

top shows all cores fully utilized including hyperthreading. No files other than c135.log were changed since Linear Algebra started.

Is that normal behavior? Especially the lack of an ETA makes me suspicious. I'm not sure about the expected ETA of a C133 on that system (i9-10900) though.


Apart from that, since hyperthreading tends to increase power consumption strongly, is there a way to tell cado-nfs not to make use of it? I started with -t 10 but apparently that isn't sufficient.

See post 502 and the replies for the lingen bug.

[charybdis]

Originally Posted by bur

I had mprime running at the same time with one worker/thread. As soon as I stopped that, LA continued normally. I have no idea what happened, since mprime was using one core and cado-nfs the remaining ones. I could even reproduce the behavior with a c105.

mprime hogging the memory bandwidth, perhaps??

Come to think of it, CADO can't have been the only process running on the cluster when I encountered the bug (see post 504). I'd say this is worth a report to the mailing list, CADO shouldn't be so easily derailed by other processes.

[bur]

mprime hogging the memory bandwidth, perhaps??

With just one thread? And it wasn't just slowed down, no usable output was produced in 6 hours despite cado using 1800 % CPU (9 cores + HT). I could understand if cado had no CPU usage, but that was strange.

Btw, some time ago I asked about a verbose setting for cado, I now found out you can use tasks.verbose=1 to make cado execute all tools with the -v switch. Also in the workdir there are lots of *.stdout.* files that contain interesting output about current progress. I think these could be redirect live to display.


cado continues to work fine besides these small issues, I'm currently doing a c153 with vbcurtis' parameters. It seems to me far less time is spent on poly selection than yafu/ggnfs does, is that so?

[charybdis]

Originally Posted by bur

With just one thread? And it wasn't just slowed down, no usable output was produced in 6 hours despite cado using 1800 % CPU (9 cores + HT). I could understand if cado had no CPU usage, but that was strange.

I don't use mprime myself so I was just speculating as to the cause. But whatever the reason, CADO shouldn't be doing that.

It seems to me far less time is spent on poly selection than yafu/ggnfs does, is that so?

Yes. Partly a product of CADO polyselect being more efficient than msieve CPU polyselect, but also I believe the amount of time that yafu allocates for polyselect is processor-independent, so if your processors are particularly fast then proportionally more time will be spent on polyselect.