ECMNet Feature Requests

[jyb]

Originally Posted by xilman

I do it slightly differently, in that I use different directories but identically the same config files for each client.First create the directories (I call them cl1, cl2, ..., cln) and in one of them create a config file. Then hard link to that config file to the same name in each of the other directories.

Second create a shell script which contains lines:

#! /bin/sh
cd /path/to/cl1
/path/to/ecmclient &
cd /path/to/cl2
/path/to/ecmclient &
cd /path/to/cl3
/path/to/ecmclient &
...
cd /path/to/cln
/path/to/ecmclient &

Third, run the shell script. Because the config files are hard linked together, editing any one immediately ensures that all the others are changed at the same time.

If you wish, you could get clever and write the script as a loop which runs from 1 to $1, thereby starting a user-selected number of clients. but I couldn't be bothered. If you wanted to get really clever, you could write a script (probably easier in Perl than sh) which writes customized config files in each directory, creating the directory if required. Again, I couldn't be bothered but if there's interest I could write one easily enough.

Paul

That all sounds rather hideous. Having to have separate directories in the first place is just ridiculously annoying. With the changes I detailed above, I can run any number* of clients out of the same directory, and all their log and work files can be in one place and easily identified. Plus, each running client can have a different ID, which is impossible if you're hard-linking the config files such that they're all the same. So if the server notifies me that I found a factor, I don't have to search in order to know which client found it.

And yes, I use a script to fire off a bunch of clients. But it's very simple because it doesn't need to cd anywhere.

*When I say any number, I really mean it. My home directory is shared by many machines via NFS, so I may have upwards of 80 cores each running its own copy of the client, all from the same directory.

[Xyzzy]

I'm open to other ideas. Please post them here.

A Debian package would be very useful, perhaps integrated into the existing GMP-ECM package.

[rogue]

Originally Posted by Xyzzy

A Debian package would be very useful, perhaps integrated into the existing GMP-ECM package.

I have absolutely no clue how to do such a thing.

[xilman]

Originally Posted by jyb

That all sounds rather hideous. Having to have separate directories in the first place is just ridiculously annoying.

Horses for courses. It works well for me.

Paul

[jyb]

Originally Posted by xilman

Horses for courses. It works well for me.

Paul

Oh, I don't doubt it. And please excuse the unnecessarily critical tone of my last post; I didn't intend it as such. With the right script it certainly doesn't require much work to start/stop a bunch of clients.

But every time you want to add new client don't you have to make yet another directory and yet another hard link? It was this management that I was referring to as annoying. And don't all clients end up with the same ID? I grant that that's not particularly onerous, I just think that the changes I detailed above make the client much more usable, with no drawbacks that I can see.

[rogue]

I have decided to modify the client to take a -id argument. This will be used to override the clientid in the cfg file. This clientid will be appended to the file name to maintain uniqueness.

[Xyzzy]

I have absolutely no clue how to do such a thing.

http://wiki.debian.org/HowToPackageForDebian

There are many links similar to that one.

Debian packages can be used on Debian, Ubuntu and several other Linux systems. Basically it is just a wrapper that configures things and installs them.

We like that we can take a new Debian box and, as root, run:

aptitude install gmp-ecm

And then it is installed. Our next command (after we relinquish root privileges) can run ECM.

[debrouxl]

Currently, sending the ecmclient program either SIGTERM, SIGINT or SIGQUIT, stops the current curve immediately, before it completes.
What about adding another signal, such as SIGUSR1, for a delayed shutdown (including communication with the server) after the current curve completes ?

EDIT: and, since you're removing support for sbfactor, what about affecting the "memorytouse" parameter to GMP-ECM (-maxmem <n>) ?

[rogue]

Originally Posted by debrouxl

Currently, sending the ecmclient program either SIGTERM, SIGINT or SIGQUIT, stops the current curve immediately, before it completes.
What about adding another signal, such as SIGUSR1, for a delayed shutdown (including communication with the server) after the current curve completes ?

EDIT: and, since you're removing support for sbfactor, what about affecting the "memorytouse" parameter to GMP-ECM (-maxmem <n>) ?

I will be adding support for the GMP-ECM -k option.

As for SIGUSR1, I don't know. Note that the ECMNet client does not link with GMP-ECM, but rather runs it via the system() function. My understanding is that both GMP-ECM and the ECMNet client get the signal, thus the client cannot control how GMP-ECM responds to that signal.

[wreck]

I don't know if it is possible, but GMP-ECM is not convient to pause,
especially using B1 very large such as 26e7 or 85e7 and after running 2 hours and press Ctrl-C the result will be lost.

And I use ECMNet about four years before, it always give me thousands of curves each time, but I have to shut down my computer each day, so is it possible to let the ECMNet client run less than 3 hours for each work unit.

I notice yoyo@Home split each curve to about 4 steps something like
ecm -save temp1.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp1.out -save temp2.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp2.out -save temp3.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp3.out -save temp4.out 11e7 -maxmem 1024 <in.num >>result.out
Is it possible to use this technical in ECMNet?

[rogue]

Originally Posted by wreck

I don't know if it is possible, but GMP-ECM is not convient to pause,
especially using B1 very large such as 26e7 or 85e7 and after running 2 hours and press Ctrl-C the result will be lost.

And I use ECMNet about four years before, it always give me thousands of curves each time, but I have to shut down my computer each day, so is it possible to let the ECMNet client run less than 3 hours for each work unit.

I notice yoyo@Home split each curve to about 4 steps something like
ecm -save temp1.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp1.out -save temp2.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp2.out -save temp3.out 11e7 -maxmem 1024 <in.num >>result.out
ecm -resume temp3.out -save temp4.out 11e7 -maxmem 1024 <in.num >>result.out
Is it possible to use this technical in ECMNet?

There is the "frequency" option in the client to control how long between communications to the server. Are you referring to processing of curves that take more than a few hours per curve, so that you can start today and continue tomorrow or something like that.