- Welcome to BOINC-AUSTRALIA FORUM.
News:
If you have forgotten your password use your email address to reset HERE
Recent posts
#44
YAFU / Re: Project Updates
Last post by Dingo - September 13, 2026, 12:38:26 PM #45
NFS@HOME / Re: Project Update
Last post by Dingo - September 13, 2026, 12:36:51 PMQuote[NFS@home] GPU sieving
Work has progressed nicely on the GPU sieving apps based on cuda-sieve. Linux and Windows apps are now available for NVIDIA GPUs, with support extended to Maxwell (such as the GTX 970) and newer GPUs with at least 4 GB of GPU memory.
For AMD, the code has been ported using HIP, and a Windows app is now available supporting all RDNA-based GPUs (Radeon RX 5000 series and newer) with at least 4 GB of GPU memory.
If you have a supported GPU, give it a try!
View article · Sat, 12 Sep 2026 20:02:19 +0000
#46
OPEN DISCUSSION / Re: Mersenne forum news?
Last post by Dingo - September 13, 2026, 10:50:45 AMhttps://www.mersenneforum.org/
Maybe something on SrBase as they are in collaboration with the Mersenne CRUS project.
https://srbase.my-firewall.org/sr5/
QuoteSome bad things have happened to the forum so we have been forced to turn it off.
We will try to post more details before noon (CST) on September 9th.
We think things are fixable. If you want to assist please contact us.
Mike (Xyzzy)
Maybe something on SrBase as they are in collaboration with the Mersenne CRUS project.
https://srbase.my-firewall.org/sr5/
#47
OPEN DISCUSSION / Mersenne forum news?
Last post by ryzenmulti - September 13, 2026, 09:28:37 AMHowdy all. Wondering if anyone knows what has happened to the mersenne forum recently? I follow it for general prime math news and prime gap data.
Have spent some time there solving the Hardy Littlewood asymptote for every prime pair gap that includes jumping champion predictions. It allows me to derive an accurate prime gap histogram at any very very large X (up to e^180) that reconstructs the prime count with an accuracy better than 1e-5 using only gap counts. For anyone who cares to search, the first occurrence for a prime gap g=30000 is around e^180 (1.48938e78) - only 79 digits.
Given up finding a record twin count ... it is an academic exercise that takes time (and cooling/GPU energy costs) that I don't have. Now modelling a Riemann Hypothesis proof framework using Claude Code and GPT codex which is a bit of fun and time waster. Running a machine on GFN18 over at primegrid for giggles ...
Have spent some time there solving the Hardy Littlewood asymptote for every prime pair gap that includes jumping champion predictions. It allows me to derive an accurate prime gap histogram at any very very large X (up to e^180) that reconstructs the prime count with an accuracy better than 1e-5 using only gap counts. For anyone who cares to search, the first occurrence for a prime gap g=30000 is around e^180 (1.48938e78) - only 79 digits.
Given up finding a record twin count ... it is an academic exercise that takes time (and cooling/GPU energy costs) that I don't have. Now modelling a Riemann Hypothesis proof framework using Claude Code and GPT codex which is a bit of fun and time waster. Running a machine on GFN18 over at primegrid for giggles ...
#48
WORD LINK / Re: Word Link 2
Last post by Cruncher Pete - September 13, 2026, 09:20:29 AMToasted~
#50
Prime Crunch / Re: Project Update
Last post by Dingo - September 12, 2026, 11:42:12 PMQuoteWhat 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.