mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   News (https://www.mersenneforum.org/forumdisplay.php?f=151)
-   -   The Next Big Development for GIMPS (https://www.mersenneforum.org/showthread.php?t=25638)

Uncwilly 2020-08-01 01:02

Minor suggestion.

In the [FONT="Courier New"]Advanced>Manual Communication[/FONT] dialog box, I think a check box something akin to "Upload proof file(s) now." would be worthwhile.
I can foresee 2 or 3 situations that one might want to do that.
1. They found a PRP probable prime.
2. They currently have comms, where they may not normally have it.
3. The machine may be shut down during normal comms time.

Mark Rose 2020-08-01 01:42

It looks like readme.txt from the mprime tarball hasn't been updated in a while. In addition to the new awesome things, it's missing the various copyright notices that are in the Windows version, and it may be easier to redo the mprime version from scratch.

One thing that may not be copied over from the Windows version is the missing mprime.pid in the FILE LIST.

I also think this phrase is probably dated: "checksum to guard against email transmission errors". The word email could be omitted from all instances of the phrase.

Otherwise, the Windows version of readme.txt looks great!

Uncwilly 2020-08-01 02:35

Several VDF's (for PRP-CF) uploaded. One has already had the cert run (by George). Another is assigned to George. One has yet to be assigned.

Looks good.

S485122 2020-08-01 07:44

[QUOTE=Prime95;552155]...
This is much closer to a beta version.
...
LL work preferences are gone, if you upgrading, your LL work preferences will be converted to PRP.
...
Suggestions for further changes are welcome. I have a few ideas I'll put forward soon.[/QUOTE]Some of the suggestion I wished to make have already been addressed [noparse]:-D[/noparse] Nevertheless I will leave the text I prepared as it is. Of course this only represent my opinion, where I write "should", "must, ... it should be understood with an implicit "in my opinion" when not explicitly stated.

At the moment PrimeNet users can choose two work types for several categories of first time tests :
"First time LL tests" and "First time PRP tests"
"World record LL tests" and "World record PRP tests"
"100 million digit LL tests (not recommended)" and "100 million digit PRP tests"

In my opinion they should have been joined since the moment PRP was operational and reliable, with the PRP capable software getting the PRP variant and older software still getting LL tests.

The available test type requests would be :
"First time primality tests"
"World record primality tests"
"100 million digit primality tests"
The assignments would, of course be different for PRP and LL. The manual assignments pages could keep the distinction since only the user knows the software that will be used.

Since 100M digits LL is not recommended it would be logical that it should not be available from PrimeNet (not even for manual testing.)

Double checking would follow the same path, but this is less urgent because of huge amount of LL tests still to be verified.

Now a new work type is introduced : PRP-VDF.

Again as soon as PrimeNet and the software are adapted, fully operational and reliable, the server should give PRP-VDF assignments in the three categories to all software capable of that type of tests. I think it premature to limit first time tests to that type of work. It can be done once a significant proportion of users have the right software. There is a caveat though : the upload of 100 MBytes (1 Tbits) files changes a lot in bandwidth requirements compared to the "ordinary" primality testing, it will impact, sometimes seriously, those users that do not have a lot of bandwidth, this shouldn't be dismissed by the specious argument that "everybody has fibre and 5G nowadays". The same goes for the temporary disk space : when helping users with their computers I see a lot of systems that have less than 10 GB free disk space, they should have more, especially on SSD's, but still... Those two factors mean it is premature to impose that new work type to all.

A useful information would be the breakdown of LL and PRP work done by software version for the last year for instance. It might be interesting to have the big users separately.

Then, should certifying be a separate work type or should a user asking for primality tests get certifying work units as well ?

Some thoughts about PrimeNet
Since the advent of PRP-VDF implies a complete overhaul of the PrimeNet server, the different scripts, reports and queries available ... it could be the time to ensure that exponents in CAT 0 and CAT 1 will not be given by the server to a user requesting manual testing TF work (be it on the "ordinary" page or the GPU page.)

Then, I regret that the status of a primality test changes once the corresponding number is factored : the test is still Unverified, Verified or Bad. Factorisation should not "destroy" that information, it is a characteristic of the Mersenne number not of the PRP or LL tests.

Some do not find the reports about factorisation very clear. One thing I have always regretted is that there is no indication for those Mersenne numbers that have been fully factored. Except, of course, for the Mersenne Primes, but for those the different primality tests by the finder and those that did the verification runs do not show up...

Jacob

Prime95 2020-08-01 08:34

FYI: I've disabled the server's proof processing while I fix a problem. 3 proofs did not verify and the problem is on the server. Proofs will still upload and will be processed later -- probably later today.

kruoli 2020-08-01 12:07

[QUOTE=Prime95;552160]Paging Oliver:

Did anything strange happen during the run of 10471007? The proof failed certification. Do you have the proof file by chance?[/QUOTE][QUOTE=Prime95;552183]FYI: I've disabled the server's proof processing while I fix a problem. 3 proofs did not verify and the problem is on the server. Proofs will still upload and will be processed later -- probably later today.[/QUOTE]

So that's not something on my side? In any case, I uploaded the file to my server [URL="http://mc.oliver-kruse.de/GIMPS/proofs/pA471007.proof"]here[/URL]. I used this script to upload files automagically:
[CODE]while sleep 1m;
do
if ! find ../301b1 -name '*.proof' | egrep -q '.+';
then
continue;
fi;
echo 'Dateien vorhanden!';
for f in $(ls ../301b1/*.proof);
do
echo $f, schlafen...;
sleep 3m;
../Uploader/uploader.exe manoli94 $f;
mv $f .;
done;
done[/CODE]

I needed to add some sleeps because the script was trying to upload proof files that were currently written. If it was acessing the proof file in a bad moment, this might have caused the issue.

Prime95 2020-08-01 15:38

[QUOTE=kruoli;552186]So that's not something on my side?.[/QUOTE]

Correct. My fault. Server getting roundoff > 0.5.

1) Detecting this and recovering was on my to-do list.
2) I asked the FFT routines to be extra safe in selecting FFT length. I think I got the sign backwards and asked it to be extra risky. Not a good combination given #1.

kriesel 2020-08-01 19:15

Seems like the time is near for a V30 prime95 thread in the software subforum. Some of the content here could plausibly fit there.

Runtime Error 2020-08-01 19:50

Etiquette for PRP-VDF w/ Manual Testing
 
[I](I know v30 is a work in progress; sorry if I'm jumping the gun here.)[/I]

What is the recommended process for uploading proofs from manual testing assignments?

Out of curiosity, I tried to upload proof files [U]before[/U] submitting the results on the website. I copy-pasted the proof files onto the same folder as Prime95 on a machine with Internet connectivity and restarted the Prime95 instance. It threw an error and refused to upload the proof files. Once I actually did submit the manual results, I restarted Prime95 again, and it is now uploading my proof files.

Will there be a more elegant way to upload proofs from manual testing? Thanks!

Also, Could we possibly add a way to see if a proof file has been uploaded to the website? Like some form of "no proof file left behind" sanity check for us who use manual testing? Otherwise, I will inevitably lose a proof file somewhere. Thanks.

Prime95 2020-08-01 21:16

Server is processing proof files again.

The bug was in my parsing of the proof file header using fscanf. If the first byte of the first residue was ASCII whitespace, it thought the header was on byte longer than it really was. Error handling reading the last residue was not good, resulting in the 0.5 roundoff error.

Prime95 2020-08-01 21:19

[QUOTE=Runtime Error;552217][I](I know v30 is a work in progress; sorry if I'm jumping the gun here.)[/I]

What is the recommended process for uploading proofs from manual testing assignments?.[/QUOTE]

You have guessed at the process.

1) Manually submit your results.json.txt.
2) move the proofs to a folder where prime95 v30.2 is running.
3) wait for the proofs to get uploaded (I archive my proofs using advanced resource limits dialog box)

I too have felt the need for a proof status web page. We'll write one sooner or later.


All times are UTC. The time now is 08:50.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.