mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Msieve (https://www.mersenneforum.org/forumdisplay.php?f=83)
-   -   Estimated relations Factmsieve (https://www.mersenneforum.org/showthread.php?t=20851)

cimpresovec 2016-01-15 20:26

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.

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

1 Attachment(s)
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[/CODE]

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[/CODE]
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.


All times are UTC. The time now is 00:59.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.