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
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.
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.
QuoteI 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
Found a new page for Help and Documentation (https://primecrunch.com/help)
Weaning myself off this project now that the Team is created but leaving a couple of vps on it.
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.
QuoteDingo
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.
#!/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.
Text on the forum.
Separately, on formatting: you used 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.
QuoteWhat 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.
QuoteWhat 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.
QuoteChallenges
What is a challenge?
A competition over a fixed window on one part of the search, for example every n below 500,000 for a week. Members and teams are ranked by the work they complete in it, and the top three of each win gold, silver and bronze medals. Current and past challenges are on the Challenges page.
How do I take part?
Press Enter on the challenge's page before it starts. If you own a team you can enter the team from the same place. Entry closes when the challenge starts, for members and teams alike, so nobody joins the leaderboard part way through and pushes down the people who were on it from the beginning. You can withdraw at any time until the end, but once the challenge has started there is no way back in.
To point your machines at a challenge, give its range a high priority on your work ranges. See Work ranges for how.
What work counts?
A job counts when it was allocated at or after the start, completed before the end, and its number is inside the challenge's n and k bounds. Every job type counts. Work already in a machine's queue before the start does not count, even if it completes during the challenge, so collecting a backlog beforehand does not help.
How is the score worked out?
In ops, the same measure as Top Crunchers, so a test on a larger number is worth more than a test on a smaller one. The leaderboard shows the job count alongside.
How do teams score?
A team's score in a challenge is the work of the members who were in the team when the challenge started. If you join a team after the start, your work still earns the team credit on the Teams page as usual, and still counts on the individual board if you entered, but it does not count towards the team's score in that challenge. That stops anyone joining the leading team near the end to share its medal. If you leave, your work stops counting towards the team's challenge score from that moment, and counts again if you rejoin. Members do not need to enter individually for their work to count towards their team's challenge score.
When do the scores update?
Every 10 minutes while the challenge runs. After it ends the last few minutes are counted again, in case some results arrived just after the end was scored, and the scores are final and the medals awarded within about half an hour.
Who gets medals?
The top three members and the top three teams win gold, silver and bronze. Equal scores share a place. A medal is the challenge's image in a gold, silver or bronze ring. Member medals appear on the member's profile. A team medal goes in the medal cabinet on the team's page, and on the profile of every member whose work counted towards it.
The first Challenge on Primecrunch has been set. It is to flesh out any problems as this is a new feature to this platform.
https://primecrunch.com/challenges/1/sweepstakes
QuoteRuns for 7 days. Work on n from 1 to 499,999 and any k, allocated from Sat, 19 Sept 2026, 10:00 AEST and completed by Sat, 26 Sept 2026, 10:00 AEST. Every job type counts, and the score is ops.
QuoteA team's score here counts only members who were in the team when the challenge started. Everyone's work still earns their team credit on the Teams page as usual. How challenges work.
Nearly 38 million candidates stand between the sweep and n = 500,000. For one week, every machine that enters is racing the same ground.
The ground
Below n = 500,000 there are about 65 million candidates across the 4,500 odd k from 1,001 to 9,999. Everything below n = 100,000 is done. The sweep, which always takes the lowest untested n in the project, is at n = 170,000. Each candidate there is a number of about 51,000 digits, and by n = 500,000 they are over 150,000 digits long.
In the seven days before this challenge was set, 3.44 million jobs finished below n = 500,000. This week we find out what that number looks like when people are competing for it.
Why this range
We keep the residual of every test, so every result here adds to a complete, checkable record of each candidate below n = 500,000, the composites as well as the primes. Primes found here are below the t5k top 5000 floor, which is over 900,000 digits, but every find is recorded and credited on primecrunch to the member whose machine tested it.
How to win
Enter before the start. Entry closes the moment the challenge begins, for members and teams.
Own a team? Enter it too. A team scores the work of everyone who was in it when the challenge started.
Set up your work ranges so your machines are on work that counts. How is below.
Score is ops, not job count. A test at n = 450,000 is worth more than one at n = 170,000 and takes longer to run, so the leaderboard measures the work your machines did, whichever part of the range they did it in.
No stockpiling. Only work allocated after the start counts.
The top three members and the top three teams win gold, silver and bronze. Medals go on member profiles and in team medal cabinets.
Setting up your work ranges
Your machines take work in the order set on your work ranges page, starting from the top row. With nothing set up, they take work from the shared k at the bottom of that page, whose untested n are large and may well be above 500,000. A few minutes on the page before the start makes sure every machine is on work that counts.
The simple way: Smallest available work
Open work ranges and press + Smallest available work.
A new row is added in a tier of its own at the bottom. Drag it to the top by its grip, or use Move up on its ... menu until it is first. Anything above it is tried first, so it needs to be at the top.
This row hands out the lowest n that nobody has reserved, any k, which is n = 170,000 as this is written. Every test it gives your machines is inside the challenge, and it does not use any of your k quota.
Using k you have reserved
Press Reserve a k. The Quick wins list starts lowest in n, which suits this challenge, or type k values into the box at the bottom.
On the row's ... menu choose Edit n window and machines and set n to to 499,999. The window includes the n you type, and 499,999 is the last n this challenge counts, as the rules at the top of this page say.
Move the row to the top, as above.
Optionally turn on the row's release k switch, so the k goes back to the pool when its window is finished, and put a + Smallest available work row directly below it, so your machines carry on with work that counts when it does.
Only some of your machines
Every row can be limited to particular machines: Edit machines on a Smallest available work row, or Edit n window and machines on a k. Put the machines you want in the challenge on the challenge row, and the rest carry on with your usual plan below it.
Just before the start
Work allocated before the start does not count, even if it finishes during the challenge, and that includes numbers already waiting in your machines' queues. If you want every test to count from the first minute, give those back just before the start from your queued work page, or lower the backlog of a machine under remote control, which hands back whatever it holds above the new number.
Watch the sweep move while it runs. How challenges work.
Suggested by Carlos on the forum.
QuoteWhat shipped this week (week 38)
andy
andy
9 hours ago
0
A round up of what has changed on the site this week. There is no new client this week, and every channel is still on 3.3.47.
Challenges
Challenges (https://primecrunch.com/challenges) are time-boxed competitions with gold, silver and bronze medals for members and for teams. (https://primecrunch.com/teams) @Carlos suggested one in last week's thread, and @Carlos and @PDW told me how challenges usually work elsewhere. The first, Sweepstakes, (https://primecrunch.com/challenges/1/sweepstakes) started at 00:00 UTC today and runs for a week on n below 500,000. 8 members and 3 teams entered. In its first 15 hours entrants completed 1.47 million jobs, 93,002 TeraOps.
The rules, in short. A job counts if it was handed out after the start and finished before the end, so a backlog built up the night before counts for nothing. The score is ops, so a test twice as long scores twice as much. Members enter themselves and team owners enter their team. A team's score is the work of everyone who was in it at the start, whether or not they entered themselves, and joining a team after the start does not add your work to it. Entry closes at the start. You can withdraw until the end, but you cannot come back in. The challenges help (https://primecrunch.com/help/challenges)has the rest.
On the page: a countdown to the start, then to the end; the Enter buttons at the top; and once a challenge is running, a chart of the top 10 members and teams hour by hour, drawn as one chart on a wide screen and a small panel per entrant on a phone. Scores refresh every 10 minutes. Medals go on members' profiles and in the team's medal cabinet.
Teams
Every team has a page of its own. Open any team from Teams to see its members and what each has banked for it, a chart of what the team banked at each daily cut-off, its challenges, its medals, and who has joined and left. Joining, switching and leaving are on that page now, not in settings, and each one asks first and says what the move does to your credit.
Team owners can give their team a picture and a description, from Manage team on the team's page, which is also where you rename the team, hand it to someone else, or leave it. Settings now just links to your team. Starting a team is the Start a team button on Teams.
What joining a team brings with it. At each 00:00 UTC cut-off a team banks everything its members have done since the last cut-off at which they were in any team. Your first cut-off in any team therefore brings your whole history. Switching teams brings only what no team has banked yet, which is normally that day's work. The help used to say "your first cut-off on a team", which read as though every new team got your whole history. It does not, and the help now says so. On a team's chart a member's first cut-off can be years of work in one bar, so those bars are cut down to the team's busiest ordinary day and hatched, with the full figure when you hover over them.
The sweep
Every k is complete to n = 200,000, at 21:41 UTC last night. See Every k is complete to n = 200,000. As I write this the sweep is in the cell at n = 210,000, and the band from 200,000 to 299,999 is 22.5% done.
Smallest available work now takes reserved k as well. Two cells sat at 99.9% for days. The candidates left in them were on three k somebody had reserved, working from n = 500,000 up. The sweep skipped any k reserved by someone else, and the reserver's own ranges never asked for n below 500,000, so nothing could hand those candidates out. The sweep would have stalled the same way at every k reserved like that. It now walks every k whoever holds it. A reservation still stops anyone else's work ranges taking the k. It no longer stops the sweep passing through it.
The sweep page has one bar for the whole overview, as @Carlos asked, split into the work behind the sweep and the work ahead of it, with a marker where they meet. Yellow on the strips is now labelled "Allocated to a machine" rather than "Being tested now": it includes numbers sitting in a machine's backlog that it has not started yet.
Jobs
How long a job can go quiet before it is taken back now depends on its size. It was a flat week. At the moment it is a day below n = 250,000, two days below 500,000 and a week above that, so a machine that is switched off does not sit on small jobs for days. The times can be set separately for k you have reserved; for now they are the same. A running job reports progress every 5 minutes, so it is only at risk if the machine goes silent. Work still in a backlog, and n below 20,000, report nothing, so their clock runs from when they were handed out. The jobs help (https://primecrunch.com/help/jobs) shows the current times, read live from the server, because they will be adjusted from time to time. The date for each job in your queue is on Jobs, Queued.
Machines and territory
The machines page counts your backlog. It said "0 queued" beside a Queued work page showing 240, because it only counted started work. It now shows running, queued (the same total as the Queued work page, linked to it) and, when there is any, paused: started work above the machine's process count. The allowance figure counts all three.
Territory numbers could be days old. The server kept serving an old copy of the territory data to the first visitor after a quiet spell, and the two API servers could hold different old copies, so the numbers could go backwards on a reload. A cached copy now goes out for at most one refresh period past its expiry. The same fix covers the other cached pages, such as the sweep, top primes and platform stats.
Territory columns are one unit wide, about 4 k each rather than 15. Each column takes the colour of whoever has done the most tests in it, so a member working one k in a wide column shared with a bigger range could vanish from the map entirely. Hovering over a column now lists every finished k in it, with its owner and test count.
Profiles and pages
"Primes in T5K" counted re-tests. The card on settings and the dashboard counted every prime at t5k size your machines had tested, including ones somebody else found first. Mine said 131; I found 10. Both cards now count your discoveries only, which is what your public profile already showed.
Pictures on the boards. Challenge boards and Top Crunchers show members' profile pictures, and team boards show the team's picture.
Some messages had lost their styling. Alerts, loading spinners and some groups of buttons were showing unstyled. They look right again.
The forum's posting threshold can be waived. You need 1 peta-op of completed work to post on the forum. An admin can now waive that for a member with a reason to post sooner. Starting a team keeps the threshold.
QuoteSweepstakes, day three: a lead change, a photo finish, and the record underneath
andy
andy
a day ago
edited
1
Three days down, four to go. Here is where Sweepstakes stands as of Monday 17:15 UTC.
The headline.
The eight entered members have run 5.16 million qualifying jobs since midnight on Saturday. In the seven days before this challenge was set, the whole project finished 3.44 million jobs below n = 500,000. You have done half again as much in under three days, which is close to four times the rate.
That number is the point of the week. Every one of those tests writes a residual, so the band below n = 500,000 is turning into a complete, checkable record of what each candidate is, the composites as much as the primes. Nobody has that record. It is the reason to cover ground that has been looked at before, and it does not care whether a prime came out of the test.
The board.
# Member TeraOps Jobs
1 PDW 150,729 1,055,757
2 andy 64,865 921,528
3 gd_barnes 62,282 673,860
4 Dingo 48,277 982,391
5 Dave Studdert 33,403 692,333
6 3C-714 33,159 278,420
7 Bijouxa 16,069 341,938
8 Carlos 11,172 218,410
The lead has changed hands once. gd_barnes led from the start and held it until 06:00 on the 20th, when PDW went past and kept going.
Read the jobs column against the ops column and you can see two different weeks being had. Dingo has run more jobs than anyone except PDW. 3C-714 has run barely a quarter of Dingo's jobs and is one place behind on ops. A test at n = 450,000 takes far longer than one at n = 230,000, and ops is what squares that up, so the machines clearing the low front and the machines working the top of the range are being measured on the same scale. Both are filling in the same record from opposite ends.
Teams:
# Team TeraOps Who
1 Ukraine 150,729 PDW
2 BOINC-AUSTRALIA 81,680 Dingo, Dave Studdert
3 mersenneforum.org 73,453 gd_barnes, Carlos
PDW is a one-member team within 4,404 TeraOps of out-scoring both two-person teams put together.
The primes, since you will ask. 135 so far, every one of them out of the 400,000 to 500,000 band. @PDW drew first blood six hours in with
5,067
·
2
439,386
−
1
at 132,273 digits, and holds the largest,
5,267
·
2
498,938
−
1
at 150,200 digits, found at 05:16 this morning.
Four days left, and three medals are still open.
gd_barnes's 62,282 has been still since early on the 20th, which makes it the number to chase, and everyone below it is running:
Dingo is 14,005 behind at about 17,800 a day. Bronze is under a day away.
Dave Studdert (28,879 behind) and 3C-714 (29,123 behind) are both about two and a half days off it, which fits inside the time remaining with room to spare.
Fifth is separated by 244 TeraOps, seven tenths of one percent, between Dave Studdert and 3C-714. That one goes to the wire.
@gd_barnes set the pace for the first day and a half of this and is still third on the board having done it in that time. The bronze is his to defend.
This was @Carlos's idea on the forum, which is the only reason the rest of us are racing at all. Six of his seven finds this week landed above n = 500,000, outside the range of his own challenge, which is a kind of luck that deserves something.
@Goldrush8 and @Tuttl3 are both running qualifying work right now and every job of it is going into the record, medals or not. Entry closes at the start, so catch the next announcement and you will be on the board too.
Scoring catches up every few minutes, so the board moves as you work. Four days left, and plenty of it still open. Go well.
QuoteWhat shipped this week (week 39)
andy
andy
2 hours ago
2
A round up of what has changed on the site this week. There is a new client, 3.3.50, on every channel.
Client
3.3.50 drops a number that turns out to have a small factor rather than stopping. prst tries small divisors before it starts a test, and when one divides the number it prints "divisible by 3" with no RES64. The client read that as a failed run, and two failed units in a row trip the safety stop, so a machine exited. Six such candidates had been in the database since April, all divisible by 3, and were handed out again this week. They are deleted from the server, and the client now drops a unit like that without retrying it or counting it towards the stop.
Residues
Some residues on the Jobs page and in the completed range downloads were wrong. The residue itself was always stored correctly. The function that turned it into hex for display rounded on some divisions, so a digit could come out one too high. Everything that shows a residue now shows the right one, and the completed range files have been rewritten. If you downloaded one before Thursday, download it again.
Researchers
k status is a new public page with one row per k: who holds it and the n ranges completed for it. Filter by reserved or unreserved, and switch on external data to include reservations and tested ranges from outside primecrunch. Both reports download as CSV or JSON in one request, so there is no need to page through them.
The sweep
The sweep is in the cell at n = 260,000, and the band from 200,000 to 299,999 is 74.8% done, up from 22.5% a week ago. Most of that came during Sweepstakes.
Work ranges for members who skip tested ranges showed work as ready that the server would never hand them, because the count included ranges already tested elsewhere. The count now leaves those out, the same way allocation does.
Jobs
A finished job gets a coloured tick in place of the pale grey bar that was hard to see: green when crunched, gold with a trophy for a prime. A bar on the Jobs page now always means the job is still yours to finish. Late and stuck share one red, at two strengths.
The Jobs page stays responsive with hundreds of jobs. Above 200 jobs the bands fold to a heading with a count and the next finish time (Needs attention stays open), and the times update every 5 seconds instead of every second. With 590 jobs on the page, the share of the browser's time it used fell from 26% to under 1%.
Forum and pages
Tables work in forum posts and blog posts, with the usual pipe syntax. The formatting help has an example.
Every comment has its own link. Click a comment's time to get a link to it; opening the link scrolls to the comment and highlights it.
Ops are in TeraOps everywhere. The dashboard and platform stats used to switch units with the size of the number. The forum threshold is now written as 1,000 TeraOps, the same amount as before.
Challenge boards update while the page is open, and stop once the medals are awarded.
Charts follow the theme when you switch between light and dark, without leaving the page.
Password resets now have the same 8-character minimum as registering.
Updates no longer take the site down for a moment. Since June every deploy stopped the running API servers before starting the new ones. It now brings the new ones up first, and checks the database is ready for them before it starts.
QuoteClient 3.4.0: a full-screen dashboard
andy
andy
18 hours ago
2
Client 3.4.0 is out on the alpha channel now, should reach beta in about an hour, and stable sometime tonight. Machines on automatic updates pick it up within about an hour and a quarter of it reaching their channel. The big change is the terminal dashboard: started from a terminal, the client now takes over the whole window with four views, and you switch between them with 1 to 4 or Tab.
Work
A summary at the top: tests running and queued, average progress, tests finished per hour, the average time a test takes, uptime, and when results and progress next go to the server.
Each running test with its progress, time spent, speed, time left and the clock time it should finish.
Tests with no progress for 20 minutes are marked stalled. Tests running well behind the others, allowing for the size of n, are marked slow.
The downloaded work in the order it will start, with an estimated start time for each unit.
With more tests than fit on screen it switches to a grid, then to a map with one cell per worker and a list of the tests that need a look. g picks the layout yourself and s sorts the list and grid.
Results
Every test finished this session, with its outcome, RES64, compute time and when the server received it. A PRP or prime gets its own line at the top.
Log
The client's messages, which used to scroll past underneath the old panel. When you quit, the last lines are printed so they stay on screen.
Machine
Version, process count, backlog, where the settings come from (command line or the website), update channel, and the results file if you keep one.
Keys that work from any view
r sends pending results and progress to the server straight away, at most once a minute.
p pauses downloads. Work already on the machine runs to the end and nothing new comes until you press p again. A restart downloads as normal.
q twice, or Ctrl+C, saves and quits. Each test carries on from where it got to next time.
? lists the keys.
Also in 3.4.0
Progress arrives one reading sooner, about 12 seconds on a test near n = 500,000. prst only ends a progress line when it starts the next one, so the client was always one reading behind, both on screen and in what it sent to the server. A new test also showed no progress until its second reading. The client now takes each reading as soon as it is complete.
Plain output when there is no terminal. Under systemd, nohup or a pipe the client switches to plain timestamped lines by itself, so logs no longer fill with screen-drawing codes. -tui=false still does the same on purpose.
Already out in 3.3.51: a results file of your own
This one is on every channel now, so you do not have to wait for 3.4.0. Start the client with -results and it appends a line for every test the machine completes, with the residue. The file is never trimmed or rotated, unlike crunch.log, so it is a permanent record.
-results-format picks the format: jsonl (the default, one JSON object per line), prst (the lines prst writes to its result.txt), prpclient (the lines prpclient writes to test_results.log), or prst-extended and prpclient-extended, which add the test type, Fermat base and certificate RES64.
A residue can only be compared with another from the same test and base, and the classic formats record neither, so use jsonl or an extended format if you may want to compare residues later.
The file goes in the working directory as results.jsonl, or results.txt for the text formats. -results-file puts it somewhere else.
The settings are saved, so you give them once and the machine keeps writing the same file across restarts and upgrades. -results=false turns it off.
./crunch -results -results-format prst-extended
In 3.4.0 the Machine view shows where the file is, and the Results view says so too.
The client help already covers both the dashboard and the results file.
Quote🥇🥈🥉 September on Top Crunchers
andy
September is closed on Top Crunchers. @PDW tops the month for the second month running, with 978,071 TeraOps: 21,929 short of a million in a single month.
Member TeraOps
1 PDW 978,071
2 andy 695,790
3 @Carlos 321,516
4 @3C-714 284,213
5 @Dingo 280,254
6 @Tuttl3 278,742
7 @vcodin 255,001
8 @Dave Studdert 209,335
9 @Floof Dynomyte 173,028
10 @Stef42 103,235
The top ten together did 3,579,184 TeraOps, up from 2,269,604 in August. In August, tenth place took 42,336; in September it took 103,235.
3C-714, vcodin and Dave Studdert are in a monthly top ten for the first time. Carlos went from 42,336 in August to 321,516, and Dingo from 91,209 to 280,254. A good part of that came from Sweepstakes, which ran from 19 to 26 September: 179,053 of 3C-714's 284,213 for the month were scored in that week.
All time. September moved the all-time table as well:
PDW went past @MangoJuice into second, and has more than doubled in a month, from about 880,000 to 1,865,557.
Tuttl3 passed a million and is 3,766 behind MangoJuice in fourth.
Carlos doubled, from about 322,000 to 648,859.
3C-714 and vcodin are new to the all-time top ten, in eighth and ninth.
Thank you all. October's table is already on the page.
QuoteWhat shipped this week (week 40)
andy
A round up of what has changed on the site this week. There is a new client, 3.4.2, on every channel.
Client
The client has a full-screen dashboard. Started from a terminal, it now fills the window with four views, switched with 1 to 4 or Tab:
Work: a summary (tests running and queued, tests finished per hour, average test time), then each running test with its progress, speed, time left and expected finish, then the work waiting to start. A test with no progress for 20 minutes is marked stalled, and one running well behind the others is marked slow. With more tests than fit on screen it switches to a grid, then a map.
Results: every test finished this session, with its outcome, RES64 and when the server received it.
Log: the client's messages, which used to scroll past underneath.
Machine: version, process count, backlog, update channel and where the settings come from.
r sends results and progress straight away (at most once a minute), p pauses downloads, and q twice or Ctrl+C saves and quits. Under a service manager, or with -tui=false, the output is plain timestamped lines as before. The help page has the details.
It draws correctly in the old Windows console. The console window Windows opens outside Windows Terminal has no fallback font, so parts of the progress bars and the map came out as question marks. On Windows outside Windows Terminal the dashboard now uses only characters that console has. Thanks to @Goldrush8 for the help debugging the client on Windows.
You can keep your own record of results. Start the client with -results and it appends a line for every test the machine completes, with the residue, to a file that is never trimmed or rotated. Formats are jsonl (the default), prst and prpclient, plus extended versions of the last two. The setting is saved, so it stays on across restarts. @garyg asked for this in I need a little more info.
The log is smaller, about 220 bytes per test instead of 2 KB. The request bodies and connection details moved to debug level.
Work allocation
Machines with nothing to do no longer get k = 999. Until this week, a machine whose work ranges gave it nothing was handed k = 999, and a member who had set nothing up only ever worked that k. k = 999 is now an ordinary reservation. Every member has a Smallest available work row at the bottom of their work ranges instead, which takes the lowest untested n in the project, the same as the sweep. You can delete it.
If your work ranges do run dry, the machine gets no work and is told why. 3.4.2 shows the reason once and says when work is back. If it lasts more than 15 minutes and one of your machines was seen in the last day, you get one email about it.
Smallest available work ignores "Don't issue candidates that might have been tested elsewhere". That setting still applies to your other ranges.
The sweep
The sweep is in the cell at n = 280,000, and the band from 200,000 to 299,999 is 90.5% done, up from 74.8% a week ago.
Primes
@NanotechSci found the first megaprime on primecrunch by anyone other than me:
2,027
·
2
3,503,676
−
1
, 1,054,715 digits.
Recent primes is a new page listing primes confirmed on primecrunch, newest first: the 1,099 that were discoveries, or all 143,066 with "Include verified and unknown results" switched on.
Top primes loads in about a fifth of a second instead of 6 seconds, and the prover code has its own column.
Public profiles show the primes a member discovered in each 500,000-wide n band, next to the cells they led. @Carlos asked for this in Top Crunchers.
Prime families show "tested to" exactly, to the last whole 10,000 segment (for example 4,299,999), instead of rounded to 250,000.
k pages show the completed frontier to the nearest 10,000 too, so a k moves as soon as each segment finishes rather than once per 500,000.
If you find a prime that is waiting to be reported to t5k, its candidate page shows it to you when you are signed in.
Dashboard and Jobs
An activity calendar on the dashboard shades each day by your TeraOps, one calendar per year, with the number of days you crunched in the last year and your current run. The TeraOps chart above it covers the same 365 days and adds a 7-day average.
Jobs and Queued can be grouped by k, alongside machine and type.
Top Crunchers lists everyone, all time and for each month, rather than stopping at the top 10.
Pages, help and forum
Getting started is rebuilt as numbered steps, with a switch for Windows, macOS and Linux.
"How this page works" links now sit at the top right of each page, and the summary figures at the top of Jobs, Machines, Work ranges, My Primes, Territory and the sweep use one compact layout.
Every help heading has its own link. Hover over a heading and click the # beside it.
Running two copies of the client on one machine is in the help, after @Carlos asked how to split one machine between the sweep and his own ranges.
The white flash before dark mode when a page loads is gone. @PDW reported it in last week's thread: the page did not pick its theme until all of the site's JavaScript had run.
The forum list shows who has posted in each thread, as up to five avatars (the starter, then the most recent), with a name on hover.
The ranges sheet fits the window, with the k header staying in view as you scroll.
Stats that stalled overnight. The nightly backup held locks that some stats rebuilds were waiting on, so they timed out and those figures stayed stale until the next run. The backup now skips those tables, which are rebuilt from the others anyway.
Cruncher Pete has joined the Team so now we are three members. The Team is in 2rd place overall up from 3rd recently.
| Rank | Team | Members | Last 30 Days | TeraOps |
| 1 | Ukraine | 1 | 943,313 | 1,944,059 |
| 2 | BOINC-AUSTRALIA | 3 | 588,895 | 793,270 |
| 3 | mersenneforum.org | 2 | 443,864 | 787,565 |
| 4 | HWBOT.org | 1 | 252,955 | 332,142 |
| 5 | nein | 3 | 33,437 | 182,556 |
| 6 | AMD Users | 1 | 0 | 10,327 |
QuoteWhat shipped this week (week 41)
andy
andy
8 hours ago
0
A round up of what has changed on the site this week. The client is now 3.4.14 on every channel.
Client
Tests can run on more than one thread. Until now every test ran on one thread, one test per core. Start the client with -calibrate on-demand and it gives each test one thread or several, whichever it has measured as getting the most done on this machine. The first time it meets an FFT size it has not measured, it pauses the running tests for a few minutes, tries the splits, and then carries on from where they stopped. The results go in thread-hints.json, so each size is measured once. Small tests still run best one per core. At large n it can be a lot more: on one 8-core machine, two tests of 4 threads did two and a half times as many 720K-FFT tests an hour as eight tests of 1. It is off unless you ask for it.
-p auto lets the client choose how many threads to fill. On a CPU with hyperthreading, running more threads than cores sometimes helps and sometimes hurts, depending on the FFT size. With -p auto the client measures each size on the physical cores, halfway to the hardware threads, and all of them, and uses whichever gets the most done. On the machines page, tick Auto in place of a thread count to do the same for a machine under remote control. @gd_barnes suggested measuring totals between the core count and the thread count in the benchmark thread.
crunch -benchmark measures how many tests an hour your machine gets through with its cores split into tests of one thread or several, at five sizes, and writes a file you can paste into the forum. It runs offline and does not touch your work. Thanks to @garyg, @3C-714, @Floof Dynomyte and @Stef42 for posting results in Benchmark your machine; they are what the thread choice above is built on.
The dashboard shows processes and threads, in total and for each test, and says what it is measuring while it calibrates.
Two fixes:
On Windows, a test the client meant to stop (to re-plan threads, calibrate or cancel work) kept running in the background. It now stops, and carries on from its last periodic save.
A self-update could restart with a prst still running from before the restart. The client now stops taking work, then stops prst, before it restarts.
The client help has the details on all of the above.
QuoteEvery k is complete to n = 400,000
andy
andy
7 hours ago
0
At 17:13 UTC on 14 October the last test below n = 400,000 came back. Every candidate for all 4,500 odd k from 1,001 to 9,999 is now done up to that point: 52.0 million k·2^n−1 left after sieving, 13.0 million of them between 300,000 and 400,000, with nothing waiting and nothing out on a machine.
The 100,000 n from 300,000 up took 9 days, from 18:01 UTC on 5 October, against 17 days for the band below it. About 4.3 million of the band was already done by then, and 8.7 million tests completed in it since, on 71 machines. The busiest day, 8 October, came to 1.2 million.
Each test costs roughly n², so a test at 350,000 is about twice the work of one at 250,000. In TeraOps the band took 1,149,779, at 128,226 a day. The band below took 741,330, at 44,004 a day, so the project put 2.9 times as much work a day into this one.
There are 3,719 known primes between 300,000 and 400,000 for these k, and every one has now been confirmed by our own LLR test. Primes of this form thin out in proportion to ln n, so the 14,196 known between 100,000 and 300,000 predict 3,717 here.
Three of the 3,719 were on no list before we found them:
2,911
·
2
333,069
−
1
, 100,268 digits, @andy, 8 October
8,333
·
2
339,626
−
1
, 102,242 digits, @andy, 8 October
8,025
·
2
347,103
−
1
, 104,493 digits, @Stef42, 9 October
Tests completed between 300,000 and 400,000 since 5 October:
@Stef42: 5,335,244
@Cruncher Pete: 1,313,533
@andy: 870,972
@vcodin: 652,062
@Carlos: 279,635
@Bijouxa: 192,567
@Goldrush8: 65,271
@Floof Dynomyte: 18,437
@3C-714: 3,900
@Tuttl3: 3,083
@Dingo: 2,296
@NanotechSci: 1,845
@Stef42 ran 61% of the band's tests, four times as many as anyone else, and found one of its three new primes. On 7 October Stef42 planned to push the sweep towards 400,000, and a week later it was there. Thank you, Stef42.
Thank you all.
Smallest available work is now handing out n = 400,000 to 409,999. Between 400,000 and 500,000, 5.1 million of 13.0 million candidates are done and 7.9 million are left, about 1.7 million TeraOps of work. At the current split between this band and work above 500,000, that is about 10 days, so around 24 October.