Not sure if this was reported or maybe even fixed in the last versions, I still have few computers using v30.3, and sometimes, for whatever reasons, they can't connect to the server (it may be network/rights related, my IT guys get paranoid sometimes, which is not a bad thing). The worktodo is therefore exhausted and the computers are waiting to get work for days (usually, over the weekend, when I can't attend them).

What I found out repeatedly is that in such case the computers can't connect to the server ever, even if P95 is restarted, but they will connect to the server if the spool file is deleted (moved to another folder), even if that is done during P95 runs. Putting the spool file back - error, can't connect to the server. Taking it out, no issue, connect, get new assignments, put it back, can't connect (but the work is progressing normal, and proof files are stacked up locally - especially for PRPCF assignments, which take little time to finish).

First time (second time, third time) we assumed that the spool file got malformed or it suffered some damage, so we just deleted it and continue from there. We tried first to recover unreported stuff from it, using a hex editor (which was quite successful). But the issue re-appeared few more times, therefore we decided to zip such file and keep it.

The file will crash the P95 connection if we unzip it in P95 folder, regardless of computer (i.e. if we put it on another computer, that will not be able to connect to the server and get and/or report work either).

@George: do you need it? (maybe to track what happens, etc), the zip is 7360 bytes (i.e. not big).

If the worker window estimates 31 days to go on a 50M fft CERT, why does the client tell the PrimeNet server it has one day to go?
If it has a month of high priority 50M fft CERT work to do, why does it interrupt that to run unneeded-for-a-month-at-least 3360K and 3456K benchmarks?
Will v30.7bx address these?
Are there settings I can apply to address them in v30.6b4?

[QUOTE=LaurV;590225]
The file will crash the P95 connection if we unzip it in P95 folder, regardless of computer (i.e. if we put it on another computer, that will not be able to connect to the server and get and/or report work either).

@George: do you need it? (maybe to track what happens, etc), the zip is 7360 bytes (i.e. not big).[/QUOTE]

Sure. PM me and I will look into it.

[QUOTE=kriesel;590250]If the worker window estimates 31 days to go on a 50M fft CERT, why does the client tell the PrimeNet server it has one day to go?
If it has a month of high priority 50M fft CERT work to do, why does it interrupt that to run unneeded-for-a-month-at-least 3360K and 3456K benchmarks?
Will v30.7bx address these?
Are there settings I can apply to address them in v30.6b4?[/QUOTE]

30.7b5 will send the estimated completion date as shown in Test/Status (which in your case is much sooner than 31 days). Auto-bench, test/status, and server estimated completion dates will all assume CERT work executes before other work types.

For now, in 30.6b4 you can turn auto-bench off.

[QUOTE=Prime95;590131]FYI2: Brent-Suyama is no more.[/QUOTE]

I noticed it's not mentioned in [C]undoc.txt[/C] anymore. I'm guessing it's been completely removed from Prime95?

[QUOTE=Prime95;590259]30.7b5 will send the [B]estimated completion date as shown in Test/Status (which in your case is much sooner than 31 days)[/B]. Auto-bench, test/status, and server estimated completion dates will all assume CERT work executes before other work types.

For now, in 30.6b4 you can turn auto-bench off.[/QUOTE]

But that's not the correct completion date. The 31-day estimate by the worker is the correct one.

[QUOTE=Prime95;590259]30.7b5 will send the estimated completion date as shown in Test/Status (which in your case is much sooner than 31 days). Auto-bench, test/status, and server estimated completion dates will all assume CERT work executes before other work types.

For now, in 30.6b4 you can turn auto-bench off.[/QUOTE]Thanks. Looking forward to b5 or 6.
From prime.log:

[CODE][Fri Oct 8 09:13:18 2021 - ver 30.6]
Updating computer information on the server
Sending expected completion date for M843112609: Oct 8 2021
...
[Tue Oct 12 08:23:44 2021 - ver 30.6]
Updating computer information on the server
Sending expected completion date for M63367621: Oct 16 2021
Sending expected completion date for M843112609: Oct 12 2021[/CODE]Oct 12 ~1:15 pm local, downed briefly to update to v30.7b4 (can't download v30.7b5 yet)
otherwise it's been running 24/7, and is now ~12.57% complete.
So linear extrapolation from ~4.17 days to 12.57%, 12.57/4.17 * 87.43 remaining ~ 29.0 days more, Nov 10.

I note during adding to prime.txt,
AutoBench=0
that v30.6b4 had apparently flipped my manual prime.txt setting from
WorkPreference=155
to
WorkPreference=151
without my knowledge. Reset that while in the editor.

Upon resumption of the big CERT with V30.7b4, test/status claims completion late on Oct [B]15[/B], ~3.3 days. Better than claiming same-day or next-day, but still seems ~8.8x too soon.
And what it reports to the server is next-day.
[CODE][Tue Oct 12 13:37:07 2021 - ver 30.7]
Exchanging program options with server
Updating computer information on the server
Sending expected completion date for M63367621: Oct 17 2021
Sending expected completion date for M843112609: Oct [B]13[/B] 2021[/CODE]

[QUOTE=kruoli;591583]It is completely stuck, every hour it states:
[CODE][Worker #3 Oct 25 18:26] Restarting worker to do priority work.
[Worker #3 Oct 25 18:26] Resuming.
[Worker #3 Oct 25 18:26] No work to do at the present time. Waiting.[/CODE]

I release this reservation.[/QUOTE]

What could have caused that certification to be unable to begin?

This was 30.6b3, Windows 7, Intel i7 3630QM. CPU-hours was set to 8.

Additional information:
[QUOTE=kruoli;591529]I have CertWork=1, upload and download limits to really high values, CertWork[B]er[/B] is set to the according worker etc. […] Prime95 shows no network activity.[/QUOTE]

Don't know if this has been resolved in later Prime95 versions, but I found a minor edge case issue: if you pause a worker during a Jacobi error check on the last iteration of a LL test, then the worker only stops after finishing the error check and completing the few first iterations of the next exponent. It only affects double checks as the Gerbicz error check for PRP tests is near-instantaneous.

Time to unsticky?
 

Since v30.7 became the current release, how about unsticky this thread?