Project Update

[Dingo]

I have crunched enough work now to Create the Team.  Join BOINC-AUSTRALIA if you run this non BOINC project.


Keep it running

On Linux, running the client as a systemd service keeps it running across reboots. Create a unit file at /etc/systemd/system/crunch.service:

[Unit]
Description=primecrunch client
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/path/to/crunch  ## CHANGE THIS
Restart=on-failure
User=yourlinuxusername  ## CHANGE THIS

[Install]
WantedBy=multi-user.target


Then enable and start it:

sudo systemctl enable --now crunch

[Dingo]

Instead of making it a service I found that putting an entry in the crontab.

process in a linux terminal

1. sudo crontab -e  # Note here r is next to e on the keyboard and if you press r instad of e (contab -r) it deletes the crontab which is not good.

2. put this entry after all the commented out section.

@reboot /PATH/TO/crunch -p 4 >/var/log/crunch.log 2>&1 & 
>/var/log/crunch.log 2>&1 & 
##  EG MINE IS  @reboot /root/PrimeCrunch/crunch -p 4 >/var/log/crunch.log 2>&1 & 

NOTE: The -p lets you assign how many Threads to use.  If left off it will use all Threads.
NOTE:  If you forget the & cron will hang until crunch exits — which it never does.

That's it when you reboot or start the machine it will start crunch

If you use this and you want to stop the job from running use this command.

# Stop PrimeCrunch
pkill -f "/PATH/TO/crunch" 2>/dev/null

eg  mine is

pkill -f "/root/PrimeCrunch/crunch" 2>/dev/null


Added the Windows start crunch at machine start

1. Find the crunch program on your computer.

2. Create a shortcut and if you want to restrict the number of cores used in the Target block enter -p [number of cores] after crunch.
eg mine is "C:\Users\giles\PrimeCrunch\crunch.exe -p4"

3.Press the Windows key + R key to open the run box.

4. Paist shell:programs in the box and press enter.  The start menu window will open;

5. Open the StartUp folder and Paste your created shortcut into that folder.

6.  That's it, the first reboot or start you might get a warning asking if you really want to start this program.. If you trust it, well you are running it, click the box to deselect ask next time and press enter or whatever the button says can't remember.

7.  To stop crunch from starting at startup open the Task Manager and click the Startup Apps button. Right click on crunch and disable.  Do the opposite to enable it afterwards.

[Dingo]

New feature added after one of my enquiries.

I had this post:

I created two 4003 and 4005. Looking at the ones running now they are small digit blocks.

I have one machine that I would like to allocate longer jobs to. What K number would be one that is over a 2,000,000 digits. My largest prime found on Primegrid is 2,060,937 digits.

His reply was to create a new page where you can estimate.

https://primecrunch.com/digit-calculator?k=999&d=1000000

[Dingo]

Found a new page for Help and Documentation

Weaning myself off this project now that the Team is created but leaving  a couple of vps on it.

[Dingo]

I have been working with Andy the person behind the project to see if he will create a RPI Linux 64 version of the application.

prst The client is really just a wrapper. The actual maths is done by prst, which is built on gwnum, George Woltman's FFT library from Prime95. gwnum is hand written x86-64 assembly with separate code paths for SSE2, AVX2 and AVX-512. There is no ARM64 build of it, and porting it means rewriting the assembly core. That's a serious project in its own right and not something I can take on.

So there are two possible routes:

