processed dc and tc posts

[kruoli]

Originally Posted by Uncwilly

Why are you DC'ing these up there?

Quoting from another thread:

Originally Posted by kriesel

I'm attempting to fill in double checks for LL and for PRP from the current state to where there's at least one of each for every million-exponent-range bin up to 200ell ahead of the first-test wavefront. https://www.mersenneforum.org/showpo...77&postcount=3 https://www.mersenneforum.org/showpo...81&postcount=6

[kriesel]

Originally Posted by Uncwilly

Why are you DC'ing these up there?

As a sort of QA. If there are bugs remaining, whether it's just fft limits set to too high an exponent or something else, it would be good to find and address them before the many first-test production systems get to the exponent ranges affected. 109M are already being assigned by the hundreds. Before I resumed targeted scattered DC, there was only maybe 18 months between the first-test wavefront and the upper limit of ~1M-spaced targeted LL DC for QA. There's a clump of over 160 first-tests done at ~143M with no DC yet, almost all PRP with 0 shift, a mix of type 4 and type 1, by one user. (The 100Mdigit area has over 900 done, with 7 DCs.)
Since there's still a mix of PRP and LL being done, both are being filled in with scattered DC.
Very little PRP DC has been done. Several bins now in the current first-test wavefront 90-110M have had no matching PRP DC completed yet. More at:
LL https://www.mersenneforum.org/showpo...78&postcount=4
PRP https://www.mersenneforum.org/showpo...81&postcount=6
(and see the work distribution map at https://www.mersenne.org/primenet/)

[kriesel]

Originally Posted by Viliam Furik

PRP won't double-check LL tests...

Maybe you already understand this, but multiple Gerbicz-checked PRPs completed without any EE occurrences is a good way to "test drive" the hardware, gpu and application tuning, etc. for reliability before attempting LL on the same setup. Ideally with similar exponents so they're done with the same fft length, since it's possible to tune the application for performance in a way that makes errors more likely on a different fft length.
You're quite right that mixing LL and PRP on the same exponent is not efficient. They may both say composite but that doesn't mean either is correct as completed. Matching res64, computation type, residue type is much stronger.

[Uncwilly]

Originally Posted by Viliam Furik

Plus, PRP won't double-check LL tests...

Originally Posted by kriesel

Maybe you already understand this, but multiple PRPs completed without any EE occurrences is a good way to "test drive" the hardware,

Some users like doing DC's to help clear the bottom end up. Right now those are all LL's on the bottom.

[kriesel]

Some users like doing DC's to help clear the bottom end up. Right now those are all LL's on the bottom.

Me too. Milestones near!
Stable kit's best.
ECC ram on cpu side, well tested reliable setup help, bad results don't. PRP until reliable, then LLDC is productive. But each user's call.
I've placed a 145M LL TC with someone. Probably won't affect low-exponent throughput here.

[ewmayer]

Originally Posted by Uncwilly

EW Meyer done exponents that may have errors.

.

BTW, just did a final-status check on the "suspect LL results from my flaky Haswell system (since put out to pasture doing just system-tasks for gpuOwl runs on the R7 GPU I installed in the box earlier this year). Here they are, not as bad as I initially feared, "just" 4 of 35 initial-LL results proved bad:
Haswell LL results needing DCs:

Exponent	ewm submitted on	ewm result		shift	current-DC-assignee/last-update
74974717	2015-07-23 03:00	B5D9219DDA5F1E__	0		match
74974961	2015-07-23 03:00	F659D72393B68D__	0		match
76095269	2016-02-22 08:44	46851FC5879C8A__	0		match
76095727	2016-02-22 08:44	A92EC4A2208AF4__	0		match
80862581	2017-12-16 23:59	C50895D8698720__	0		match
80862739	2017-12-16 23:59	4A74D6080CC9C0__	0		bad
81356593	2018-01-11 00:44	4CED8E610C5680__	0		match
81356621	2018-01-23 23:56	C9EE8ABD52DBD1__	0		match
81489533	2018-01-23 23:56	53CAC649260C99__	0		match
81489643	2018-02-19 01:33	EE9AA266BAF2C5__	0		match
82261939	2018-02-25 01:16	70421560D74445__	0		match
82261957	2018-03-08 06:53	399BE4206CB1B7__	0		match
82701683	2018-03-26 02:16	1D3151F372C59F__	0		match
85836229	2019-01-04 04:28	E208B13089B37F__	0		match
85836271	2019-01-04 04:28	94648F6B800C30__	0		match
85836449	2019-01-04 04:28	945EF467CCFE2B__	0		match
85836847	2019-01-04 04:28	A3A6EF6EC9E6CA__	0		match
85836869	2019-01-04 04:28	0710B4E14DC4CF__	0		match
85836871	2019-01-04 04:29	B70A1A8D056298__	0		match
85836953	2019-01-04 04:29	544DCA37645C14__	0		match
86313749	2018-12-27 06:58	C01302C6444441__	0		match
86313833	2019-01-07 07:42	236AB1B7F27908__	0		match
86660489	2019-07-08 03:06	60549BE75AB34B__	0		match
86660533	2019-07-28 05:07	5834D82AEB7A2E__	4392243		match
86660569	2019-08-30 05:35	83BC88FF8E5542__	45526406	match
86687009	2019-04-02 19:01	F758FD5F7F7DB3__	9961107		match
86687099	2019-03-10 21:38	E4F9565BBA645C__	58101078	bad
86695813	2019-06-19 05:59	840C9A84963608__	17568972	match
86749163	2019-08-15 18:32	7CBDF51C9A915D__	55111967	match
89493361	2020-01-20 02:34	DE1386EF6213A5__	48305317	match
89522501	2019-12-23 19:17	28FB263CDCAB24__	13206906	match
89575217	2020-02-10 20:56	873C9D0059FD91__	6603453		bad
89575379	2020-01-02 20:18	E06B3C3EEADACD__	30089138	match
89604341	2019-11-01 23:08	FA91DCBF5B6477__	26413812	bad
89614489	2019-12-26 02:00	B80DC2EE52E628__	31334545	match

Special thanks to ATH and endless_mike for their DC/TC heavy-lifting here.

[LaurV]

Originally Posted by moebius

Really not from LaurV?

I wish haha!

(at least, to have his money )

Seriously speaking, and probabilistic, to how many assignments he did and is doing, and running random machines, I think that the overlap is quite insignificant, I would expect one or two orders of magnitude higher self-DCs from him. But he is not actually running DCs, he is doing only the "mandatory" number of them, periodically assigned by the server "to check his hardware", which would explain it (OTOH, in context of random cloud computers, mandatory DC makes no sense anyhow, but the server doesn't know it).

[Mark Rose]

Instructions for the top post for mprime:

• Grab the lines of the exponents that you will do.
• Stop mprime.
• Edit your worktodo.txt, inserting the new lines, save it, and close the editor.
• Delete the line starting with `LastEndDatesSent=` in `local.txt`.
• Run `mprime -c` for force communication, and watch for errors: exponents that didn't get assignments should be removed from `worktodo.txt`.
• Restart mprime.

[Uncwilly]

Originally Posted by Mark Rose

Instructions for the top post for mprime:

Updated

[Runtime Error]

I took these as LL-DC. Given that there are already two [non-matching] LL results, the probability that I also mismatch is likely less than the PRP-VDF overhead, right? I suppose it probably makes sense to continue the Triple Check list as LL.

DoubleCheck=87815327,76,1
DoubleCheck=87829211,76,1

DoubleCheck=88053461,76,1
DoubleCheck=88303121,76,1
DoubleCheck=88303129,76,1

DoubleCheck=89223679,76,1
DoubleCheck=89224147,76,1
DoubleCheck=89833343,76,1

PS: Thank you for splitting off the PRP-VDF and DC thread, although it seems to have devolved into a thread about patches. Anyway, it is a very exciting development!

[Uncwilly]

Originally Posted by Runtime Error

Given that there are already two [non-matching] LL results, the probability that I also mismatch is likely less than the PRP-VDF overhead, right? I suppose it probably makes sense to continue the Triple Check list as LL.

I concur doctor.