Updated polynomial selection

[jrk]

Originally Posted by debrouxl

Some stats about polynomial selection for the remaining C164 of near-repdigit http://hpcgi2.nifty.com/m_kamada/f/c.cgi?q=77771_297 , which has been running on one of my cores for nearly 98 hours:

* the Murphy E values range from ~5.1e-13 to ~8.5e-13;

The 8.5e-13 score is excellent for this input.

[chris2be8]

I've noticed the following at the end of the screen output for RSA110's msieve -np1:

hashtable: 138 entries,  0.14 MB
polynomial selection complete
error generating or reading NFS polynomials
elapsed time 00:21:09

Does this mean a problem? Whenever I see the word error output by a program I start worrying.

Chris K

[jrk]

Originally Posted by chris2be8

I've noticed the following at the end of the screen output for RSA110's msieve -np1:

hashtable: 138 entries,  0.14 MB
polynomial selection complete
error generating or reading NFS polynomials
elapsed time 00:21:09

Does this mean a problem? Whenever I see the word error output by a program I start worrying.

Chris K

-np1 only produces partial (unoptimized) polynomials, so it is normal that you won't get a full polynomial at the end when you use that option. But now that you have finished -np1, you can run -np2 to get the full polynomials.

If you don't want to run msieve twice like this in the future, you may run with -np only, which will run both stages in sequence.

[chris2be8]

Originally Posted by jrk

-np1 only produces partial (unoptimized) polynomials, so it is normal that you won't get a full polynomial at the end when you use that option. But now that you have finished -np1, you can run -np2 to get the full polynomials.

If you don't want to run msieve twice like this in the future, you may run with -np only, which will run both stages in sequence.

I'm running -np1 and -np2 in parallel by making msieve.dat.m a named pipe. See my previous post. What I want to know is if the "error generating or reading NFS polynomials" message means -np1 didn't search as far as it should have.

Chris K

[fivemack]

The 'error generating ...' message appears if there aren't any entries in msieve.dat.p after the polynomial-selection pass; I see it from time to time running msieve -np with sub-optimal parameters where not a single curve is found in some A5 range.

Obviously -np1 will finish with nothing in msieve.dat.p.

So, it's just an artefact of the shape of the program; don't worry about it. Same as the way that a -ncr run will finish saying something unclear about square roots, when all it means is 'now run -nc3'.

[jrk]

Originally Posted by chris2be8

I'm running -np1 and -np2 in parallel by making msieve.dat.m a named pipe. See my previous post. What I want to know is if the "error generating or reading NFS polynomials" message means -np1 didn't search as far as it should have.

Nothing is wrong. -np1 will always end with that error. I could make the error go away but it is only a cosmetic issue.

[tristarman]

i made a polynominal selection with msieve 1.47 and factmsieve.py (v0.74).. is it possible to do the sieving with msieve 1.48 and factmsieve.py (v0.76)? i tried it already and it seems that the sofware was working but i have seen a message about an unknown revision (see attachment)

[Andi47]

Originally Posted by tristarman

i made a polynominal selection with msieve 1.47 and factmsieve.py (v0.74).. is it possible to do the sieving with msieve 1.48 and factmsieve.py (v0.76)? i tried it already and it seems that the sofware was working but i have seen a message about an unknown revision (see attachment)

this unknown revision message comes from the GGNFS siever, it has nothing to do with msieve. For me it looks as it seems to work.

[schickel]

Originally Posted by tristarman

i made a polynominal selection with msieve 1.47 and factmsieve.py (v0.74).. is it possible to do the sieving with msieve 1.48 and factmsieve.py (v0.76)? i tried it already and it seems that the sofware was working but i have seen a message about an unknown revision (see attachment)

Originally Posted by Andi47

this unknown revision message comes from the GGNFS siever, it has nothing to do with msieve. For me it looks as it seems to work.

It's not an error....it's the display of one of the compile-time settings and the revision level. I forget what the L1_BITS setting is for (see here), but the "SVN $Revision$" would have been filled in by SourceForge with the SVN revision level (read this post and the next one.....)

[tristarman]

Originally Posted by Andi47

this unknown revision message comes from the GGNFS siever, it has nothing to do with msieve. For me it looks as it seems to work.

