mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Factoring (https://www.mersenneforum.org/forumdisplay.php?f=19)
-   -   2801^79-1 reservations (CLOSED 27 AUGUST) (https://www.mersenneforum.org/showthread.php?t=13305)

Batalov 2010-06-09 01:15

[quote=richs;217862]I was wondering if someone would kindly give me some advice. I am sieving 60M-61M and was about 69% complete when I noticed that the siever had not incremented over the past few hours. I shut down the siever with control-C.

The number in .last_spq0 is 60690713. How do I restart without losing what I have done so far? I already backed up .last_spq0 and 2801_79.out (my output file).
[/quote]
1. If it had been a BSOD or planned restart, then you could probably repeat the last command line and add -R to the end of it. Backup the output file but leave it in this directory as well (because -R scans the file).
1a. Your binary may not know -R option; then indeed override -f and -c as suggested above; and get a newer one from Jeff's site.
2. However, if the progress report had not incremented (and the computer was not swapping), then it could have been stuck in an infinite loop. What kind of a binary was it? Some binaries are patched for this, old ones are not, but there's another consequence for you - it may get stuck again, on the same value.
3. So, if it starts and gets stuck again, kill it and increase the -f value beyond the "stuck" special_q. Note: the "stuck" q=... on the screen is the previous special_q! The next primes are 60690727 and 60690733. If it get stuck on 60690727, proceed to next, etc. Even old binaries get stuck on one q perl many million, so you will probably not hit another loop.

Tell us later, how it proceeded. -Serge

[COLOR=green]P.S. The 64-bit binary didn't get stuck. Here's the number of relations for some next spq0's:[/COLOR]
[COLOR=green] 29 60690713
30 60690727
33 60690733
45 60690739
40 60690757
8 60690761
27 60690779
43 60690781
37 60690787
37 60690803[/COLOR]

richs 2010-06-09 01:15

Thanks, apocalypse. Looks like I'll have two output files which I assume should not be a problem.

richs 2010-06-09 01:44

The binary was svn374-win32-p4 downloaded mid-May.

Here's what happened since I wasn't sure of the syntax for using -R:

C:\Program Files\GGNFS>gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60690713 -c 309287 -R
Resuming with -f 60999629 -c 371
Warning: lowering FB_bound to 60999628.
^C
C:\Program Files\GGNFS>gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60690713 -c 309287
Warning: lowering FB_bound to 60690712.

I had already made a back-up of the output file. Since the program started at 60999628, I knew that I had the -R syntax incorrect, so I stopped and restarted as shown. I will end up with two output files for this range.

Thanks for the advice since I am just learning how this works.

mdettweiler 2010-06-09 04:34

[quote=richs;217870]The binary was svn374-win32-p4 downloaded mid-May.

Here's what happened since I wasn't sure of the syntax for using -R:

C:\Program Files\GGNFS>gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60690713 -c 309287 -R
Resuming with -f 60999629 -c 371
Warning: lowering FB_bound to 60999628.
^C
C:\Program Files\GGNFS>gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60690713 -c 309287
Warning: lowering FB_bound to 60690712.

I had already made a back-up of the output file. Since the program started at 60999628, I knew that I had the -R syntax incorrect, so I stopped and restarted as shown. I will end up with two output files for this range.

Thanks for the advice since I am just learning how this works.[/quote]
I belive what you need to do for -R is to use the original -f and -c parameters:

gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60000000 -c 1000000 -R

That should then automatically scan the file, pick up where it left off and continue to the end of the range. (Disclaimer: I haven't actually tried this. The last time I used a ggnfs siever standalone, i.e. outside of factmsieve.pl/py, was before the -R feature was implemented and thus I had to use the "old fashioned" resume method that you're using now. Someone else with more experience should be able to confirm whether what I suggested is correct.)

Mini-Geek 2010-06-09 12:39

[QUOTE=mdettweiler;217885]I belive what you need to do for -R is to use the original -f and -c parameters:[/QUOTE]

Yep, this is right. :smile:

Andi47 2010-06-09 13:37

[QUOTE=mdettweiler;217885]I belive what you need to do for -R is to use the original -f and -c parameters:

gnfs-lasieve4I15e -r 2801_79.poly -o 2801_79.out -f 60000000 -c 1000000 -R

That should then automatically scan the file, pick up where it left off and continue to the end of the range. (Disclaimer: I haven't actually tried this. The last time I used a ggnfs siever standalone, i.e. outside of factmsieve.pl/py, was before the -R feature was implemented and thus I had to use the "old fashioned" resume method that you're using now. Someone else with more experience should be able to confirm whether what I suggested is correct.)[/QUOTE]

I have done this quite often and it works like you said. For me it has always worked. (the only times it had failed turned out to be input errors, i.e. a typo in the command line or when I accidently typed "-a" when it should have "-r", or vice versa.)

If the last line of the output file is truncated (that happens quite often), an error message like "Warning: incomplete line. If it's just a few, it's ok, they will be skipped". This is nothing to worry about, as long as you don't get hundreds of these messages.

chris2be8 2010-06-20 19:02

Reserving 137M-139M.

Chris K

PS. This thread needs a post that isn't deleted to move it back up to near the top of the forum.

[SIZE="1"]Let's make it sticky until sieving is finished [/SIZE]

richs 2010-06-21 23:03

60-61M complete and submitted.

Reserving 139-140M.

apocalypse 2010-06-23 04:05

115M-119M completed. 7160853 relations in the range (7130008 unique). uploading now.

Reserving 140M-144M

chris2be8 2010-06-23 16:15

113M-115M uploaded. 3588854 relations.

Chris K

Gimarel 2010-06-24 10:00

Reserving 144M-148M


All times are UTC. The time now is 04:43.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.