2020 “small” 15e post processing reservations and results

[chris2be8]

f20_193p1 has built a matrix. About 49 hours remain so I should have a result on Wednesday or Thursday depending on how many square root steps it takes.

Chris

[swellman]

Originally Posted by swellman

Yes. The data file is corrupt. I will attempt repairs with gzrecover once my Linux box finishes another job in a day or two.

23_193m1 has been repaired, and it lost ~10M rels as a result. 257M of those are unique.

Failed to build a matrix with TD of 120, attempting 114 now. I’ll keep dropping TD until this job goes into LA.

[swellman]

23_193m1 finally made it into LA @TD=108, ETA 918 hrs (~Jan 1).

[unconnected]

C172_785232_11530.dat.gz is broken, running gzrecover.

[VBCurtis]

Originally Posted by swellman

23_193m1 finally made it into LA @TD=108, ETA 918 hrs (~Jan 1).

Sounds like way too big a matrix for an e-small job. Maybe add 10MQ, if you haven't already moved it to post-processing?
Or, we could do some sieving locally. Let's knock off at least a week from that matrix solve-time- I'm game for an experiment about the tradeoff between sieving and matrix here, e.g. does a machine-week of sieving shorten the matrix by a week?

[jyb]

Originally Posted by VBCurtis

Sounds like way too big a matrix for an e-small job. Maybe add 10MQ, if you haven't already moved it to post-processing?
Or, we could do some sieving locally. Let's knock off at least a week from that matrix solve-time- I'm game for an experiment about the tradeoff between sieving and matrix here, e.g. does a machine-week of sieving shorten the matrix by a week?

I was actually wondering if the problem went the other way: 257M unique relations sounds like an awful lot for a 31-bit job. Is it possible that this is too much oversieved? Can you build a matrix with higher density if you cut down the relations to e.g. 210M? It's counterintuitive, but I've seen this sort of thing work before.

[RichD]

It is a 31.5 bit job or 31/32 hybrid. I think around 270M unique might be the sweet spot.

See https://www.mersenneforum.org/showpo...9&postcount=32.

[jyb]

Originally Posted by RichD

It is a 31.5 bit job or 31/32 hybrid. I think around 270M unique might be the sweet spot.

See https://www.mersenneforum.org/showpo...9&postcount=32.

Ah, indeed. I hadn't noticed that. Mea culpa.

[swellman]

Well, based on results to date, adding 20M+ Q should get this job to 270M uniques. I’ll keep bumping Q if yield degrades along the way but I suspect this job will reach that goal by the weekend.

Then I’ll start at TD=120 and drop by 4 until the job enters LA. We can explore unique rels vs TD and the resulting ETA.

If more rels are warranted then I’ll bump Q some more and repeat the process.

Shall I proceed?

[VBCurtis]

Definitely.
I think I'll do a little 10kQ test-sieve to see how much CPU time the extra sieving takes, to compare to matrix time saved.

The new queues and new organization rules are working nicely, but I remain interested in conserving boinc resources so that we can get more numbers factored. This sort of test helps give us a sense of how much public computation we're trading for our savings in private matrix-solving computation.

[swellman]

For the record, Q range was 20-190M. Just raised the upper end to 210M.