i think no work correct.. see log:

Thu Jan 27 21:41:35 2011 Found 61251994 relations, 107.4% of the estimated minimum (57029236).
Thu Jan 27 21:41:36 2011  
Thu Jan 27 21:41:36 2011  
Thu Jan 27 21:41:36 2011  Msieve v. 1.48
Thu Jan 27 21:41:36 2011  random seeds: b92f8348 af47d834
Thu Jan 27 21:41:36 2011  factoring 6703927226456845236092787161565505201973340970658566195176653288974766211804013820621945450203151220760800372906178064984350552502078301558004672244602561 (154 digits)
Thu Jan 27 21:41:37 2011  searching for 15-digit factors
Thu Jan 27 21:41:37 2011  commencing number field sieve (154-digit input)
Thu Jan 27 21:41:37 2011  R0: -691476128642256065160939049252
Thu Jan 27 21:41:37 2011  R1:  294702069223281919
Thu Jan 27 21:41:37 2011  A0: -184422675619174088372745165230333093301
Thu Jan 27 21:41:37 2011  A1:  391969234366257563885098121836119
Thu Jan 27 21:41:37 2011  A2:  753365188154393180431079
Thu Jan 27 21:41:37 2011  A3: -15135336978267099247
Thu Jan 27 21:41:37 2011  A4: -1021680147138
Thu Jan 27 21:41:37 2011  A5:  42408
Thu Jan 27 21:41:37 2011  skew 8660622.41, size 5.939e-015, alpha -7.615, combined = 3.177e-012 rroots = 3
Thu Jan 27 21:41:37 2011  
Thu Jan 27 21:41:37 2011  commencing relation filtering
Thu Jan 27 21:41:37 2011  estimated available RAM is 4096.0 MB
Thu Jan 27 21:41:37 2011  commencing duplicate removal, pass 1
Thu Jan 27 21:42:16 2011  error -15 reading relation 4727791
Thu Jan 27 21:42:17 2011  error -15 reading relation 4738955
Thu Jan 27 21:42:17 2011  error -15 reading relation 4750202
Thu Jan 27 21:42:17 2011  error -11 reading relation 4761516
Thu Jan 27 21:42:17 2011  error -9 reading relation 4777009
Thu Jan 27 21:42:17 2011  error -11 reading relation 4792503
Thu Jan 27 21:42:17 2011  error -15 reading relation 4808145
Thu Jan 27 21:42:17 2011  error -15 reading relation 4823147
Thu Jan 27 21:42:17 2011  error -15 reading relation 4838798
Thu Jan 27 21:42:17 2011  error -15 reading relation 4854262
Thu Jan 27 21:42:18 2011  error -15 reading relation 4869845
Thu Jan 27 21:42:18 2011  error -11 reading relation 4885366
Thu Jan 27 21:42:18 2011  error -15 reading relation 4885550
Thu Jan 27 21:42:18 2011  error -15 reading relation 4885704
Thu Jan 27 21:42:18 2011  error -15 reading relation 4885856
Thu Jan 27 21:42:18 2011  error -11 reading relation 4886011
Thu Jan 27 21:49:51 2011  error -6 reading relation 58704035
Thu Jan 27 21:49:51 2011  error -6 reading relation 58704065
Thu Jan 27 21:49:51 2011  error -6 reading relation 58704095
Thu Jan 27 21:49:51 2011  error -1 reading relation 58704125
Thu Jan 27 21:49:51 2011  error -9 reading relation 58704155
Thu Jan 27 21:49:51 2011  error -9 reading relation 58704185
Thu Jan 27 21:49:51 2011  error -1 reading relation 58704215
Thu Jan 27 21:49:51 2011  error -1 reading relation 58704245
Thu Jan 27 21:49:51 2011  error -2 reading relation 58704275
Thu Jan 27 21:50:12 2011  found 21381319 hash collisions in 61251968 relations
Thu Jan 27 21:51:02 2011  added 7 free relations
Thu Jan 27 21:51:02 2011  commencing duplicate removal, pass 2

[debrouxl]

A C154 by GNFS... could that be a 512-bit RSA key, per chance ?

One third of duplicate relations is a rather large ratio, but not disproportionate. You'll just probably want to sieve further, until 65M or 70M raw relations.