C321_149_146: Ready for SNFS

[pinhodecarlos]

Originally Posted by swellman

No word from Greg on my query. I just assumed he was busy/not interested in pursuing this job.

Just left him a message, hope he comes back here to the thread.

Hey Curtis, any estimates figures yet?

Edit: he has seen the thread....

[VBCurtis]

I don't see any records for this; I think I decided to wait for an indication of interest from Greg, since Ryan is not available presently. I'll have some time this weekend for test-sieving.

This candidate is difficult enough that it may be worth using CADO with I = 17 on the smallest Q values, as a team sieve outside of NFS@home. Of course, we'd need quite a few cores available to CADO to make a dent.

Are parameters handy for the largest previous nfs@home factorizations? I'd benefit from a starting point for testing, particularly for alim/rlim. Does 536M/800M seem reasonable?

Edit: I don't quite grasp poly creation for this form. Is a septic possible?

[pinhodecarlos]

I don’t have access to the 16e V5 data server but I can ask Greg.

Was looking at previous jobs, 2,1285- (GNFS218), and Greg queued from q=260M to 3700M on sieve range. I’ll dig about alim and rlim.

[frmky]

I won't have any room for it for at least a few months. I'll revisit it then.

[pinhodecarlos]

Originally Posted by frmky

I won't have any room for it for at least a few months. I'll revisit it then.

I suppose for LA but my brain already failing at this hour to understand that expression (capacity), can you elaborate?

[VBCurtis]

I spent a few hours deciding that the regular 16e siever would not be able to factor this number; as far as I know, it can only sieve Q up to 2G (not sure if binary or decimal G). 2000M special-Q range is not sufficient to gather enough relations, no matter the large-prime settings.

Using 16f with -d 1 (the setting to stick to prime special Q), I've done just a bit of testing. I haven't determined whether 3 large primes should be used on both sides, or just on rational side. I think 35-bit LP is the highest we can safely go with msieve, as 36 might require more than 4G raw relations. I think 35/36 hybrid needs fewer than 4G, and I'll test that against 35 as well.

Initial tests suggest 35/99 on rational side and 36/71 on algebraic side might be best, or perhaps 35/69 or 35/99. Still to-do is exploring exactly what mfbr is best with lpbr; I guessed 99 to get started, but anything from 97 to 102 is possibly best.

A short (7 samples across the Q range) with 35LP and 99/69 mfb's suggests sieving 20M to 2100M should produce roughly 2600M raw relations. Yield above 2000M is roughly 0.8 to 1.0, so if 3000M relations are needed we can get that by sieving to 2500-2600M. A fast desktop should find about 1 sec/rel with these settings.

I'll have more to report about yields of various mfb settings when I have more time.

[VBCurtis]

Carlos emailed frmky and cc'ed me about the 16e NFS@home queue, and Greg explained that for reasons of client memory use and server space use he prefers to go no higher than 34LP for NFS@home projects.

So, we face a choice: wait for Greg to have interest and an available slot to run this number (with LA an open question) with 34LP and small lim's, or try some sort of nutso team-sieve with larger params.

With my previous estimate of 2.5G thread-seconds of sieving, I don't think there's enough interest in a team sieve. I am willing to contribute ~100M thread-seconds worth of CADO 17e time on the smallest Q, which may be something like 50% more effective than GGNFS 16e; that's still only 5 or 6 % of the required sieving, and LA would still be an open question.

A team sieve has the possible interest of being among the first to use large LP bounds (bigger than 34) to complete a factorization; only the CADO group has done so previously for their published papers. We'd be the first "users" to do so, whether we use CADO or GGNFS (or both, more likely) to sieve.

Before Greg's email, it hadn't occured to me to check GGNFS memory usage. With rlim=800M and alim=1076M, 16f uses 2.5GB per process!!!! No wonder Greg restricts alim and rlim to be much tighter than my testing.

My next test-sieve will be with alim=rlim=536M and 34LP to see how yield looks (and thus estimate required Q to get 1600-1800M relations). Not sure 536M is gentle enough on RAM, but I'll report memory usage as well.

[RichD]

Whoa, this is a BIG job.

I thought about offering an i5 or two but realized 100M thread-seconds would be a little over nine months for a single Core-i5 box. I have 16GB on each machine so a 2.5GB process is not a problem. I would be removing them from the the smallest post-processing NFS@Home queue during that time. Maybe not a good idea.

I didn’t realize a 34LP siever is in the public domain. (Shameful plug coming.) OPN has a Most Wanted number for well over a decade at SNFS-301. Ryan tried his hardest to get enough relations as a 33LP job but failed. Perhaps this could be a stepping stone.

One a side note, I thought about upgrading to a Core-i9. I have no experience with water cooled systems. It would be nice to have a 12, 14, 16-core box but it would need 32 or 64GB of DDR4 memory. May still not be enough for the bigger LA jobs.

Edit: The SNFS-301 is an octic by degree halving. Traditionally it would be an SNFS-338 with degree 6.

[VBCurtis]

Henryzz has compiled regular 16e with 33LP limit removed; it was as simple as removing a flag to check, according to his posts. I believe he also sent me 15e with 33LP removed, which I plan to try on a SNFS-900bit number as 34LP one of these days.

I got the 16f siever from an old thread around the time frmky expanded nfs@home to use it. Both are windows exe's; I haven't located a linux copy yet of either one, or if I have I forgot about it. So, I do my test-sieving for 34LP+ on a Broadwell ultrabook, my only Windows machine.

CADO supports any large-prime size; their factorization of RSA-768 used mfba = 140 and four 40-bit large primes! mfbr was 110 and three 40-bit primes were admitted on the rational side.
Edit: I noticed that in my initial test-sieve mentioned above, I failed at mental math and used 1076M as 2^30 rather than 1072M. So, I managed to pick alim just *over* 2^30, which can't be good with GGNFS. I doubt I'll repeat the test-sieve, as NFS@home is likely the only path to getting this done so I'd rather put effort into smaller lims. I tested alim=rlim=536M, and memory use is 1550MB with 16f. Now I see why Greg suggested 268M for each lim!

[VBCurtis]

Originally Posted by RichD

I didn’t realize a 34LP siever is in the public domain. (Shameful plug coming.) OPN has a Most Wanted number for well over a decade at SNFS-301. Ryan tried his hardest to get enough relations as a 33LP job but failed. Perhaps this could be a stepping stone.

Do you have the relation set Ryan generated? Perhaps we can finish it with CADO, since the CADO tools do well with large Q values. We can just keep sieving above the last Q Ryan completed.

If the relation set is almost sufficient (say, 800M or more raw 33LP relations), we should be able to finish this. My main concern is that CADO seems to demand a lot of memory for the LA phase, and my biggest machine only has 32GB. We may need to learn how to convert CADO-format relations to msieve-format, and only use CADO for sieving.

[RichD]

Originally Posted by VBCurtis

Do you have the relation set Ryan generated? Perhaps we can finish it with CADO, since the CADO tools do well with large Q values. We can just keep sieving above the last Q Ryan completed.

If the relation set is almost sufficient (say, 800M or more raw 33LP relations), we should be able to finish this. My main concern is that CADO seems to demand a lot of memory for the LA phase, and my biggest machine only has 32GB. We may need to learn how to convert CADO-format relations to msieve-format, and only use CADO for sieving.

I don't think he kept them. He ran the sievers until the yield dropped to near zero. This was six-to-eight-plus months ago. I haven't heard from him in quite a while.