Quick question. I’ve been running PRP DC CF but I want now to change to PRP DC, what line on prime.txt I need to change, what’s the work ID type?

My concern is how to swap work type without having to have a clean client installation and going throughout the configuration process, what I’m failing?

[QUOTE=pinhodecarlos;554265]Quick question. I’ve been running PRP DC CF but I want now to change to PRP DC, what line on prime.txt I need to change, what’s the work ID type?

My concern is how to swap work type without having to have a clean client installation and going throughout the configuration process, what I’m failing?[/QUOTE]

Work type is 151.

The easiest way to change is ./mprime -m
or the Worker Windows dialog box in prime95
or even the web pages (list your CPUs, then click on the one you want to change)

That said, there is no longer a PRP DC work type. Selecting work type 151 will give you DC assignments. These can be LL or PRP at the server's discretion. I've not yet decided if we should LL the big backlog of DCs or PRP-proof them if the client is 30.3 or greater.

Ah or duh for the worker Windows dialog box....
Looks like I’ll have to stay with current work type since I can’t do LL DC if I get one, laptop temp just fires up, not with PRP. I would “ PRP-proof them if the client is 30.3 or greater.” but it is your decision.

[QUOTE=Prime95;554268]I've not yet decided if we should LL the big backlog of DCs or PRP-proof them if the client is 30.3 or greater.[/QUOTE]

Which, in your opinion, is more useful?

Doing a DC will point out borderline kit, but I think Aaron's years-long SDC effort has cleared out most of the known noise.

How trusting are you of the PRP-proof mechanism (I presume, based on the extensive collaboration and peer-review, quite)?

The call, of course, is yours. And if I may please say, this has been truly awesome to observe!

Agile in Action; almost a case-study. :tu: :bow:

[QUOTE=Prime95;554268]..I've not yet decided if we should LL the big backlog of DCs or PRP-proof them if the client is 30.3 or greater.[/QUOTE]

Both, until you go public with 30.x. Then PRP-Proof [U]all[/U] of them. At that point, LL and LL-DC can be retired. Over time, the backlog will shrink.

[QUOTE=chalsall;554270]Doing a DC will point out borderline kit, but I think Aaron's years-long SDC effort has cleared out most of the known noise.

How trusting are you of the PRP-proof mechanism (I presume, based on the extensive collaboration and peer-review, quite)?[/QUOTE]Since the LL DC is lagging several years behind LL first time testing, the identification of borderline or reliably-unreliable kit may come years too late. Unless there are enough error codes caught in the prime95 /mprime result's errors field. Which does nothing for Mlucas, CUDALucas, clLucas, gpuowl runs.
I'm doing a systematic sampling of PRP & PRPDC (spaced ~1 per million of exponent range up to 200M), and don't recall a PRPDC failing to match a PRP. Some of the PRP-DC in this sampling effort are PRP-with-power8-proof. Some of the future first-PRP in this sampling effort will be PRP-power8-proof & a Cert to verify, no separate DC.
(I had started with LL/LLDC sampling in 2017, and made PRP sampling ahead a priority this year. PRP samples have been finished 74M-128M, so now precede the wavefront somewhat.)

Of the ~20 bad primality tests I've logged over the past few years, none are PRP, all are LL/LLDC/LLTC.

