@Curtis,

Thanks for finding that for me. I had gone over the READMEs in the main directory and now I remember seeing the other one.

I now have scripts/binaries that will run straight from providing a command line bash call with a composite as the only option, though to the printing of the factors in the terminal at the end, (unless it needs more relations). It stops cado-nfs at the filtering step and continues with msieve. I will soon try it on the c155 from earlier. I'm actually wondering if it won't fail with too few relations and the extra sieving will eat up any LA time saving.

Something I have observed, though, is that the siever clients continue to run until their assignment is complete, even if the server has moved on to filtering, etc. This might actually help the issue if more relations are needed. First, I'll see what happens when I try a straight run with the c155.

Ed

When I sent my params files to PaulZ and the CADO group, Paul suggested that I may wish to set rels_needed to a minimum higher than CADO default. I believe the cause is that sieving smaller Q values produces more duplicates than the default Q-range CADO chooses, so the number of raw relations CADO aims for isn't quite enough because of the extra duplicates. We can use your data from the previous run to do that- set the rels needed to 5% less than the number you needed last time (to account for C153 or C154 jobs that would run on this file too).

I like that the siever-clients keep running during filtering; I feel like wasting a couple filtering attempts is worth the chance at saved sieve time, and wall clock time doesn't suffer much because the other clients produce a bunch of relations while the first filtering pass runs. With your 100+ clients, this isn't as efficient (since inevitably a bunch of sieve effort will be wasted when the filtering pass builds a matrix).

Edit: Then again, if needing more relations causes a hiccup in your automation, ask for 15% more relations than we think is needed, and hope that means msieve only needs to be called once!

[QUOTE=VBCurtis;487488]When I sent my params files to PaulZ and the CADO group, Paul suggested that I may wish to set rels_needed to a minimum higher than CADO default. I believe the cause is that sieving smaller Q values produces more duplicates than the default Q-range CADO chooses, so the number of raw relations CADO aims for isn't quite enough because of the extra duplicates. We can use your data from the previous run to do that- set the rels needed to 5% less than the number you needed last time (to account for C153 or C154 jobs that would run on this file too).

I like that the siever-clients keep running during filtering; I feel like wasting a couple filtering attempts is worth the chance at saved sieve time, and wall clock time doesn't suffer much because the other clients produce a bunch of relations while the first filtering pass runs. With your 100+ clients, this isn't as efficient (since inevitably a bunch of sieve effort will be wasted when the filtering pass builds a matrix).

Edit: Then again, if needing more relations causes a hiccup in your automation, ask for 15% more relations than we think is needed, and hope that means msieve only needs to be called once![/QUOTE]Thanks Curtis,

I can't find a rels_needed in the parameter list, but I see a rels_wanted with a default of 0. My recent c100 test shows a value of 2679831 and I have a c150 log that shows 71293383, but I can't find any c155 log. Is this what I would adjust? I'll probably try a default run first because the set of relations I tried that failed, may have been incomplete. I can also have a rels number to work with for later adjustment.

I didn't get started with my machines early enough today for a test run. Maybe I can get things set up tonight and start a run tomorrow morning.

Ed

Sorry, I meant the tasks.sieve.rels_wanted from the readme a few posts ago. Just about any flag that can be set on the command line can also be placed in the params file.

Your CADO c155 run lists 138M relations at 30/31LP. Long ago I solved a C155 with msieve 30LP and needed 80M relations; more recently I solved a C149 with 31LP and 135M relations. Based on those two data points, the CADO production of 138M relations should be more than sufficient! If they're not, that suggests CADO maybe has a higher duplicate rate than GGNFS; we should then compare unique relations rather than raw relations to see what's going on.

[QUOTE=VBCurtis;487506]Sorry, I meant the tasks.sieve.rels_wanted from the readme a few posts ago. Just about any flag that can be set on the command line can also be placed in the params file.

Your CADO c155 run lists 138M relations at 30/31LP. Long ago I solved a C155 with msieve 30LP and needed 80M relations; more recently I solved a C149 with 31LP and 135M relations. Based on those two data points, the CADO production of 138M relations should be more than sufficient! If they're not, that suggests CADO maybe has a higher duplicate rate than GGNFS; we should then compare unique relations rather than raw relations to see what's going on.[/QUOTE]OK, so that sounds good for me to try a default run, then. I was concerned because of a trial I did with the rels I had from a c150 run, but it's probable the "snapshot" of the temporary folder was made prior to the completion of sieving.

