CADO NFS

[Dubslow]

Originally Posted by xilman

I noticed long since. In fact I had a discussion with the dev team about the switch.

Silence may be golden but it's not necessarily an indication of ignorance.

May be

What was the discussion about? A link, perhaps?

[xilman]

Originally Posted by Dubslow

May be

What was the discussion about? A link, perhaps?

Had to dig through the mail archives. There seems to have been several discussions.

One from November 2013 concerned putting system-constant headers (machine whitelists, thread numbers, etc) into a system.py and the factorization-dependent material into a separate file, both to be included by ecmfactor.py

Another is best summarized by

On Sat, 2013-11-23 at 01:13 +0100, Alexander Kruppa wrote:

>
> The parameter files in the param/ directory are for the old Perl script, which we kept around as a legacy in 2.0. The parameter files for the Python script are in params_py/. By using the params.c131 file from that directory, it should work. This fact clearly needs to be documented better, and the error message when required parameters are missing in the parameter file could be a lot more descriptive.

Doh! I feel quite stupid now. Clearly I'm getting hard of thinking in
my old age.

Thanks Alex.

And a third from a month earlier concerned a bug in cadotask.py

(I .cc PZ, he may be interested in this)

Oh. This is a limitation severe enough that it qualifies as a bug. I generate workunit names by concatenating the project name, the name of the task (such as "sieving") and the range (such as "1000000-1010000"), where the three pieces are separated by the underscore. I need to be able to parse the workunit name again later, which means splitting it into three pieces again. To ensure that this is possible uniquely, no underscore may appear in the project name. However I realize now that this was a poor choice, as underscore is used way too commonly to be restricted like this.

I think I will change it so that the split will happens only at the *last* two underscores in the workunit name; this way any underscores in the project name are ignored, and the other two parts (task name and range string) are generated by cadofactor.py itself so it is easy to guarantee that no underscore occurs among them.

[EdH]

I know this thread is old, but it is specifically titled!

I am just now taking an interest in this package. Is this a good place for questions or would it be better to work via email at the site?

If interested, some background:

I have a set of scripts that allow me to distribute sieving across several machines and have set up mpi in the past, but even with Gigabit switches, once I moved past Pentium 4s, the LA couldn't be distributed efficiently. Additionally, I had scripts that distributed poly searches, although the effectiveness was questionable.

I would like to try to set up CADO-NFS across several LAN connected machines, all of which currently communicate among themselves via SSH.

I see that CADO-NFS uses http, so I "assume" Gigabit isn't required and as soon as I can figure out the little pieces, I expect I can work intraLAN-wise.

However, ATM, I have CADO-NFS running successfully (as far as factoring) on an i7 with 4 cores and 2 threads/core, but have not been able to get more than 2 cores/threads involved. I am using a parameter file (a modified copy of parameters), and have set tasks.threads=8, 4, 2 with no success, or even change. I've also tried -t 8 on the command line.

I have read through all the READMEs, this thread and several months of archives at the site, but the understanding part is still quite limited.

My current call, which does succeed, but with only 2 cores/threads:

./cado-nfs.py mathparameters

Via top, the machine "appears" to be running 2 cores with 2 threads per core. I see this in my terminal:

Info:root: No database exists yet
Info:Database: Opened connection to database /tmp/work//test_run5.db
Info:root: tasks.polyselect.threads = 2
Info:root: tasks.sieve.las.threads = 2
Info:root: Command line parameters: ./cado-nfs.py mathparameters

Thanks for any assistance...

[VBCurtis]

Ed-
I should be able to help you via this thread. Are you using 2.3.0, or the current git repository? Most of my experience is with 2.3.0, though I have 3.0.0-beta via git on at least one machine also.

On my setup, the main machine ("server", and place where the postprocessing will run) is invoked with:

./cado-nfs.py b.c132 --client-threads=2 --server-threads=8

The param file b.c132 includes these lines:
server.whitelist = 169.254.0.0/16, 138.23.[my office IP]/16, 66.215.[my home IP]/16
server.ssl = no
server.port = [I choose the same 5-digit number for every job]
slaves.hostnames = localhost
slaves.nrclients = 4

My clients, which consist of 3 machines connected via LAN; my office machine, and my home machine, can all contribute to the job via this command:

./cado-nfs-client.py --server=http://[servername].local:[the 5-digit number you chose above for server port]

.local is for the LAN machines.

You should be able to run the client command from your i7 to add threads, if for some reason the initial job refuses to use more than 4. This is nice for varying dynamically the number of threads a CADO job uses; start the main process with 4, and run a client or two in other terminal windows to use 6 or 8 as desired.

[EdH]

Thanks Curtis,

I actually considered PM'ing you, but chose this thread.

I am using 2.3.0. I thought I'd get that running and a little experience before heading for the latest.

I'm tied up (figuratively) for a few hours, but hopefully I can play this evening.

A few verifications/questions for now:

