ggnfs via factMsiev.pl on 125 digit cofactor
 

I've "lucked" into a 125 digit cofactor in one of my sequences and am wondering if my computer can handle the LA, if it ever gets there. Or, maybe whether it can get there. (The 125 digit cofactor is from a 126 digit composite - that's why I call myself lucky.)

I recently had some trouble with the python script and went back to the perl script on this particular machine/sequence, but I'm wondering if it isn't getting anywhere.

After several days of ECM, it has now spent four days with ggnfs and just reduced everything to 38 relations and 0 ideals. Does this mean it's virtually back at the start for ggnfs?

The machine is running WinXP with a 2.4GHz CPU, but only 447MB RAM available, per Msieve message (512MB installed). Am I really back to only 38 relations and that close to when it started 4 days ago? Will I lose much if I restart, trying the python script again. Will this machine be able to run the matrix with only 447MB?

I know, questions, questions, but...

Anyway, thanks for any suggestions...

Take Care,
Ed

[quote=EdH;209540]After several days of ECM, it has now spent four days with ggnfs and just reduced everything to 38 relations and 0 ideals. Does this mean it's virtually back at the start for ggnfs?[/quote]
Don't worry. When you try to run post-processing but are extremely under-sieved, it will reduce it to nearly no relations/ideals. Just keep sieving and (once you near the minimum relations for successful post-processing) the number of relations and ideals will shoot up. You'll get there eventually. :smile:
[quote=EdH;209540]The machine is running WinXP with a 2.4GHz CPU, but only 447MB RAM available, per Msieve message (512MB installed). Am I really back to only 38 relations and that close to when it started 4 days ago? Will I lose much if I restart, trying the python script again. Will this machine be able to run the matrix with only 447MB?[/quote]
A c117 I needed a max of 246.3 MB.
[URL="http://www.mersenneforum.org/showthread.php?t=11800"]This c131[/URL] took a max of 294.4 MB.
So it should fit.
If it's a little too much, (and freeing as much memory as possible by closing unneeded programs or even running in safe mode doesn't help) some oversieving will lower the memory required (which probably explains the close memory requirement in these two very differently-sized jobs).

Thanks Mini-Geek,

Hmm, a c131 was a Team Sieve...maybe I should get one of my other machines sieving...

Is this c125 likely to take a few weeks if left to one machine?

The 3 has been shedding powers and I was hoping the last one would fall off in the next few lines, but I might not have the resources to run this number much further.:sad:

[QUOTE=EdH;209549]Thanks Mini-Geek,

Hmm, a c131 was a Team Sieve...maybe I should get one of my other machines sieving...

Is this c125 likely to take a few weeks if left to one machine?

The 3 has been shedding powers and I was hoping the last one would fall off in the next few lines, but I might not have the resources to run this number much further.:sad:[/QUOTE]Depending on how the params are set, here are a couple of points of reference....

I had a c123 that took 152 hours with these params:[code]rlim: 5000000
alim: 5000000
lpbr: 27
lpba: 27[/code]And I had a c126 that took 239 hours with this set:[code]rlim: 5400000
alim: 5400000
lpbr: 27
lpba: 27[/code]These times are from '06 or '07 on my old 2+ GHz Athlon running Win98.