We might also find out from your calculations, that the cado-nfs relations could be cut some.

I'm looking forward to seeing how this next experiment runs.

Of course, from my "farming" viewpoint, I would really welcome distributed LA, as suggested somewhere I recently read, but can't seem to locate again. It was something different from the paper you pointed me to a few posts back.

I wish I knew enough to help in that development, but it would take more dedication than I can muster to learn what I would need...

I had two false starts this morning in trying to run the c155 with my new scripts. Apparently, I had a conflict with providing a name when one existed within the params file. I think I have solved this issue and have completed a couple of smaller tests with success. I'll try a little larger one later and the c155 again tomorrow.

When letting CADO-NFS complete the factorization, it kills the clients, appropriately, when no longer needed. I see, now that I am telling CADO-NFS to stop at filtering, it no longer tells the clients to stop at all. This may be because I am manually controlling the clients, whereas if I had the server call them, they may be killed when it is aborted.

As to aborting at the filtering stage, it does not appear to be a gentle ending to the cado-nfs.py script, but rather a "harsh" ending with Traceback and Exception messages.

How disappointing:
[code]
Mon May 14 13:31:40 2018 Msieve v. 1.54 (SVN 1015)
Mon May 14 13:31:40 2018 random seeds: bda7bc3a 7d279c6a
Mon May 14 13:31:40 2018 factoring 83430973660859696075606860121751204140765096280774007534994681679625269640631965880347308911045515734302894715692241103470949 (125 digits)
Mon May 14 13:31:40 2018 searching for 15-digit factors
Mon May 14 13:31:41 2018 commencing number field sieve (125-digit input)
Mon May 14 13:31:41 2018 R0: -753029938976683458937593
Mon May 14 13:31:41 2018 R1: 1785081673495471
Mon May 14 13:31:41 2018 A0: -7629089397626407377977251370
Mon May 14 13:31:41 2018 A1: 1398616311587389133353367
Mon May 14 13:31:41 2018 A2: 43796173748317237522
Mon May 14 13:31:41 2018 A3: -1503928724515567
Mon May 14 13:31:41 2018 A4: -138299341992
Mon May 14 13:31:41 2018 A5: -2756160
Mon May 14 13:31:41 2018 skew 1.00, size 4.464e-12, alpha -6.578, combined = 6.846e-12 rroots = 3
...
Mon May 14 13:35:58 2018 commencing linear algebra
Mon May 14 13:35:58 2018 read 850225 cycles
Mon May 14 13:35:59 2018 cycles contain 2733559 unique relations
Mon May 14 13:36:20 2018 read 2733559 relations
Mon May 14 13:36:22 2018 using 20 quadratic characters above 4294917295
Mon May 14 13:36:34 2018 building initial matrix
Mon May 14 13:36:52 2018 memory use: 358.7 MB
Mon May 14 13:36:52 2018 read 850225 cycles
Mon May 14 13:36:53 2018 matrix is 850047 x 850225 (258.0 MB) with weight 81305451 (95.63/col)
Mon May 14 13:36:53 2018 sparse part has weight 57440675 (67.56/col)
Mon May 14 13:36:58 2018 filtering completed in 2 passes
Mon May 14 13:36:58 2018 matrix is 849325 x 849502 (258.0 MB) with weight 81275010 (95.67/col)
Mon May 14 13:36:58 2018 sparse part has weight 57430903 (67.61/col)
Mon May 14 13:37:01 2018 matrix starts at (0, 0)
Mon May 14 13:37:01 2018 matrix is 849325 x 849502 (258.0 MB) with weight 81275010 (95.67/col)
Mon May 14 13:37:01 2018 sparse part has weight 57430903 (67.61/col)
Mon May 14 13:37:01 2018 saving the first 48 matrix rows for later
Mon May 14 13:37:01 2018 matrix includes 64 packed rows
Mon May 14 13:37:02 2018 matrix is 849277 x 849502 (247.0 MB) with weight 64545583 (75.98/col)
Mon May 14 13:37:02 2018 sparse part has weight 56241767 (66.21/col)
Mon May 14 13:37:02 2018 using block size 8192 and superblock size 786432 for processor cache size 8192 kB
Mon May 14 13:37:04 2018 commencing Lanczos iteration (8 threads)
Mon May 14 13:37:04 2018 memory use: 192.7 MB
Mon May 14 13:37:07 2018 linear algebra at 0.4%, ETA 0h13m
Mon May 14 13:53:15 2018 lanczos halted after 13434 iterations (dim = 849276)
Mon May 14 13:53:16 2018 recovered 31 nontrivial dependencies
Mon May 14 13:53:16 2018 BLanczosTime: 1038
Mon May 14 13:53:16 2018
Mon May 14 13:53:16 2018 commencing square root phase
Mon May 14 13:53:16 2018 [B]cannot handle negative leading algebraic polynomial coefficient[/B]
Mon May 14 13:53:16 2018 sqrtTime: 0
Mon May 14 13:53:16 2018 elapsed time 00:21:36
[/code]