Emulation. Box64 on 64 bit Raspberry Pi OS. That's the one you can try today without me doing anything. I have no numbers for it. My expectation is that it will be poor, because gwnum's speed comes almost entirely from wide SIMD, and translating AVX2 onto a Cortex-A72 with 128 bit NEON is close to the worst case for a translator. But I would rather see a measurement than a guess. If you fancy trying it, grab the linux x86_64 client, run it under box64 and post how long a single Fermat test takes.
Swap gwnum for a generic bignum library like GMP. That would be native and would run anywhere, but the maths is the whole game here. gwnum uses an irrational base DWT, which is why a test at n = 1.5M takes minutes. A generic modpow at that size is orders of magnitude slower. You would get a native arm64 client that still reports almost nothing.
Even assuming a perfect hypothetical ARM64 port, the hardware gap is big. An A72 core does 2 doubles per FMA at 1.5GHz, a modern x86 core does 4 or 8 per FMA at over 4GHz, so roughly 10x per core before you account for anything else. These FFTs are also memory bandwidth hungry, and that is where the Pi 4 is weakest, with a few GB/s shared across all four cores. Your 16 Pis would land at a handful of modern desktop cores at best, and probably well under that.

So given that challenge and a bunch of testing and help from adam I finally got one of my RPI to complete a job.

I posted this on the forum at the project.

Dingo
3 hours ago
edited
It ran and didn't have any errors reported. The time is very close.

dingo@C1-Ubuntu:~/prst-folder$ BOX64_LOG=0 box64 ./prst "1005*2^100000-1" -cpu SSE2
[BOX64] Box64 arm64 v0.4.3 a2ae0500d with Dynarec built on Jul 25 2026 10:57:54

dingo@C1-Ubuntu:~/prst-folder$

cat result.txt
"1005*2^100000-1" is not a probable prime. Have you run Fermat test first? RES64: 16F98A5F08A1F731, time: 68 s.

I am going to try a bigger one that is a prime on my list.

dingo@C1-Ubuntu:~/prst-folder$ BOX64_LOG=0 box64 ./prst "4005*2^56366-1" -cpu SSE2

start time 15:07 AEST Finish time 16:27 AEST

Results

BOX64_LOG=0 box64 ./prst "4005*2^56366-1" -cpu SSE2

[BOX64] Box64 arm64 v0.4.3 a2ae0500d with Dynarec built on Jul 25 2026 10:57:54
"4005*2^56366-1" is prime! Time: 19.1 s.

cat result.txt

"4005*2^56366-1" is prime! Time: 19 s.

looking good.

I am going to do the large one that is a known prime (1,415,549 digits) on one core of an RPI 4. I wrote a little script so I didn't have to wait and watch as it is going to be along time.  maybe 12 hours I don't have a clue really.

Code Select Expand

#!/bin/bash

LOGFILE="/home/dingo/prst-folder/result.txt"

# Record start time
START_TIME=$(date +%s)
echo "Prime Search Start: $(date)" >> "$LOGFILE"

# Run your Box64 job
BOX64_LOG=0 box64 ./prst "1011*2^4702339-1" -cpu SSE2 >> "$LOGFILE"

# Record end time
END_TIME=$(date +%s)
RUNTIME=$((END_TIME - START_TIME))

# Summary
echo "Prime Search End: $(date)" >> "$LOGFILE"
echo "Total runtime: ${RUNTIME}s" >> "$LOGFILE"
echo "------------------------------------------------------------" >> "$LOGFILE"

Using one core:

16649 dingo 20 0 177984 109948 15156 R 99.7 2.8 0:12.30 prst

I am hoping that andy will be able to make a wrapper for a ARM64 client if this finishes and it gives the correct answer.

[Dingo]

Text on the forum.

Separately, on formatting: you used

Code Select Expand

and [quote] in your first post and they came out literally. That's on me for never documenting what the composer accepts. It takes markdown, not BBCode.

The composer has two tabs, Rich text and Markup. Rich text gives you a toolbar with Inline code (Ctrl/Cmd+E) and Code block buttons. Markup is the raw source if you'd rather type it directly.

The markup, written out literally:

