I suspect that on a local system, you wouldn't be able to tell the difference. But anyways, George will have to confirm if this is even possible or not.

[QUOTE=axn;575242]George, Would it be possible to reduce the size of P-1 stage 2 checkpoint files? Using this with colab / google drive, it takes a very long time to stop/restart during stage 2 - it writes 100-200 MB of save file. I am guessing it is somehow saving the stage 2 prime bitmap or something? I think it would be faster to recompute the state, rather than load it from disk (with google drive).[/QUOTE]

Theoretically possible but I'm very afraid I'd make a mistake. Even the most subtle change in initial state can affect how the primes are paired.

You might try MaximumBitArraySize=n in prime.txt. This limits the maximum bit array size to n MB (default is 250). This will have some negative impact on performance, make a few runs yourself to see if it is significant.

[QUOTE=Prime95;575274]You might try MaximumBitArraySize=n in prime.txt. This limits the maximum bit array size to n MB (default is 250). This will have some negative impact on performance, make a few runs yourself to see if it is significant.[/QUOTE]

Is it safe to change this in the middle of a Stage 2 run?

[QUOTE=axn;575536]Is it safe to change this in the middle of a Stage 2 run?[/QUOTE]

Probably. Never tested.

P95/mprime really needs a way to manually force a proof upload. I periodically have Wi-Fi issues on my laptop (my primary GIMPS computer), and would like a way to upload proofs (I do PRP-CF, so there are quite a few of them) that have backlogged while the Wi-Fi has been out (especially if it will go out again soon). Perhaps add it to the manual communication menu?

An unrelated gripe. I have 5 workers on 8 cores on my laptop. They're never all running at the same time (I run 3 max at a time, 2 cores each). But the benchmarks still use all 5 workers on all 8 cores, a usecase that never happens and causes inaccurate timing due to the core overlap and throttling. It also causes issues on my desktop, as it runs benchmarks with 3 workers on 3 cores, an unused-in-practice scenario which causes it to overheat (it's an old Core 2 box). Can you add a setting to tune the automated benchmarking to a particular worker/core combination other than the full max?

[QUOTE=Happy5214;575933]An unrelated gripe. I have 5 workers on 8 cores on my laptop. They're never all running at the same time (I run 3 max at a time, 2 cores each). [/QUOTE]
Then why not have just 3 workers (or 2 workers)? You're putting the program in an impossible situation. It'd be best to just turn off the benchmark altogether.

[QUOTE=axn;575935]Then why not have just 3 workers (or 2 workers)? You're putting the program in an impossible situation. It'd be best to just turn off the benchmark altogether.[/QUOTE]
Because I run 3 different work types in rotation (3 PRP-CF, 1 ECM, 1 P-1).

[QUOTE=Happy5214;575939]Because I run 3 different work types in rotation (3 PRP-CF, 1 ECM, 1 P-1).[/QUOTE]

Why not have just three workers and change their worktype as and when you want to switch over? Should be just as easy as bringing workers up/down.

Or ... Have two instances of P95 and keep PRP workers in one, and ECM/P-1 in another.

Anyway, with the current setup, your best bet is to just turn off automated benchmarking.

[QUOTE=Prime95;575562]Probably. Never tested.[/QUOTE]

I may have found a "bug" with the FFT speed or size or iterations.

I don't know if it's the same for 10900k (it probably is), but on 11900k, if you disable FMA3, AVX512F and AVX in local.txt and run a small FFT stress test, each loop (multiple loops per FFT size though) finishes in 1 minute. Example, small FFT -->48k, finishes each loop in 1 minute. After several loops it goes to the next FFT.

If you disable AVX512, AVX2 and AVX in the stress test options instead, each loop lasts I think 2 or 3 minutes.

So the loop speed is different if you disable all the AVX settings in local.txt (from undoc.txt) versus disabling them in the stress test options.

Is this intended?

I'm running a P-1 in stage 2, and it's saying it's 100% complete, but it's still running and printing "100% complete" reports at the normal rate. Is there a data issue or is this a problem with the printout that can be safely ignored without compromising the validity of the data until a fix is posted?