I might be wrong but I think you could just flip the sign for all the coefficients. It will add a factor of -1 to each relation but that is fine.

That was reported to work on an older very large factorization.

Huhhh??
 

HELP, CADO-NFS is fast! :confused2::max::sos:


[SIZE=3][B]RSA-100[/B][/SIZE]


[B]Factmsieve(v0.86) + Msieve + GGNFS sievers (with asm)[/B]

[code]
Mon May 14 00:11:33 2018 -> factmsieve.py (v0.86)
Mon May 14 00:11:33 2018 -> This is client 1 of 1
Mon May 14 00:11:33 2018 -> Running on 16 Cores with 2 hyper-threads per Core
Mon May 14 00:11:33 2018 -> Working with NAME = RSA100
Mon May 14 00:11:33 2018 -> Running polynomial selection ...
Mon May 14 00:11:33 2018 -> ./msieve -s ./RSA100.dat.T0 -l ./RSA100.log.T0 -i ./RSA100.ini.T0 -nf ./RSA100.fb.T0 -np 1,100 -v > ./RSA100.msp.T0
...
<deleted lines>
...
Mon May 14 00:11:58 2018 Best score so far: # norm 1.402930e-13 alpha -6.325236 e 1.281e-08 rroots 2
...
Mon May 14 00:11:58 2018 -> Selected lattice siever: gnfs-lasieve4I12e
Mon May 14 00:11:58 2018 -> entering sieving loop
....
Mon May 14 00:19:08 2018 Found 5074452 relations, 123.9% of the estimated minimum (4095000).
Mon May 14 00:19:09 2018 commencing relation filtering
...
Mon May 14 00:20:42 2018 -> Running matrix solving step
..
Mon May 14 00:22:25 2018 -> Running square root step
...
Mon May 14 00:22:53 2018 p50 factor: 37975227936943673922808872755445627854565536638199
Mon May 14 00:22:53 2018 p50 factor: 40094690950920881030683735292761468389214899724061[/code]If my time math is correct:

0:00:25 Poly
0:07:10 Sieving
0:01:34 Filtering
0:01:43 LA
0:00:28 SQR
-----------
0:11:20 total ([B]680 seconds[/B])


[B]CADO-NFS 3.0-dev[/B]

