Thanks for all of that info.

By the way, I had the power supply go out on my computer which I just swapped out. I restarted just one core to see what would happen, and the recordtable was written over as if it was starting from scratch.

How do you recover from a shutdown and resume where you left off?

[QUOTE=SaneMur;277862]
By the way, I had the power supply go out on my computer which I just swapped out. I restarted just one core to see what would happen, and the recordtable was written over as if it was starting from scratch.

How do you recover from a shutdown and resume where you left off?[/QUOTE]

Ouch, and there is me thinking America is good at power. Certainly you would get a lot less power cuts than Afghanistan (1 a day) or where I lived previously in Dhaka (8 cuts a day).

I'm afraid that record table is lost forever. You should stop the programme and rename the record tables in the other cores to secure them - something like recordtable1.txt. When you start them up again the new record table is called recordtable.txt It is possibly worth doing this every week if you do long runs.

Regarding your old table, you could reconstruct some of the larger p/n values by using pfgw on all of the candidates you found in results.txt

When you start the program again, it should automatically start from where you were before the power cut, as the progress.txt file gets updated every 5 minutes or so. If the progress.txt file was in the process of being written when the power cut came, it may be corrupted, then you should recreate the progress.txt file starting from the Iteration and "i" value one greater than the last candidate in the results file, unless you are superconfident you can extrapolate the position from the time of that find to the time of the power cut.

Hope this helps

Checked my M(52) record files for the last month and found the following records:

Absolute (Riesel and Sierpinski) best

[CODE]
32 89 61233200129625 R 52 (one Sierpinski equals this)
33 91 61233200129625 R 52
36 118 61233200129625 R 52
38 129 61233200129625 R 52
39 140 61233200129625 R 52

[/CODE]
Riesel best
[CODE]

22 42 63084742759365 R 52
31 87 61233200129625 R 52

[/CODE]

[QUOTE=robert44444uk;277626]
If you have lots of cores, then we are in business! I can post the check points I reached for the other M values when I get back to Kabul in a couple of days.
[/QUOTE]

Checkpoints:
[CODE]
M(x):Iteration:i

82 21 17694
100 483 65266
106 813 99396
130 85 120077
148 49 75098
162 129 90793
180 136 34933
196 27 11301
210 30 113272
226 40 15573
268 116 63038
[/CODE]

I would like to reserve 180, 196, 210 for myself.

recommended smith_check for the M(x):

M(82), M(100), M(106):

7 50
14 100
23 200
38 500
54 1000
66 2000
74 3000
90 6000

M(130):
7 50
13 100
21 200
32 500
53 1000
65 2000
73 3000
88 6000

M(148)
10 100
30 500
48 1000
62 2000
70 3000
87 6000

M(162)
26 500
47 1000
64 2000
72 3000
85 6000

[QUOTE=robert44444uk;277894]Ouch, and there is me thinking America is good at power. [/QUOTE]

It was the power supply INSIDE the computer that went. It was 3 years old and on almost all of the time and a little underpowered for my config. I replaced it with a 1000 Watt PSU which should be much more robust.


[QUOTE=robert44444uk;277894]I'm afraid that record table is lost forever. [/QUOTE]

Actually, I have been backing them up, regularly, every 8 hours. And the last backup was made 2 hours before the PSU cut out. So, I "lost" only 2 hours of records.

Shouldn't the software "store" the best result for each level (102, 103, 104, etc) and only replace the ones that need replacing in the record table? In the event of a restart, the "last known best" should be read from a separate file, and the record table should be written according to that.

[QUOTE=SaneMur;277908]

Shouldn't the software "store" the best result for each level (102, 103, 104, etc) and only replace the ones that need replacing in the record table? In the event of a restart, the "last known best" should be read from a separate file, and the record table should be written according to that.[/QUOTE]

I'm really grateful to Robert Gerbicz for writing the software, which is amazing, but we never got around to asking for this one. If you are good at topping and tailing you could write some code that automates this outside of the core program.

[QUOTE=robert44444uk;277931]I'm really grateful to Robert Gerbicz for writing the software, which is amazing, but we never got around to asking for this one. If you are good at topping and tailing you could write some code that automates this outside of the core program.[/QUOTE]

I will work on it, that will be easy enough to encode.
I'll need to:

1. Code up a new format for a binary record_table, and write to that each time there is a record table update.
2. When the program first launches, if the binary table exists, ask if this is the continuation of the previous run, or a new run, and take actions based on that.

[QUOTE=robert44444uk;277900]

I would like to reserve 180, 196, 210 for myself.

[/QUOTE]

And also I will reserve 178 and 268

Regards

Robert

One Riesel record to post, which is equal to the best Sierpinski to 14 primes

14 16 66622302705377 R 52

The series contains a CC7, CC3 and a CC4 to this point.

[QUOTE=robert44444uk;277775]Heres the table for Riesels:

[CODE]
153 100101 638621868573 R 66
154 638621868573 R 60
155 638621868573 R 60
156 638621868573 R 60
157 <150000 638621868573 R 60
158 164463 638621868573 R 60
[/CODE]
[/QUOTE]

Hi Robert,

your recent post reminded me that I always forgot and never reported the missing primes for closing this gap in your status table. Actually they are already done for more than a year now!

So, the lines in question should read as follows:
[CODE]
153 100101 638621868573 R 60 ( <-- not 66 ! )
154 107726 638621868573 R 60
155 118186 638621868573 R 60
156 121601 638621868573 R 60
157 143629 638621868573 R 60
158 164463 638621868573 R 60
[/CODE]
Note, that the 66 is a typo in your list (also for the lines above this section).
It's actually 60.

Besides this, there was not much progress at my end for quite a while now.
No new record breakers found.

A few top performers tested to n=220k are:
[CODE]
S 12034494960083 66 170/212402
S 16196964114523 58 169/215818
S 1061615018040269 106 168/212206
S 2752432099816267 138 167/217907
S 26465530345417 66 166/192945
S 1024817770766811 100 166/192615
[/CODE]

Kind regards!

Thomas

Hi Thomas11

Ah bless, now we have the full Riesel table! Thank you for that. Good to know you are still active, and that you have a second candidate at 170 primes, it is tough going at n>160,000

Keep the computer cycles pumping!! The Sierpinski side has a natural disadvantage, the + part of the equation gives us Riesel guys a 2 point start.

But having said that, the Sierpinskis have 87 records from p=15 to p=172 compared to Riesel with 67 records.

But...at present it looks like the Riesels have the computer resource pledges to even that score up.

Riesel absolute racing records: p=15-20,24,26-29,31,33-48,57-59,69-70, 72,74-79,81-83,111-124,133-134,136-139,141-145

Sierpinski absolute racing records: p=21-22,31,49-56,60-68,71,73,80,84-110,125-132,135,140,146-172

Ties: p=1-14,23,30,32

And now the Riesel side has the best to n=10000, 121 vs 119!!!!

Regards

Robert