`code`                        between single backticks
**bold**  *italic*  ~~strike~~
> a quoted line
- a bullet
1. a numbered item
[text](https://example.com)   a link
@[name]                       mentions someone
:smile:                       emoji
For a code block, put three backticks on a line of their own above and below the text.

No headings or images on the forum, those are blog only.

[Dingo]

What shipped this week (week 36)
andy
andy
6 days ago
edited
0
A round up of what has changed on the site this week.

Work ranges

A k can give itself back. Every row on your work ranges page now has a "release k" switch. With it on, the k is unreserved once there is nothing left to test in that window, and the rows on it go with it.

Until now a reservation ended two ways: you unreserved it, or the inactivity clock took it, which is a warning after seven days without work and a release a day after that. Neither helps if you finish the window you set out to search and carry on crunching elsewhere. That is the case where holding a k costs other searchers and nobody notices.

A check every five minutes reads the same counts the "finished" chip on the row draws: nothing ready, nothing out with a machine, and candidates actually in the window. The release goes through the same path as pressing Unreserve yourself, so jobs are cancelled exactly as they always were, and you get an account notice. If you hold one k in two windows it only goes back when both are done, in whatever order they finish. Turning the switch on asks for confirmation and counts the other rows on that k the release would take with it. Turning it off does not, because that only means the k stays where it is.

Thanks to @Carlos, who asked for this in Release a k automatically.

Tiers. @Dingo and @PDW both reported that "New tier" on the row menu did nothing. The button was not broken, it was misnamed. It split a row out of a tier it shared with others, so with one row in one tier there was nothing to split, and the click sent no request and produced no error. It is now "Split into own tier" and greys out where there is no tie to split, like every other item in that menu.

What they were both actually after now exists: "Duplicate into a new tier", beside "Duplicate in this tier". A row added by either scrolls into view and is tinted for a couple of seconds, since a new row lands at the bottom of the plan and a copy looks identical to the row it came from.

The density bar shows more of the range. It had 30 marks spread across the whole loaded ceiling of about 12,000,000, so each mark covered 400,000 n and a window of 1 to 499,999 was a sliver about one mark wide at the far left. There are now 240 marks at 50,000 n each, so the same window covers ten of them.

The limit here is pixels rather than data. The bar is roughly 370 CSS pixels wide. One mark per grid cell, which is what the data would support, puts each at 0.3px, and at that size a single tested cell can vanish on rounding.

The page updates itself when a range finishes, rather than waiting for a reload.

Jobs

A page for queued work, at Jobs, Queued. This is work allocated to your machines that no worker has picked up. The Jobs page has only ever listed jobs that reported progress, so this work appeared nowhere and there was no way to get the id needed to cancel it. It came out of two jobs @Carlos emailed about, which he could not have cancelled himself however hard he looked.

Most of what shows up here is an ordinary client queue and not a problem. The page does not try to tell a queue from a loss, because it cannot: it gives you how long each number has been sitting and the date the seven day sweep returns it to the pool, and you know whether that machine is working. Cancelling is a page at a time instead of one confirmation per number.

One detail. Below n = 20,000 the client reports no progress at all, so down there queued cannot be told from running. Those numbers are listed only once they are more than six hours old, which no queue at that size survives.

Primes

Verifications publish as they land. A new prime used to be held off the public pages until published by hand whenever it was large enough to rank. Size is only half the question. The hold exists to protect a submission, and confirming a prime somebody else found years ago has no submission to protect and nothing to reveal, since the source published it long ago. The hold now applies only to a discovery of ours. A verification is on the site as soon as it is stored.

Discoverer and verifier are named separately. Three places credited one person for a prime two people had a hand in.

The top primes chart plotted every point on the date our machine finished, so a prime found in 2014 and confirmed here last month was drawn as a 2026 find. A verification now sits on the date the public record gives, and the tooltip carries separate "discovered by" and "verified by" lines. Points are coloured by whose result it is rather than by k, and the legend doubles as a filter.
The prime families grid said "Found by" and one name on every chip, whether that chip was a discovery or a re-test. It names both parties now.
Profiles list "Largest discoveries" rather than largest primes, and the T5K figure counts discoveries. Verifications are somebody else's finds, and they were taking the top of the card because they are usually the larger numbers.
Where neither side can be shown to have been first, because our timestamp falls inside the period the published date leaves open, all three still say "found by" and leave it at that.

A new page

Territory maps the ground the project has finished: one mark per completed 500k range cell, coloured by whoever did the testing. As I write this that is 563 cells across 330 values of k and fifteen people. The shape is a staircase rather than a front, because low exponents are cheap and every band up costs more per test. One cell sits above 7.5M.

It makes no claim about anyone outside primecrunch. A gap means we have not completed a range there, not that nobody has. Some/many of those k already have known primes found by others.

[Dingo]

What shipped this week (week 37)
andy
andy
3 hours ago
0
A round up of what has changed on the site and in the client this week. Clients update themselves, and every channel is on 3.3.47.

Machines

Set a machine's load from the website. Start the client once with -remote-control and the flag is saved in crunch.yaml. After that, expanding the machine on your machines page gives you three settings: Processes, how many tests it runs at once; Backlog, how many numbers it holds beyond those; and Drain. Until now the first two lived only on the command line, so changing either meant getting to the machine and restarting it.

A change reaches a running machine at its next progress report or result, usually within 5 minutes, and within 15 on a machine running nothing. Lowering the process count stops the most recently started tests, and they resume from their save files when a worker is free. Lowering the backlog hands back numbers no worker has started, so another machine can have them.

With the flag on, the client ignores -p and -b, and a machine with nothing saved runs one process per physical core. So if both boxes are empty the first time a machine starts under remote control, they are filled in from the -p and -b it was started with, and it carries on at the load it had. Saved values are never overwritten.

Drain takes a machine to zero from the website: it finishes what it holds, takes nothing new, and keeps running while it waits. -d exits when the work runs out, which is fine at the keyboard, but from the website it would be a switch you can turn off remotely and only turn back on in person. Untick Drain and save, and the machine starts asking for work again. Drain needs client 3.3.47.

On the page itself, rows now sort by name within each status band, rather than by last contact, which moved them under the pointer every time a machine reported. The top line counts running and queued separately, and closing a machine without saving puts its boxes back to what is saved. The new machines help page covers all of it.

Client

A machine that cannot run prst stops asking for work. @Dingo's Pi came back from a reboot unable to run prst and took 130 jobs in about twenty seconds. Each one failed, was tried three times, was given up, and the client asked for the next. That limit was built for one bad job. Nothing slowed the client down when every job failed for the same reason.

From 3.3.46 the client runs prst once on 3*2^5134-1, a small known prime, before it asks the server for anything, and runs it the same way real jobs run. If prst will not start, crashes or gets the answer wrong, the client prints the command, how prst ended and its last lines of output, then exits with status 3. While it is running, two jobs given up in a row with nothing finishing between them stops it the same way. Jobs it already holds stay in journal.jsonl and carry on once prst works. Under systemd each restart repeats the check, so a machine with a broken prst no longer collects more jobs every time it is restarted. See what happens if prst cannot run.

A job could fall out of the client's journal. The client compares the jobs it holds with the list the server has for it, and drops anything the server does not list, sparing jobs that arrived after the list was fetched. A job still being written to the journal while that comparison ran was not spared. It came out of the journal while the machine went on running it, and after the next restart the client had no record of it, so the job sat allocated with no progress until the seven day sweep. It turned up on one of my own machines. Fixed in 3.3.46. The update does not recover a job already stranded this way; cancel it from the Jobs page.

A restart keeps your queue in order. After a restart the client restored its backlog smallest n first. That was a sensible default when I was the only person running it and every number in the buffer was interchangeable. It is not once you have tiers and several k: a machine moved from one k to another could restart with the new k's low n ahead of the old k's high n it was finishing. The backlog now comes back in the order it arrived. The journal file always held that order, so existing queues get it back at the next restart with nothing to do.

Work ranges

Paste a plan. "Paste a plan" on the work ranges page takes a list of k and n windows, one per line, reserves each k as its line is read and adds a row for it. Each line gets its own answer: added, k held by somebody else, no candidates, a duplicate window, or past your quota. Lines that did not go in come back as the same three columns, so you can copy them, fix what needs fixing and paste again.

The rules. Quota is spent as the list is read, and a k you already hold costs no extra slot. A window whose top is above what we have loaded is cut down to the loaded ceiling; one that starts above it is refused. Pasted rows go above your existing plan, one tier per row by default so paste order is priority, and your existing rows keep their order and ties. Release k on complete is on for the whole paste unless you turn it off.

Nothing waits for quota to free up. A line waiting for a slot would be a claim on a k that anyone else can reserve in the meantime, so the paste takes what it can now and tells you what it did not take. This is the other half of what @Carlos asked for in Release a k automatically.

Ready counts stay inside the window. The ready and allocated numbers on a row came from 10,000-wide cells, and any cell the window touched was counted whole. A window from 300,000 to 400,000 touches one n of the cell starting at 400,000, and took in every candidate in it. So a finished window could read "384 ready" with none of them inside it, never showed as finished, and release k on complete never fired for it. The cells at the two ends of a window are now counted candidate by candidate.

"Edit n window" is now "Edit n window and machines", because that is where a row's machines are set, and the old name hid it.

Jobs

Queued work bands by machine or by job type on Jobs, Queued. It uses the same grouping setting as the Jobs page, so changing it on one changes both. The whole queue is sorted into bands before it is split into pages, so one machine's work stays together instead of scattering across every page.

The Jobs help had handing a job back wrong. It said a number you give back always goes to somebody else. That is true on unreserved k. On a k you have reserved nobody else can be given it, so it waits for you.

Primes

The Riesel rank says what it is a rank among. A candidate page read "465th largest of the 160,220 known Riesel primes". Norman, who maintains the Riesel list we import, pointed out that his list covers k below 10,000, and there are larger Riesel primes with bigger k. Every place the rank appears now says "k below 10,000", in the sentence or a tooltip, and there is a help entry explaining it. The numbers were right. The sentence claimed more than the list covers.

Which t5k proof method to tick. @PDW asked in Reporting a t5k prime, and @Carlos and @3C-714 answered. Our help said "the LLR confirmation", meaning the Lucas-Lehmer-Riesel test, to people looking at a form where one of the options is a program called LLR. The primes help and the discovery email now say to tick Pavel Atnashev's PRST, the program that runs the test, and give the exact text for the credits box, PSieve, Srsieve, Primecrunch.com, with a copy button on the help page.

The pzktupel link on a candidate page now opens Norman's table for that k at its heading, instead of downloading a 160,000 line file. It cannot land on the prime's own row, because the rows do not carry k and thousands of them share an n with a row under a different k.

A new page

Sweep progress shows how far smallest available work has got. That mode hands out the lowest untested n nobody has reserved, one 10,000-n cell at a time, lowest k to highest. The page gives a 2,000,000-n overview in 100,000 bands, then opens the current band into its ten cells, each drawn as a strip across k from 1,001 to 9,999.

As I write this the sweep is in the cell at n = 160,000, with k = 6,505 the lowest still to test there. Everything below n = 100,000 is done, 13,006,255 candidates, and the band from 100,000 to 199,999 is 69.5% done.

A candidate counts as done when we hold a residual for it, so work other projects have reported counts as untested here. The bands ahead of the sweep are not empty: up to about 10% of each is already done by members working the k they have reserved.

Thanks to @Carlos, who asked for it in Configure specific machines for specific ranges?. Territory has moved out of the top navigation into the sidebar beside it, under Project.