[code]./cado-nfs.py 1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139
Info:root: Using default parameter file ./parameters/factor/params.c100
...
...
Info:Square Root: Factors: 37975227936943673922808872755445627854565536638199 40094690950920881030683735292761468389214899724061
Info:Polynomial Selection (size optimized): Aggregate statistics:
Info:Polynomial Selection (size optimized): potential collisions: 5781.44
Info:Polynomial Selection (size optimized): raw lognorm (nr/min/av/max/std): 5778/32.780/37.836/38.680/0.700
Info:Polynomial Selection (size optimized): optimized lognorm (nr/min/av/max/std): 5778/32.780/36.541/38.680/0.989
Info:Polynomial Selection (size optimized): Total time: 179.29
Info:Polynomial Selection (root optimized): Aggregate statistics:
Info:Polynomial Selection (root optimized): Total time: 113.19
Info:Polynomial Selection (root optimized): Rootsieve time: 112.7
Info:Generate Factor Base: Total cpu/real time for makefb: 1.42/0.164074
Info:Generate Free Relations: Total cpu/real time for freerel: 41.53/1.53222
Warning:Lattice Sieving: some stats could not be displayed for sieving (see log file for debug info)
Info:Lattice Sieving: Aggregate statistics:
Info:Lattice Sieving: Total number of relations: 2554287
Info:Lattice Sieving: Average J: 1026.82 for 85306 special-q
Info:Lattice Sieving: Total CPU time: 11204.3s
Info:Filtering - Duplicate Removal, splitting pass: Total cpu/real time for dup1: 8.95/7.15092
Info:Filtering - Duplicate Removal, splitting pass: Aggregate statistics:
Info:Filtering - Duplicate Removal, splitting pass: CPU time for dup1: 6.9s
Info:Filtering - Duplicate Removal, removal pass: Total cpu/real time for dup2: 41.33/16.053
Warning:Filtering - Duplicate Removal, removal pass: some stats could not be displayed for duplicates2 (see log file for debug info)
Info:Filtering - Singleton removal: Total cpu/real time for purge: 36.22/17.4717
Info:Filtering - Merging: Total cpu/real time for merge: 77.19/56.4209
Info:Filtering - Merging: Total cpu/real time for replay: 7.2/6.00657
Info:Linear Algebra: Total cpu/real time for bwc: 1019.53/109.33
Info:Linear Algebra: Aggregate statistics:
Info:Linear Algebra: Krylov: WCT time 57.87, iteration CPU time 0.01, COMM 0.0, cpu-wait 0.0, comm-wait 0.0 (6000 iterations)
Info:Linear Algebra: Lingen CPU time 70.78, WCT time 6.49
Info:Linear Algebra: Mksol: WCT time 33.26, iteration CPU time 0.01, COMM 0.0, cpu-wait 0.0, comm-wait 0.0 (3000 iterations)
Info:Quadratic Characters: Total cpu/real time for characters: 8.98/1.74848
Info:Square Root: Total cpu/real time for sqrt: 119.93/18.0659
Info:HTTP server: Shutting down HTTP server
Info:Complete Factorization: Total cpu/elapsed time for entire factorization: 21026.1/715.742
[/code]CADO-NFS took [B]716[/B] seconds, only 36 seconds more than the GGNFS+msieve pack. (so only ~5% slower). Isn't GGNFS supposed to run circles around CADO-NFS in the lower ( < C140 ) regions??? I actually didn't believe the result at first, so I ran it again and it the timings were almost identical (actually even a few seconds WCT faster)
[code]
Info:Complete Factorization: Total cpu/elapsed time for entire factorization: 21181.5/709.047

[/code]So what happens if we move on to slightly bigger composites?
[SIZE=3][B]RSA-110[/B][/SIZE]

[B]Factmsieve(v0.86) + Msieve + GGNFS sievers (with asm routines)[/B]
[code]
Mon May 14 13:26:50 2018 -> factmsieve.py (v0.86)
Mon May 14 13:26:50 2018 -> This is client 1 of 1
Mon May 14 13:26:50 2018 -> Running on 16 Cores with 2 hyper-threads per Core
Mon May 14 13:26:50 2018 -> Working with NAME = RSA110
Mon May 14 13:26:50 2018 -> Running polynomial selection ...
Mon May 14 13:26:50 2018 -> ./msieve -s ./RSA110.dat.T0 -l ./RSA110.log.T0 -i ./RSA110.ini.T0 -nf ./RSA110.fb.T0 -np 1,1000 -v > ./RSA110.msp.T0
..
Mon May 14 13:28:44 2018 Best score so far: # norm 2.170012e-10 alpha -6.451622 e 1.047e-09 rroots 5
Mon May 14 13:28:44 2018 -> Selected lattice siever: gnfs-lasieve4I13e
Mon May 14 13:28:44 2018 -> entering sieving loop
...
Mon May 14 13:57:57 2018 Found 8210614 relations, 111.7% of the estimated minimum (7350000).

Mon May 14 13:57:58 2018 commencing relation filtering
...
Mon May 14 14:00:47 2018 -> Running matrix solving step
...
Mon May 14 14:02:47 2018 commencing square root phase
...
Mon May 14 14:04:16 2018 p55 factor: 5846418214406154678836553182979162384198610505601062333
Mon May 14 14:04:16 2018 p55 factor: 6122421090493547576937037317561418841225758554253106999

[/code]0:02:54 Poly
0:29:13 Sieving
0:02:50 Filtering
0:02:00 LA
0:01:29 SQR
----------
0:38:26 total ([B]2306[/B] seconds, 2306/680= 3.39xRSA100), keep those [U]2300[/U] seconds in mind!

