Estimated relations Factmsieve

cimpresovec · 2016-01-15, 20:26

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.

Batalov · 2016-01-15, 20:41

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.

cimpresovec · 2016-01-15, 20:46

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.

Batalov · 2016-01-15, 20:56

Something is not right with your configuration / threads, because your number of non-redundant 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

cimpresovec · 2016-01-15, 21:01

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.

Batalov · 2016-01-15, 21:05

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.)

cimpresovec · 2016-01-15, 21:17

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.

Batalov · 2016-01-15, 21:31

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 130-digit 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

cimpresovec · 2016-01-15, 21:39

Thanks for the help. I'll wait if someone else can advise.

Dubslow · 2016-01-15, 21:47

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 non-redundant. 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.

RichD · 2016-01-15, 22:41

Just some casual observations.

Some of the special-q was re-worked 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

Taking the above into account you are probably close to 90% done. (needing ~14.6M unique)

Since you are not that familiar with the script, I would just let it continue. You may need 120-130% of the initial estimate of 18M relations.

2016-01-15, 20:26	#1
cimpresovec 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.

2016-01-15, 21:01	#5
cimpresovec Jan 2016 2×5 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 2016-01-15 at 21:01

2016-01-15, 22:41	#11
RichD Sep 2008 Kansas 2⁴×211 Posts	Just some casual observations. Some of the special-q was re-worked 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 Taking the above into account you are probably close to 90% done. (needing ~14.6M unique) Since you are not that familiar with the script, I would just let it continue. You may need 120-130% of the initial estimate of 18M relations.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Announcement: New server coming online (estimated 2017-08-11)	Madpoo	PrimeNet	43	2017-09-06 04:19
Question about Estimated Days to Complete	Mark Rose	GPU to 72	5	2013-10-04 06:12
Estimated completion dates	Yura	Software	3	2012-11-13 19:45
ECM Takes far longer than estimated time	Rhyled	PrimeNet	31	2011-02-06 16:46
More relations mean many more relations wanted	fivemack	Factoring	7	2007-08-04 17:32

2016-01-15, 20:41	#2
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 2505₁₆ 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.

2016-01-15, 21:05	#6
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶×13 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.)

2016-01-15, 21:17	#7
cimpresovec 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.

2016-01-15, 21:31	#8
Batalov "Serge" Mar 2008 Phi(4,2^7658614+1)/2 3⁶·13 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 130-digit 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

2016-01-15, 21:39	#9
cimpresovec Jan 2016 A₁₆ Posts	Thanks for the help. I'll wait if someone else can advise.

2016-01-15, 21:47	#10
Dubslow 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 non-redundant. 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.