slaves.nrclients - should this be the maximum I'll allow or the expected number I'll run for the current instance?

client-threads - If I have 4 core single thread machines as clients, would I use 2 or 4 and if 2, then do I run two instances on the client?

If I do have clients running, do they have to be started and stopped for each different run of the server, or can they simply sit idle between jobs, waiting for the next server project?

Ed

[VBCurtis]

Ed-
Slaves.nrclients is the number of child processes the CADO server runs on the machine localhost. Those aren't visible or controlled by you in any way once started, so consider it a minimum number to be running for the entire job. This setting has nothing to do with the number of client processes that may connect, on localhost or via your LAN (or, for that matter, the open internet if so whitelisted).

CADO docs indicate all processes are best run two-threaded at minimum; so a 4-core not-hyperthreaded machine (or a HT i3 two-core) would run two clients of two threads each. I believe client-threads = 2 is default, but I happen to have that in my invocation because I run client-threads = 3. I believe you can leave it off and everything will run two-threaded. I would run two instances of the cado-nfs-client.py window on each 4-core contributing machine.

Clients will idle between jobs; the default is to look for work every 10 seconds, but I'm sure that can be altered. However, when a job finishes sieving the server tells the client it is no longer needed, and the client exits out to terminal. The idle behavior is useful when you kill a server (for instance, to change parameters) and fire it back up within a few minutes; the clients will just idle and connect to the new job when it's available.

[VBCurtis]

Originally Posted by VBCurtis

You should be able to run the client command from your i7 to add threads, if for some reason the initial job refuses to use more than 4. This is nice for varying dynamically the number of threads a CADO job uses; start the main process with 4, and run a client or two in other terminal windows to use 6 or 8 as desired.

This part is misrepresented: When I said "start the main process with 4", I should have said "set slaves.nrclients to 2 in order to use 4 threads minimum, then fire up cado-nfs-client.py instances to add more pairs of threads to use 6 or 8 as desired."

[EdH]

Thanks Curtis,

I seem to have the server running properly, but am still working on getting a client up and running. Actually, I just got a client online and I tried running it with the client invocation you gave. It couldn't communicate using the name so I tried the static ip. That time it "almost" worked, but the two machines got into an argument and the server "threw up its arms and quit!"

Error:Lattice Sieving: Program run on math24.97d94eca failed with exit code 1
Error:Lattice Sieving: Stderr output follows (stored in file /tmp/work/test_run9.upload/test_run9_sieving_3894000-3896000#2.vbo2b3pv.stderr0):
b"download/las: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.0' not found (required by download/las)\ndownload/las: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by download/las)\ndownload/las: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by download/las)\ndownload/las: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by download/las)\n"
Error:Lattice Sieving: Exceeded maximum number of failed workunits, maxfailed=100

The client went to idle.

I'll probably have to leave it for tonight and take a fresh look tomorrow. Have I failed to set some directories or install something? Am I missing the sievers?

Possibly of note, the client OS is Debian (on which I had to install Python3), and the server is Ubuntu. Tomorrow, if able, I will try to install the program on another Ubuntu i7 and see if it makes a difference.

On a different note:

Am I correct in thinking the polyselect is distributed as well as sieving? Is LA distributed also? If not, How large a number should I be able to handle with 12GB of RAM? (I might be able to increase that to 16GB, if necessary.)

Ed

[Dubslow]

https://askubuntu.com/questions/4216...2-14-not-found

How old is that Debian client?

[VBCurtis]

Originally Posted by EdH

On a different note:

Am I correct in thinking the polyselect is distributed as well as sieving? Is LA distributed also? If not, How large a number should I be able to handle with 12GB of RAM? (I might be able to increase that to 16GB, if necessary.)
Ed

Polyselect is distributed, and also multi-threaded; it will use precisely the same resources as sieving (well, less memory). The postprocessing steps are not distributed; they run only on the host/server machine. Memory use is higher than msieve, but I haven't run a job larger than low 140s yet so I don't have a firm idea of how it scales or whether GNFS-170 will fit into 12GB. My guess is that you're good into the 160s with 12GB, but maybe not 170s.
I'm running GNFS-139 now with I=13, with each siever instance taking ~500MB virt ~250MB res according to "top". I=14 means 4x the memory use per instance, so 1GB minimum. I'm not sure I'll be running an I=15 job unless we do a group-job in the 180s.

[EdH]

Originally Posted by Dubslow

https://askubuntu.com/questions/4216...2-14-not-found

How old is that Debian client?

Ancient!

OK, my Ubuntu i7 jumped right in and is working along, although, oddly, the ETA has not changed on the server.

I watched as I added four threads to fully occupy the client and none of the additions affected the ETA. The terminals were affected, in that as I added another terminal, all the others appeared to slow down. hmmm...

BTW, I had missed the ".local" portion of the address for my local machine, so now it is working by name.

Thanks for all th help. I'll play a bit and see where it leads me.