For this run I changed the size of the np1 workunits in the factmsieve.py from 100 to 1000 (for a more constant CPU load) and the range from 0 - 4000 to:
[code]# msieve polynomial search leading coefficients limits
# search from POLY_MIN_LC + 1 to POLY_MAX_LC inclusive
POLY_MIN_LC = 0
POLY_MAX_LC = 64000
[/code]


Now comes the unbelievable part:

[B]CADO-NFS 3.0-dev[/B]
[code]
./cado-nfs.py 35794234179725868774991807832568455403003778024228226193532908190484670252364677411513516111204504060317568667 workdir=/tmp/RSA110
Info:root: Using default parameter file ./parameters/factor/params.c110
Info:root: No database exists yet
Info:root: Set tasks.threads=32 based on detected logical cpus
...
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_0-5000 to client localhost
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_5000-10000 to client localhost+2
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_10000-15000 to client localhost+3
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_15000-20000 to client localhost+4
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_20000-25000 to client localhost+6
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_25000-30000 to client localhost+5
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_30000-35000 to client localhost+7
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_35000-40000 to client localhost+8
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_40000-45000 to client localhost+10
Info:HTTP server: 127.0.0.1 Sending workunit c110_polyselect1_45000-50000 to client localhost+9
...
Info:Polynomial Selection (root optimized): Finished, best polynomial from file /tmp/RSA110/c110.upload/c110.polyselect2.pfbrex9n.opt_72 has Murphy_E = 2.59e-09
...
Info:Square Root: Factors: 6122421090493547576937037317561418841225758554253106999 5846418214406154678836553182979162384198610505601062333
Info:Polynomial Selection (size optimized): Aggregate statistics:
Info:Polynomial Selection (size optimized): potential collisions: 11711.3
Info:Polynomial Selection (size optimized): raw lognorm (nr/min/av/max/std): 11672/31.850/38.956/44.950/1.139
Info:Polynomial Selection (size optimized): optimized lognorm (nr/min/av/max/std): 11672/31.310/34.551/39.370/0.976
Info:Polynomial Selection (size optimized): Total time: 1176.67
Info:Polynomial Selection (root optimized): Aggregate statistics:
Info:Polynomial Selection (root optimized): Total time: 489.95
Info:Polynomial Selection (root optimized): Rootsieve time: 488.36
Info:Generate Factor Base: Total cpu/real time for makefb: 4.37/0.373342
Info:Generate Free Relations: Total cpu/real time for freerel: 109.26/3.60933
Warning:Lattice Sieving: some stats could not be displayed for sieving (see log file for debug info)
Info:Lattice Sieving: Aggregate statistics:
Info:Lattice Sieving: Total number of relations: 5412839
Info:Lattice Sieving: Average J: 1893.28 for 79582 special-q
Info:Lattice Sieving: Total CPU time: 28220.8s
Info:Filtering - Duplicate Removal, splitting pass: Total cpu/real time for dup1: 18.96/16.6092
Info:Filtering - Duplicate Removal, splitting pass: Aggregate statistics:
Info:Filtering - Duplicate Removal, splitting pass: CPU time for dup1: 16.0s
Info:Filtering - Duplicate Removal, removal pass: Total cpu/real time for dup2: 113.86/54.6661
Warning:Filtering - Duplicate Removal, removal pass: some stats could not be displayed for duplicates2 (see log file for debug info)
Info:Filtering - Singleton removal: Total cpu/real time for purge: 97.19/51.8443
Info:Filtering - Merging: Total cpu/real time for merge: 106.71/89.2541
Info:Filtering - Merging: Total cpu/real time for replay: 9.6/7.87395
Info:Linear Algebra: Total cpu/real time for bwc: 1904.82/190.56
Info:Linear Algebra: Aggregate statistics:
Info:Linear Algebra: Krylov: WCT time 105.61, iteration CPU time 0.01, COMM 0.0, cpu-wait 0.0, comm-wait 0.0 (8000 iterations)
Info:Linear Algebra: Lingen CPU time 110.81, WCT time 10.02
Info:Linear Algebra: Mksol: WCT time 59.48, iteration CPU time 0.01, COMM 0.0, cpu-wait 0.0, comm-wait 0.0 (4000 iterations)
Info:Quadratic Characters: Total cpu/real time for characters: 13.74/2.61752
Info:Square Root: Total cpu/real time for sqrt: 260.73/37.302
Info:HTTP server: Shutting down HTTP server
Info:Complete Factorization: Total cpu/elapsed time for entire factorization: 42899.5/[B]1549.64[/B]
6122421090493547576937037317561418841225758554253106999 5846418214406154678836553182979162384198610505601062333[/code][B]1550[/B] seconds WCT!! Remember those 2300 seconds it took GGNFS?
1550 seconds works out to 25:50 for us mortals. That is [U]12 [/U]minutes faster than GGNFS. If left running, it would be halfway the second factorization!



