ECMNet Feature Requests

[rogue]

Originally Posted by jyb

I didn't ask about hitting ^C, I asked about sending a SIGTERM to the ecmclient process. Hitting ^C causes a SIGINT to be sent to all processes in the foreground process group, which would ordinarily include the GMP-ECM process as you say, but that's not what I'm talking about.

This has already been covered earlier in this thread. See post #24. As far as I can tell, sending a SIGTERM (or SIGINT) to *just the ecmclient process* has exactly the behavior you're going for with stopasapoption.

That might be true on *nix (I'm not an expert on *nix signals), but not on Windows . Remember that this code also has to run on Windows and Windows doesn't have *nix signal handling.

[jyb]

Originally Posted by rogue

That might be true on *nix (I'm not an expert on *nix signals), but not on Windows . Remember that this code also has to run on Windows and Windows doesn't have *nix signal handling.

Fair enough. I can't claim any expertise on (or even passing knowledge of) how these things work in Windows. Is there really no way to do the equivalent of sending a signal to just the ecmclient process? My reading of the code, even for Windows, is that ecmclient behaves exactly the same way as I described. It's just a question of what the ecm process will do.

[rogue]

Originally Posted by jyb

Fair enough. I can't claim any expertise on (or even passing knowledge of) how these things work in Windows. Is there really no way to do the equivalent of sending a signal to just the ecmclient process? My reading of the code, even for Windows, is that ecmclient behaves exactly the same way as I described. It's just a question of what the ecm process will do.

Windows uses a "control handler", which is similar to *nix signal handler. In code you specify a routine to get control when a user does something, such as closing the window of the parent process or killing via the Task Manager. I don't differentiate between the different types of events in code.

To me the important thing is that the software behaves in a simple, predictable fashion and that a user has some ability to control the software's behavior without understanding the code behind it. I won't preclude anyone from using SIGTERM, but I doubt that it would be the preferred method for users to shutdown the client. FYI, out of habit I never rely on software to handle SIGTERM cleanly. Maybe I'm paranoid, but that is me. I do rely on software to handle SIGINT correctly.

[rogue]

I was merrily testing today when I realized that I hadn't written a piece of code that is needed: the recursive factoring of composites co-factors. I wrote the code, but then I wondered if I designed the tables optimally. I pose a question to you, the users of the ECMNet server to get you opinions.

Should I treat the new database similar to the current ini file, where connection between composite co-factor and original composite is lost (if you don't consider that the prefix of the composite co-factor name is the same as the original composite name) or should I continue to track the original composite and treat each factor as a child to that composite?

This is the first option would look like in the database:

composite a
   factor a-1
   factor a-2

composite a-1
   factor a-1-1
   factor a-1-2

composite a-1-2
   factor a-1-2-1
   factor a-1-2-2

...

This is the second option would look like in the database:

composite a
   factor a-1
   factor a-2
   factor a-3
   ...
   factor a-n

Both have distinct advantages. The first is similar to the 2.x design. The second allows one to easily see all factors for a composite. The first requires the server to track work for all composites and their composite co-factors. The second requires the server to track work only for the original composite.

I'm personally leaning toward the second option because it makes more logical sense.

Opinions?

[wblipp]

I seldom use automatic recursive factorization, so my opinion should be given low weight. I prefer option 2.

William

[xilman]

Originally Posted by wblipp

I seldom use automatic recursive factorization, so my opinion should be given low weight. I prefer option 2.

William

I always use automatic recursive factorization. Given that my scripts for keeping things tidy are going to have to change anyway, it doesn't really matter to me which option you choose. The second looks more aesthetically pleasing.

Paul

[rogue]

Okay, that is what I will do. It will cost me some time and delay the release.

[rogue]

Does anyone care about "difficulty"? The difficulty is computed as the total work done * (decimal length^2). You can set up a strategy to order work by difficulty, with less difficult numbers to be factored before more difficult numbers.

Note that there is already a means to order work selection by total work and one to order work selected by decimal length. This would be a carry over from 2.x. There will be no means to order work selection by b1, as it is presumed that total work should be sufficient. Total work is computed by sum(b1 * ECM curves for b1) for all b1.

Opinions?

[wblipp]

Originally Posted by rogue

Does anyone care about "difficulty"? The difficulty is computed as the total work done * (decimal length^2). You can set up a strategy to order work by difficulty, with less difficult numbers to be factored before more difficult numbers.

I use difficulty a lot - usually 60-90% in the configuration. I like the resulting spread of much more work for smaller numbers.

[xilman]

Originally Posted by rogue

Does anyone care about "difficulty"? The difficulty is computed as the total work done * (decimal length^2). You can set up a strategy to order work by difficulty, with less difficult numbers to be factored before more difficult numbers.

To the best of my knowledge, I've never ordered by "difficulty". Below is the portion of the current ecmserver.cfg if that helps you understand my approach.

// strategy0 - random
// strategy1 - by lowest B1 that needs curves done and total work done
// strategy2 - by total work done
// strategy3 - by difficulty
// strategy4 - by length and total work done
//strategy0=20:20:0:0:0
strategy0=00:20:0:0:0
//strategy1=80:20:0:0:0
strategy1=100:20:0:0:0
strategy2=0:20:0:0:0
strategy3=0:20:0:0:0
strategy4=0:20:0:0:0

The two commented lines are my other standard approach and are left there so that changing between the alternatives doesn't require any thinking and, more important, less likely to incur typos.

To be honest, I've never used any complex strategies during my entire experience of running your code. The last three have always had 0:20:0:0:0 and the last three figures on every line have never been anything other than 0:0:0. I'm a bear of very little brain and those things confuse me.

Paul


Paul

[xilman]

Originally Posted by rogue

Okay, that is what I will do. It will cost me some time and delay the release.

Thanks, but please don't let my tastes delay a release. I'm happy to wait for recursive factorization on the assumption that it won't be too difficult for me to implement recursion by manual modifications to the database.

Paul