20160115, 20:26  #1 
Jan 2016
2×5 Posts 
Estimated relations Factmsieve
Hello, I'm new to factoring and I'm trying to factor a number for teslacrypt. The number is C130, and I'm at 20 million relations (111.4% of the estimated minimum). The script is checking if it can step into the final algebra calculations step, but it never does. Are there any estimates on how much more does it need or anything?
Thanks. 
20160115, 20:41  #2 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
19·523 Posts 
If you post the full log, perhaps this question can be answered. It is possible that the process is indeed close to proceeding to the next step, but also possible that due to some misconfiguration your process only collects redundant relations  this will be visible in the log.
zip the log, then use the little "staple" icon in the first row of the message editor to attach the zipped log. 
20160115, 20:46  #3 
Jan 2016
2×5 Posts 
Here is the zipped log. I just now looked at it, and it seams there are quite some errors in it. Maybe I screwed it over, since I started with 64 threads, but then lowered it to 8. I have been running the factorization for a few hours everyday for the past week. I mainly have little idea what I'm doing, but I would like to crack this.

20160115, 20:56  #4 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
19·523 Posts 
Something is not right with your configuration / threads, because your number of nonredundant relations grows very slowly:
Code:
$ grep begin ../example.log tail Fri Jan 15 20:52:25 2016 begin with 13066990 relations and 17522202 unique ideals Fri Jan 15 20:58:14 2016 begin with 13077065 relations and 17528690 unique ideals Fri Jan 15 21:03:55 2016 begin with 13087223 relations and 17535179 unique ideals Fri Jan 15 21:09:29 2016 begin with 13097130 relations and 17541459 unique ideals Fri Jan 15 21:14:59 2016 begin with 13106590 relations and 17547630 unique ideals Fri Jan 15 21:20:40 2016 begin with 13117290 relations and 17554537 unique ideals Fri Jan 15 21:26:11 2016 begin with 13128119 relations and 17561337 unique ideals Fri Jan 15 21:31:43 2016 begin with 13138099 relations and 17567672 unique ideals Fri Jan 15 21:37:11 2016 begin with 13148280 relations and 17574176 unique ideals Fri Jan 15 21:42:50 2016 begin with 13157555 relations and 17580112 unique ideals 
20160115, 21:01  #5 
Jan 2016
12_{8} Posts 
Well, I guess I should have researched the process a bit more before starting with the factorization. But I didn't really change anything except the number of threads. I guess I'll stop this run now.
Last fiddled with by cimpresovec on 20160115 at 21:01 
20160115, 21:05  #6 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
23321_{8} Posts 
Wait for someone from the .py script users who may have seen this to recommend next steps. (This has been seen before, and exactly when the script is stopped and restarted with the changed #threads. I am not using this particular script, so I cannot advise.)

20160115, 21:17  #7 
Jan 2016
2×5 Posts 
While we discuss this, would there have been a faster way to do this? I probably ran this for 20 hours on a fully used i7 2.4GHz, and by the looks of it, i'd say most of the data is useless. I have an Nvidia card, but probably not a fast one.

20160115, 21:31  #8 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9937_{10} Posts 
No, lattice sieving a.f.a.i.k. is not readily implemented for GPUs. This is done on CPU.
(GPU is helpful during the polynomial search phase  but you are already past that.) Right now your process is moving albeit very slowly. A 130digit gnfs project usually should take much less than a week on a system like yours; you just have to wait for someone from .py users to advise. They will tell you 
20160115, 21:39  #9 
Jan 2016
2·5 Posts 
Thanks for the help. I'll wait if someone else can advise.

20160115, 21:47  #10 
Basketry That Evening!
"Bunslow the Bold"
Jun 2011
40<A<43 89<O<88
3·29·83 Posts 
If it's anything like yafu, setting the threads to 64 and then 8 probably messed up where factmsieve.py thinks it's already sieved, and is probably unwittingly redoing work from the time when there were 64 threads. Batalov, if he's close to having enough unique rels, then either sieving within the FB (below where factmsieve.py would normally start) or high above any potential upper bound should do the trick. Basically work guaranteed to be nonredundant. It would be slow of course, but enough to push him over the edge. It's up to you to judge and translate to useful help if necessary  I can't currently view the log myself, nor do I know the first thing about factmsieve.py.

20160115, 22:41  #11 
Sep 2008
Kansas
2×5×367 Posts 
Just some casual observations.
Some of the specialq was reworked when changing threads. The duplicate rate is rather high (35%) so something is amiss. Not to worry. Code:
found 6990856 duplicates and 13157555 unique relations Since you are not that familiar with the script, I would just let it continue. You may need 120130% of the initial estimate of 18M relations. 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Announcement: New server coming online (estimated 20170811)  Madpoo  PrimeNet  43  20170906 04:19 
Question about Estimated Days to Complete  Mark Rose  GPU to 72  5  20131004 06:12 
Estimated completion dates  Yura  Software  3  20121113 19:45 
ECM Takes far longer than estimated time  Rhyled  PrimeNet  31  20110206 16:46 
More relations mean many more relations wanted  fivemack  Factoring  7  20070804 17:32 