CADO-NFS is cheating somewhere :chappy:, or I must have made a mistake. Or maybe the GGNFS default parameters are not very good??!!

CADO searched a smaller LC range (1 - 50 000) in Poly selection and found a poly with a much better Murpy-E (2.59e-09) compared to Msieve (e 1.047e-09), assuming they use the leading coeficients and compute Murpy-E the same way???????

I also ran this twice, with very similar CPUtime and WCT stats

[code]
Info:Complete Factorization: Total cpu/elapsed time for entire factorization: 42725.2/1555.01[/code]


[SIZE=3][B]RSA-120[/B][/SIZE]

[B]Factmsieve(v0.86) + Msieve + GGNFS sievers (with asm routines)[/B]
[code]
Mon May 14 15:57:16 2018 -> factmsieve.py (v0.86)
Mon May 14 15:57:16 2018 -> This is client 1 of 1
Mon May 14 15:57:16 2018 -> Running on 16 Cores with 2 hyper-threads per Core
Mon May 14 15:57:16 2018 -> Working with NAME = RSA120
Mon May 14 15:57:16 2018 -> Running polynomial selection ...
Mon May 14 15:57:16 2018 -> ./msieve -s ./RSA120.dat.T0 -l ./RSA120.log.T0 -i ./RSA120.ini.T0 -nf ./RSA120.fb.T0 -np 1,1000 -v > ./RSA120.msp.T0
...
Mon May 14 16:12:45 2018 -> ./msieve -s ./RSA120.dat.T31 -l ./RSA120.log.T31 -i ./RSA120.ini.T31 -nf ./RSA120.fb.T31 -np 127001,128000 -v >> ./RSA120.msp.T31
...
Mon May 14 16:12:46 2018 Best score so far: # norm 2.428994e-11 alpha -6.396319 e 3.305e-10 rroots 5
...
Mon May 14 16:12:46 2018 -> Selected lattice siever: gnfs-lasieve4I13e
Mon May 14 16:12:46 2018 -> entering sieving loop
...
Mon May 14 17:09:15 2018 Found 9260958 relations, 104.6% of the estimated minimum (8850000)
Mon May 14 17:09:16 2018 commencing relation filtering
...
Mon May 14 17:12:13 2018 filtering wants 1000000 more relations
...
Mon May 14 17:16:20 2018 Found 10027164 relations, 113.3% of the estimated minimum (8850000)
Mon May 14 17:16:21 2018 commencing relation filtering
...
Mon May 14 17:20:00 2018 -> Running matrix solving step
...
Mon May 14 17:26:53 2018 -> Running square root step
...
Mon May 14 17:28:40 2018 p60 factor: 327414555693498015751146303749141488063642403240171463406883
Mon May 14 17:28:40 2018 p60 factor: 693342667110830181197325401899700641361965863127336680673013

[/code]0:15:30 Poly
0:56:29 Sieving
0:02:58 Filtering attempt1
0:04:08 extra Sieving (total Sieving 1:00:37)
0:03:39 Filtering attempt2 (total Filtering 0:06:37)
0:06:53 LA
0:01:47 SQR

-----------

1:31:24 Total ([B]5484[/B] seconds), This is a [U]strong[/U] performance from GGNFS. With excellent scaling, only 2.38x RSA110 (nowhere near doubling every 5 digits!). Poly search was maybe a bit too long (1 - 128 000) and if it didn't attempt the first time filtering it could save maybe another 5 minutes?



