Thanks Jason, I'll let you know after the next few updates.

I have had reports of errors when the script is terminated early. With the many versions of Python and the many OS's around it is proviing very hard to track this bug down.

But I now have a tentaitive update that seems to work better on my system. However, I need help from peoplle running Python 2.6.x, 2.7.x and 3.x.x on both Windows and Linux to test it. This requires starting a job and repeatedly stopping and starting it during both the polynomial selection and lattice sieving steps to see if it behaves itself.

I would be most grateful if anyone is willing to do this sort of test and report any issues here. This TENTATIVE new version is attached. I DON'T recommend upgrading to it unless you are willing to do some testing or endure errors. But your help will be much appreciated.

Python - 3.1.2
10 interrupts while running Polyselect stage - passed
Sieve stage - failed.
It just gets stuck in the end of first sieve loop.
Terminating and restarting yields the same result. Always.
Also, when it gets stuck, I observe no CPU usage, so it's really stuck:smile:

Thanks for trying it Karl. Can you please try the attached version?

Haha, this worked perfectly. 10 interrupts and resets on polyselect and sieving phase, and the script successfully coped with each. I did not interrupt the combining, matrix solving or sqrt steps.

Thanks Karl - I hope we see some more tests from peolle running on other systems.

You are welcome! In case this matters - Python v3.1.2(like I said above) is installed on Win7 x64 with SP1.

That is interesting since we are using the same OS but different versions of Python. Are you using a 32 or 64 bit Python - I am using an x64 version of Python 3.2

I have been looking at the ggnfs siever code and I now think that a lot of the problem in script termination is caused by its use of a now somewhat outdated setjmp/longjmp method for termination. I am going to have a look at changing this (at least on WIndows).

I have looked at the ggnfs siever options in its C code and I find "-N num" for a processor identifier and "-n" for catching signals. But factmsieve.pl (and hence factmsieve.py) uses "-n num" for setting the processor identifier and doesn't set for catching signals. So it might not be surprising that I am having trouble with signals.

Am I missing something here?

[QUOTE=Brian Gladman;264254]Are you using a 32 or 64 bit Python - I am using an x64 version of Python 3.2[/QUOTE]
64 bit Python. Native variant.

The siever parameters are OK - Chris Monico combined the -N and -n parameters so that -n sets signaal catching as well as setting the processor ID. But running the siever independently of the script shows that termination is very hit and miss because memory allocation sometimes gets screwed up after a setjmp/longjmp call. So there is not much the script can do about this.

[QUOTE]The POLY_MIN/MAX_LC values do have defaults so you don't have to play with them. But if the polynomial serach seems too short in time, just increase the POLY_MAX_LC value.[/QUOTE]Are there any rules of thumb for how much time should be spent doing polynomial selection? I increased POLY_MAX_LC all the way to 200000 and it still only took ~15 minutes to complete, as compared to 15 hours for lattice sieving. This was on a number that maybe would have been better factored by SNFS: (1729783277^17-1)/81164773774053707518382800588 (SNFS size 158).