2018 14e post processing reservations and results

[VictordeHolland]

C222_44611351_31
= (44611351^31-1)/4724683554106950

p100 factor: 3129736754265434313115385777531815325426379555658941464347144096700868465629359448106263791728036343
p122 factor: 91817635573267857528245872303927479264638420438204782306659976328499199398619817645407854972158808897698702806939508021431
Mon May 28 02:07:00 2018  elapsed time 01:38:14

Factors uploaded to factordb.

Truncated log attached and at https://pastebin.com/rMC9HYfA

[richs]

Originally Posted by richs

Reserving C202_M127_k9

p89 factor: 28671472257842829465286850812061976846241333899857562772650872397788535503540554845502783
p113 factor: 37619677089167213926945303294913340200839420719711647589426226438636403067966427468055116925715974269789294823587

44.6 hours on 8 threads i7-5500U with 8 GB memory for a 6.13M matrix at TD = 70. Log attached and truncated log at https://pastebin.com/9rBxRU2v

Factors added to factordb.

[fivemack]

Wed May 30 08:07:13 2018  p81 factor: 212964755526353370590207528158400933000546039169480153256299393636587955035281223
Wed May 30 08:07:13 2018  p161 factor: 61183247576207084139117138075248634109518882435883583354592418681686857383102917177003213130369956245433740861835480483736679555168049838813731566460891903680881

About 277 hours on 7 threads E5-2650v2 for 22.42M matrix at density 124 (126 didn't work)

Log attached and at https://pastebin.com/Hi9RsY7w

[pinhodecarlos]

Taking C193_194xx723_13.

[debrouxl]

For C193_194xx723_13, the generated WUs cover the 6M-36M range, but the management form suggests an upper bound of 40M. I'll raise it to at least 38M.

[RichD]

While we are talking Q ranges, the following might be considered.

C221_691xx579_7 could use just a touch. The sweet spot seems to be about 228-236M for a 31-bit job. A matrix can be built at TD=110 which requires just under a week, instead of 1.5-2.0 weeks for something must less.
Likewise,
C169_203xx091_19
C217_69655517_29
C172_115xx057_17
could use a little bit more to get into that range.

I'm not too familiar with 32-bit jobs but it seems 450-460M might be the sweet spot. Therefore,
C176_M127_k24
could use a little bit more also.

[VBCurtis]

Originally Posted by RichD

I'm not too familiar with 32-bit jobs but it seems 450-460M might be the sweet spot. Therefore,
C176_M127_k24
could use a little bit more also.

In my experience with 32LP, 450M relations is always oversieved, and sometimes the matrix-building collapses. The number of relations needed scales with the difficulty of the candidate; something like 360M + 7M*(GNFS size - 170) is likely pretty close to optimal for TD-120+ matrix building.
Data points, all 32LP:
GNFS 170 275M relations 9.9M matrix (run on 15e -J 13, so 14.5e)
GNFS 166 274M relations 8.9M matrix TD 104
GNFS 165 265M relations 10.3M matrix TD 96
I sieved these all myself, so I used fewer relations and lower TD than I would for grid-sieved work. I don't think more than 25% oversieving is needed to build TD 120+ matrices.
Data points for 15e/33LP:
GNFS 172 529M relations 9.0M matrix TD 104
GNFS 175 556M relations 10.7M matrix TD 112
Two points is not a trend, particularly since I used different TDs, but based on these I'm using 510M + 10M* (GNFS size -170) for 15e/33 tasks. I'm running GNFS 179 right now, but using 15f and 16f for some of the sieving so the number of relations won't provide useful data.
EDIT: That C176 didn't have good parameters, and the sieving has already run to Q=750M. That suggests duplicate rate will be lousy too, but with Q already over twice the lim's we may collectively just have to eat the large matrix awaiting us (or sieve a little with 15e or 16e at the low end of Q-range). I'll have time to take it on in 10 days or so if nobody jumps before then.

[debrouxl]

* I have adjusted the ranges for C169_203xx091_19 and C172_115xx057_17 to match the ending Q values currently recommended by the management page. The latter will probably have to be adjusted again.
* the range for C217_69655517_29 matched the recommended range, but sieving hadn't reached 90% yet, and the grid's starving, so I expanded the range by 5M.
* the range for C221_691xx579_7 slightly exceeds the recommended range, and there were zero pending WUs, so I've let that sieving job RIP, and I've reserved it for post-processing, as I can't see another reservation in this topic.


Technically, the recommendations made by the management page could be adjusted if enough people agree that this is the right thing to do, and we can borrow a bit of time from Greg. Tom ? Others ?

[RichD]

I don't have enough data points for a recommendation. This is the job that recently came to mind.
http://www.mersenneforum.org/showpos...postcount=2700
It will be interesting to see how your job plays out as each job is unique in its own right.

[VictordeHolland]

Originally Posted by VBCurtis

In my experience with 32LP, 450M relations is always oversieved, and sometimes the matrix-building collapses. The number of relations needed scales with the difficulty of the candidate; something like 360M + 7M*(GNFS size - 170) is likely pretty close to optimal for TD-120+ matrix building.
...
...

Those are raw relations with normal duplicate rate I assume?

[VBCurtis]

Originally Posted by VictordeHolland

Those are raw relations with normal duplicate rate I assume?

Yes, raw relations under 14e (with its higher dup rate than 15e). I really really think 32LP should be used more instead of 31LP, with much lower than 400M relations targeted.