[B]CADO-NFS 3.0-dev[/B]
[code]
./cado-nfs.py 227010481295437363334259960947493668895875336466084780038173258247009162675779735389791151574049166747880487470296548479
Info:root: Using default parameter file ./parameters/factor/params.c120
...
Info:root: Set tasks.threads=32 based on detected logical cpus
...
Info:Polynomial Selection (size optimized): Adding workunit c120_polyselect1_96000-100000 to database
...
Info:Polynomial Selection (root optimized): Finished, best polynomial from file /tmp/cado.y6d80vda/c120.upload/c120.polyselect2.s7415ny4.opt_90 has Murphy_E = 2.47e-09
...
Info:Square Root: Factors: 327414555693498015751146303749141488063642403240171463406883 693342667110830181197325401899700641361965863127336680673013
Info:Polynomial Selection (size optimized): Aggregate statistics:
Info:Polynomial Selection (size optimized): potential collisions: 19893.3
Info:Polynomial Selection (size optimized): raw lognorm (nr/min/av/max/std): 20018/34.470/42.677/47.450/1.072
Info:Polynomial Selection (size optimized): optimized lognorm (nr/min/av/max/std): 20018/33.410/37.836/43.140/0.979
Info:Polynomial Selection (size optimized): Total time: 4541.77
Info:Polynomial Selection (root optimized): Aggregate statistics:
Info:Polynomial Selection (root optimized): Total time: 1416.04
Info:Polynomial Selection (root optimized): Rootsieve time: 1414.04
Info:Generate Factor Base: Total cpu/real time for makefb: 9.54/0.656109
Info:Generate Free Relations: Total cpu/real time for freerel: 219.4/7.26091
Warning:Lattice Sieving: some stats could not be displayed for sieving (see log file for debug info)
Info:Lattice Sieving: Aggregate statistics:
Info:Lattice Sieving: Total number of relations: 13250893
Info:Lattice Sieving: Average J: 1901.72 for 233502 special-q
Info:Lattice Sieving: Total CPU time: 106196s
Info:Filtering - Duplicate Removal, splitting pass: Total cpu/real time for dup1: 48.16/42.6905
Info:Filtering - Duplicate Removal, splitting pass: Aggregate statistics:
Info:Filtering - Duplicate Removal, splitting pass: CPU time for dup1: 41.8s
Info:Filtering - Duplicate Removal, removal pass: Total cpu/real time for dup2: 377.57/203.891
Warning:Filtering - Duplicate Removal, removal pass: some stats could not be displayed for duplicates2 (see log file for debug info)
Info:Filtering - Singleton removal: Total cpu/real time for purge: 325.72/185.027
Info:Filtering - Merging: Total cpu/real time for merge: 273.95/228.449
Info:Filtering - Merging: Total cpu/real time for replay: 25.6/20.9339
Info:Linear Algebra: Total cpu/real time for bwc: 10267.9/981.21
Info:Linear Algebra: Aggregate statistics:
Info:Linear Algebra: Krylov: WCT time 592.94, iteration CPU time 0.02, COMM 0.0, cpu-wait 0.01, comm-wait 0.0 (18500 iterations)
Info:Linear Algebra: Lingen CPU time 270.32, WCT time 24.72
Info:Linear Algebra: Mksol: WCT time 340.55, iteration CPU time 0.02, COMM 0.0, cpu-wait 0.01, comm-wait 0.0 (9500 iterations)
Info:Quadratic Characters: Total cpu/real time for characters: 37.88/6.75894
Info:Square Root: Total cpu/real time for sqrt: 772.36/110.95
Info:HTTP server: Shutting down HTTP server
Info:Complete Factorization: Total cpu/elapsed time for entire factorization: 142725/[B]5569.33[/B]
Info:root: Cleaning up computation data in /tmp/cado.y6d80vda
327414555693498015751146303749141488063642403240171463406883 693342667110830181197325401899700641361965863127336680673013

[/code][B]5569[/B] seconds WCT (1:32:49). GGNFS was faster, but only 1-2 minutes!! Also, CADO [U]continued[/U] sieving while attempting filtering, while the GGNFS/factmsieve.py script waits for the outcome of the filtering attempt.
And look at the E scores: e 3.305e-10 vs. Murphy_E = [B]2.47e-09[/B]
Did CADO just find a really, really good poly with (1 - 100 000)??? Or did GGNFS/Msieve somehow fail (or did I somewhere??)


Please tell me what did I do wrong? There must be some mistake somewhere or the believe that GGNFS/Msieve/factmsieve.py package is faster for small composites needs revision?

Please check, double check and tripple check my findings!


We need MOAAAARR DATA!!!!

[QUOTE=henryzz;487590]I might be wrong but I think you could just flip the sign for all the coefficients. It will add a factor of -1 to each relation but that is fine.[/QUOTE]
Thanks - worked great! Is there some way to tell if I will have this trouble prior to translating the poly file to the fb file. If I can tell at that time, I can translate as needed. Should c0/A0 be positive to start with, perhaps?