In yoyo@home I wrote a wrapper arround gmp-ecm. It runs ecm with -chkpnt. This option periodicaly saves the state in phase 1 of the run. Phase 1 is roughly 80% of the total runtime. So during this phase checkpoints are generated.
These checkpoints are used to in restart cases. So if you shoutdown Boinc or your computer or if something crashes and Boinc restarts, the wrapper checks if a checkpoint file exists. If yes, it runs ecm with -resume to resume from the checkpoint.
yoyo

[QUOTE=debrouxl;235172]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 ? :smile:
[/QUOTE]

Actually, your description of the current behavior isn't accurate. In fact, the current behavior appears to be exactly what you're asking for. When the ecmclient program gets one of those signals, it sets a flag, and the next time a curve completes it shuts down in an orderly fashion.

You may be getting confused by what's happening if you're running ecmclient as a foreground job in some shell and you do a Ctrl-C. In such circumstances, the shell sends a SIGINT to the entire foreground process group, so GMP-ECM is getting one as well, causing it to die immediately (and ecmclient to then clean up immediately). But if you send a SIGINT (or SIGTERM or SIGQUIT) to just the ecmclient process (e.g. from some other shell), then you should see the behavior you want.

[QUOTE=rogue;235183]I will be adding support for the GMP-ECM -k option.
[/QUOTE]

??

You already have support for the GMP-ECM -k option (see "gmpecmkvalue" in the .cfg file). But it would be really nice to directly support -maxmem. I've done that for my own use, and it's really nice (Paul L's ECMNet server has lately been handing out P+1 assignments with a B1 of 260e6, and GMP-ECM would otherwise want about 2.5 GB of memory for these). Let me know if you want me to send you my diffs.

@Rogue What is stopping you doing something similar to prpnet?

[QUOTE=jyb;235248]??

You already have support for the GMP-ECM -k option (see "gmpecmkvalue" in the .cfg file). But it would be really nice to directly support -maxmem. I've done that for my own use, and it's really nice (Paul L's ECMNet server has lately been handing out P+1 assignments with a B1 of 260e6, and GMP-ECM would otherwise want about 2.5 GB of memory for these). Let me know if you want me to send you my diffs.[/QUOTE]

I'm sorry. I had that reversed. I added support for -maxmem, not -k, which was already there.

[QUOTE=henryzz;235251]@Rogue What is stopping you doing something similar to prpnet?[/QUOTE]

Specifically what?

There are some fundamental differences between how PRPNet and ECMNet work. I intend to have them share a lot more code with the next release, but I don't think that a database is necessary for ECMNet. Maybe someone disagrees, but I don't see ECMNet servers having as many dedicated clients.

[QUOTE=rogue;235253]Specifically what?

There are some fundamental differences between how PRPNet and ECMNet work. I intend to have them share a lot more code with the next release, but I don't think that a database is necessary for ECMNet. Maybe someone disagrees, but I don't see ECMNet servers having as many dedicated clients.[/QUOTE]
I meant with stopping and starting.
As far as I remember that was a pretty early change in prpnet. I fail to understand how starting llr or pfgw is different to starting ecm.

[QUOTE=henryzz;235254]I meant with stopping and starting.
As far as I remember that was a pretty early change in prpnet. I fail to understand how starting llr or pfgw is different to starting ecm.[/QUOTE]

GMP-ECM didn't always write a checkpoint. If it does now or has the capability to, then I can support it.

[quote=jyb]You may be getting confused by what's happening if you're running ecmclient as a foreground job in some shell and you do a Ctrl-C. In such circumstances, the shell sends a SIGINT to the entire foreground process group, so GMP-ECM is getting one as well, causing it to die immediately (and ecmclient to then clean up immediately). But if you send a SIGINT (or SIGTERM or SIGQUIT) to just the ecmclient process (e.g. from some other shell), then you should see the behavior you want.[/quote]
You're correct, thanks :wink:

[QUOTE=rogue;235253]Specifically what?

There are some fundamental differences between how PRPNet and ECMNet work. I intend to have them share a lot more code with the next release, but I don't think that a database is necessary for ECMNet. Maybe someone disagrees, but I don't see ECMNet servers having as many dedicated clients.[/QUOTE]One of my ideas a while back was to use a proper database behind an ECMNET server. Not so much to support more clients, though that would be a welcome by-product but more to make admin tasks easier.

I'd also make the server multi-threaded or multi-processing. At the moment a single rogue client (ambiguity intentional!) can hang the server, thereby mounting a denial of service to other clients.

Paul

[QUOTE=xilman;235329]One of my ideas a while back was to use a proper database behind an ECMNET server. Not so much to support more clients, though that would be a welcome by-product but more to make admin tasks easier.

I'd also make the server multi-threaded or multi-processing. At the moment a single rogue client (ambiguity intentional!) can hang the server, thereby mounting a denial of service to other clients.

Paul[/QUOTE]

With PRPNet, I added a database and multi-threading at the same time. Doing so with ECMNet should be fairly easy. I was hesitant to make such changes because I didn't see the value. Since you see value in it and are you are one of the bigger users (that I know of), I'll add that for the next release.