[QUOTE=Prime95;554174]You do not need to re-arrange your worktodo.txt file. Cert work will get done quickly regardless of where it appears in the file.[/QUOTE]
That is not what I am experiencing. Just restarted mprime on my laptop and it got a new CERT test but then continued the the LL-DC which does not end before September:
[CODE]
[user@laptop mprime]$ ./mprime -d
[Main thread Aug 19 21:05] Mersenne number primality test program version 30.3
[Main thread Aug 19 21:05] Optimizing for CPU architecture: Core i3/i5/i7, L2 cache size: 2x256 KB, L3 cache size: 3 MB
[Comm thread Aug 19 21:05] Updating computer information on the server
[Main thread Aug 19 21:05] Starting worker.
[Comm thread Aug 19 21:05] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=uc&g=dc79f1c52374fcc10162f12141161ca
b&hg=870ede87c0fa98649457adec85d4ad59&wg=&a=Linux64,Prime95,v30.3,build+2&c=Intel(R)+Core(TM)+i5-6200U+CPU+@+2.30GHz&f=
Prefetch,SSE,SSE2,SSE4,AVX,AVX2,FMA,&L1=32&L2=256&np=2&hp=2&m=7831&s=2540&h=1&r=4000&L3=3072&ss=5848&sh=89989C1E7296CC4
D15C466366144D1AA
[Work thread Aug 19 21:05] Worker starting
[Work thread Aug 19 21:05] Setting affinity to run worker on CPU core #1
[Comm thread Aug 19 21:05] RESPONSE:
[Comm thread Aug 19 21:05] pnErrorResult=0
[Comm thread Aug 19 21:05] pnErrorDetail=SUCCESS
[Comm thread Aug 19 21:05] g=dc79f1c52374fcc10162f12141161cab
[Comm thread Aug 19 21:05] u=gLauss
[Comm thread Aug 19 21:05] un=gLauss
[Comm thread Aug 19 21:05] cn=laptop-klaus
[Comm thread Aug 19 21:05] od=10
[Comm thread Aug 19 21:05] ==END==
[Comm thread Aug 19 21:05]
[Comm thread Aug 19 21:05] Sending expected completion date for M57643127: Sep 28 2020
[Comm thread Aug 19 21:05] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ap&g=dc79f1c52374fcc10162f12141161ca
b&k=27481014FF4CCAAE79090BF22E599FFE&stage=LL&c=0&p=33.7369&d=86400&e=3465350&ss=12763&sh=0D9E42398ECDEB1470895F7BADAE6
A58
[Work thread Aug 19 21:05] Setting affinity to run helper thread 1 on CPU core #2
[Comm thread Aug 19 21:05] RESPONSE:
[Comm thread Aug 19 21:05] pnErrorResult=0
[Comm thread Aug 19 21:05] pnErrorDetail=SUCCESS
[Comm thread Aug 19 21:05] ==END==
[Comm thread Aug 19 21:05]
[Comm thread Aug 19 21:05] URL: http://v5.mersenne.org/v5server/?v=0.95&px=GIMPS&t=ga&g=dc79f1c52374fcc10162f12141161cab&c=0&cert=10.000000&ss=33072&sh=9F58D7017E911849EE1BC3F8F6B8E52D
[Comm thread Aug 19 21:05] RESPONSE:
[Comm thread Aug 19 21:05] pnErrorResult=0
[Comm thread Aug 19 21:05] pnErrorDetail=Server assigned CERT work.
[Comm thread Aug 19 21:05] g=dc79f1c52374fcc10162f12141161cab
[Comm thread Aug 19 21:05] k=4C8A4BBDFCBAFE2E7D6A480657D4DFE3
[Comm thread Aug 19 21:05] A=1
[Comm thread Aug 19 21:05] b=2
[Comm thread Aug 19 21:05] n=4991983
[Comm thread Aug 19 21:05] c=-1
[Comm thread Aug 19 21:05] w=200
[Comm thread Aug 19 21:05] ns=39000
[Comm thread Aug 19 21:05] ==END==
[Comm thread Aug 19 21:05]
[Comm thread Aug 19 21:05] PrimeNet success code with additional info:
[Comm thread Aug 19 21:05] Server assigned CERT work.
[Comm thread Aug 19 21:05] Got assignment 4C8A4BBDFCBAFE2E7D6A480657D4DFE3: CERT M4991983
[Comm thread Aug 19 21:05] Done communicating with server.
[Work thread Aug 19 21:05] Running Jacobi error check. Passed. Time: 22.509 sec.
[Work thread Aug 19 21:05] Resuming primality test of M57643127 using FMA3 FFT length 3M, Pass1=512, Pass2=6K, clm=2, 2 threads
[Work thread Aug 19 21:05] Iteration: 19447019 / 57643127 [33.73%].

[/CODE]

[QUOTE=keisentraut;554280]That is not what I am experiencing. Just restarted mprime on my laptop and it got a new CERT test but then continued the the LL-DC which does not end before September:[/QUOTE]

Have you just let it run for a while, and then review the logs to see what George's code does in the temporal domain (without any human interaction)?

If not, give it a try...

[QUOTE=kriesel;554277]Since the LL DC is lagging several years behind LL first time testing, the identification of borderline or reliably-unreliable kit may come years too late. Unless there are enough error codes caught in the prime95 /mprime result's errors field. Which does nothing for Mlucas, CUDALucas, clLucas, gpuowl runs.[/QUOTE]

In my world, all data is interesting.

But, as you suggest, some might not be worth collecting in the bigger calculus (economic tradeoffs, expediency, etc).

henryzz question really perked up my ears. Is this seminal? Worth formally publishing?

edit: Discussion split into new thread. Henryzz's question is at [url]https://mersenneforum.org/showthread.php?t=25852[/url]

If doing PRP-VDF's on the low end of the DC's is a good idea.....

It might be worth moving the assignments for v29 and below up to some set value (like 65,000,000) and above once v30 comes online (or after there is a 50% adoption of v30).
Or move them 10 or 15,000,000 above the DC milestone.
Or move them up 1,000,000 above the milestone each and every month for about a year and a half (first month 1M above, second month new assignments 2M above, 3rd 3M,

They will still get DC work done, but they will get moved away from the milestones enough so that these old slugs won't interfere.

Build 3 is available. See first post in this thread for links.

Not a whole lot there. Two bugs fixed as detailed in post #2 of this thread. Mihai improved P-1 probability calculator. You can opt out of CERT work in the worker Windows dialog box. There are undoc settings for controlling the exponent sizes you get for CERT assignments.