[Edit: If you think you'll have trouble, let us know. I'm sure someone can help out with the post-processing. I'll be tied up with a c143 for another week or so, but my systems will be mostly free after that.]

[QUOTE=EdH;209549]Thanks Mini-Geek,

Hmm, a c131 was a Team Sieve...maybe I should get one of my other machines sieving...

Is this c125 likely to take a few weeks if left to one machine?
[/QUOTE]

When FactMsieve.pl tries a filtering run (using msieve for this), it will say something like

[code]Sun Feb 07 15:28:22 2010 found 12680 hash collisions in 417559 relations
Sun Feb 07 15:28:24 2010 added 27462 free relations
Sun Feb 07 15:28:24 2010 commencing duplicate removal, pass 2
Sun Feb 07 15:28:25 2010 found 10409 duplicates and 434612 unique relations[/code]

How many raw relations (the figure at the end of the first line here) and how many unique relations do you have up to now (i.e. in the last filtering attempt)?

For a c125 you will need approx. 9.5 million raw relations.

Don't worry if ggnfs reduces "everything to 38 relations and 0 ideals". The relations which you have sieved up to now are [B]not[/B] lost - ggnfs just sees that the c125 is still extremely undersieved and continues sieving from the point just where it left before the filtering attempt.

Edit: Don't start over - I think when factmsieve.pl starts to do filtering attempts from time to time, you are at least halfway through sieving.

With the perl script, create a file "MINRELS.txt" with 9000000 in it. This means that it won't do filtering until at least 9 million relations have been found. You won't waste time by doing filtering with only a third of the necessary relations.

Thanks!

I've added MINRELS.txt file.

Here's a current snapshot:
[code]
Msieve v. 1.44
Fri Mar 26 09:59:28 2010
random seeds: d048b100 a592126a
factoring 1110491822722823081088688490142506637446929630796213877138352114489492
5896999381260082405916006418827566563543744858048501891 (125 digits)
searching for 15-digit factors
commencing number field sieve (125-digit input)
R0: -553274058073488369906936
R1: 5896892239331
A0: -17010541470340266647866398415
A1: -14428085843239031565134244
A2: 938123728073876448750
A3: -61907685184708
A4: -260946730287
A5: 214200
skew 61277.68, size 6.658870e-012, alpha -7.441533, combined = 1.714667e-010
commencing relation filtering
estimated available RAM is 447.0 MB
commencing duplicate removal, pass 1
found 883040 hash collisions in 8050866 relations
added 230 free relations
commencing duplicate removal, pass 2
found 561747 duplicates and 7489349 unique relations
memory use: 26.6 MB
reading ideals above 4784128
commencing singleton removal, initial pass
memory use: 188.3 MB
reading all ideals from disk
memory use: 135.9 MB
commencing in-memory singleton removal
begin with 7489349 relations and 9088909 unique ideals
reduce to 524752 relations and 338394 ideals in 32 passes
max relations containing the same ideal: 14
reading ideals above 30000
commencing singleton removal, initial pass
memory use: 23.5 MB
reading all ideals from disk
memory use: 21.0 MB
commencing in-memory singleton removal
begin with 525014 relations and 943288 unique ideals
reduce to 42 relations and 17 ideals in 6 passes
max relations containing the same ideal: 4
filtering wants 1000000 more relations
elapsed time 00:10:06
-> Q0=4850001, QSTEP=100000.
-> makeJobFile(): q0=4850000, q1=4950000.
-> makeJobFile(): Adjusted to q0=4850001, q1=4950000.
-> Lattice sieving algebraic q-values from q=4850001 to 4950000.
=> "c:/MathWork/ggnfs/gnfs-lasieve4I13e" -k -o spairs.out -v -n0 -a test.job
FBsize 338724+0 (deg 5), 380799+0 (deg 1)
total yield: 112138, q=4879549 (0.04385 sec/rel)
[/code]

Not being able to edit the previous post, I'm supplying a few more details in this separate post in case anyone is interested:

The c125 took one week to factor.
The CPU is 2.4GHz.
The OS is WinXP.
Msieve was v1.44.
I used factMsieve.pl.
It needed > 10M relations.
It used 355.5 MB RAM for the LA.

Debug info for gnfs-lasieve4I12e.exe crash?
 

This has just been posted into the "Python driver for GGNFS"-thread - maybe it's some helpful debug infor for the crash I have reported a few times on gnfs-lasieve4I12e (and I've also seen 11e and 13e crashing in this way):

[QUOTE=WraithX;210017]I've been running several snfs factoring jobs with factmsieve.py and have run into the "Return value -1073741819" problem. It has happened to 6 of my 67 snfs factoring jobs. The simple fix for each case was to update the c024.job.resume file to be the next block to be sieved. Then I would just start factmsieve.py c024.poly, and it would pick back up and run to completion. For example (I've been running 3 threads), if it crashed during the 400000 to 450000 block, I would change the .resume file from:
Q0: 400000
QSTEP: 50000
QLAST0: 415297
QLAST1: 431862
QLAST2: 449801
To:
Q0: 450000
QSTEP: 50000
QLAST0: 450000
QLAST1: 466667
QLAST2: 483334

I think I've found out the meaning of the error code too. When I went into microsoft's calculator program and entered in the number -1073741819, I then click to convert that to hexadecimal and get 0xffffffffc0000005. The important part here is the 0xc0000005 part. This is a generic windows error code for "Illegal memory access violation". When I look into my event log I see the following info:
Faulting application gnfs-lasieve4i12e.exe, version 0.0.0.0, faulting module gnfs-lasieve4i12e.exe, version 0.0.0.0, fault address 0x00031dd4

I don't know how to look into the executable and find out what part of the code is at 0x31dd4. If anyone else does, this may be a good place to look.

However, without getting into the siever code, I think just picking up sieving with the next block is a good way to proceed. What do you think of this course of action Brian?[/QUOTE]

[quote=Jeff Gilchrist;161119]There are no Core2 specific optimizations in the 32bit code, so the Pentium4 version should also the best one to use for Core 2. Same thing with Opterons, only 64bit specific optimizations available. I don't have 32bit Core2 or Opteron systems to test if the Pentium4 optimized code or the generic C code would be faster (I'm assuming P4).

You also need to test out the software to see which one in practice is faster. On my Core2 system the 32bit P4 lattice siever is faster than the 64bit Core2 version, other 64bit binaries are faster than the 32bit ones. So I generally use the 32bit sievers, and 64bit everything else in the GGNFS package. YMMV

Jeff.[/quote]

Hi!

I know i'm quoting an old post.

First of all, thank you for giving support for newbies like me.

Second:

I'm using an i7 795 quad core CPU, (as you know8 CPU's declared by hiperthreading).

Should i try the "32bit P4 lattice siever" versions, or is this an old issue ?

Regards,
scalabis

[quote=Andi47;210022]This has just been posted into the "Python driver for GGNFS"-thread - maybe it's some helpful debug infor for the crash I have reported a few times on gnfs-lasieve4I12e (and I've also seen 11e and 13e crashing in this way):[/quote]

I have seen these crashes on my WinXP system as well. I was running under Aliqueit at these times. IIRC, I simply stopped and restarted Aliqueit and all proceeded fine. If I experience another crash, I will try to study it in more depth.