Posts by Grant (SSSF)

1) Message boards : News : NumberFields Is Back (Message 4377)
Posted 1 hour ago by Grant (SSSF)
Post:
Well, the web site is back.
But uploads, downloads & Scheduler requests are still slow/timing out and taking a couple of tries to get through.
And posting takes forever to finally happen.

Some network/server issues?
AI bot attack?
2) Message boards : Number crunching : Control both CPU 4.00 and GPU 4.02 simultaneously (Message 4357)
Posted 1 Jul 2026 by Grant (SSSF)
Post:
KISS always has and always will apply.

Running with a reasonably sized cache would stop the issue from occurring, negating the need for convoluted app_config based fixes, which will most likely result in other issues that will then need to be addressed.
*shrug*
3) Message boards : Number crunching : Control both CPU 4.00 and GPU 4.02 simultaneously (Message 4351)
Posted 30 Jun 2026 by Grant (SSSF)
Post:
Your cache is too big.

Given the number of projects you are running, and if you feel that for some odd reason that you need to have a cache, make sure you set your cache to
0.2 days
and 0.01 additional days.

Otherwise, 0.97 days and 0.01 additional days would be plenty.


Then leave things alone for a few days to let them settle down.
4) Message boards : Number crunching : Gerasim is not working (Message 4282)
Posted 28 Apr 2026 by Grant (SSSF)
Post:
Why do I loose points in the last time? On april the 17th to the 18th and 26th to 27th.
Two posts before yours, Eric explained why.
5) Message boards : Number crunching : why later deadline executed first? (Message 4260)
Posted 6 Mar 2026 by Grant (SSSF)
Post:
I guess it's possible the server could be telling the client to abort unstarted work units that are past their deadline. But according to Google Gemini:
Yes, the BOINC Manager can and does automatically abort work units that it determines cannot be finished before their deadline, particularly if they are significantly past due or stalled.
Gemini is technically correct, but it is also wrong.

There have been cases where projects have had major unexpected extended downtime, and the project configured the Scheduler to extend the deadlines for all previously issued Tasks before bringing the servers back on-line again.
That way even though it might have been weeks (or longer) since the deadlines passed, all systems that processed those tasks with the past due deadlines were able to get Credit if they validated once they had been reported.
Even though the deadline was long past, the BOINC Manager didn't drop the Tasks from the systems. They were still there to process, because it couldn't contact the project servers.


Yes, the BOINC Manager does cancel Tasks that haven't been started by their deadline, but it can only do so after it has contacted the project server and got a valid response from the Scheduler.
The deadline may pass, but unless the Scheduler tells the Manager to drop the Task, it won't; and BOINC will continue to process any Tasks that are past their deadline.
6) Message boards : Number crunching : why later deadline executed first? (Message 4256)
Posted 4 Mar 2026 by Grant (SSSF)
Post:
Too late to edit things, but the initial deadline is 7 days (not 6 as i kept posting for some odd reason).
7) Message boards : Number crunching : why later deadline executed first? (Message 4254)
Posted 4 Mar 2026 by Grant (SSSF)
Post:
I finally understand. The system is sending me a mix of tasks, including some that are re-sends because they timed out *on other people's systems* . Those re-sends have shorter deadlines.
Yep.


This is not the case that tasks are timing out *on my system* .
Correct.
The resends occurred because they timed out (missed the deadline) on those other systems, not yours.


It looks like you started doing Numberfields work on that computer on the 26 Feb?

As work is returned, over time the BOINC Manager will monitor how many hours a day the computer is running, and when running how many of those hours it is able to process Tasks and eventually it will settle down- if your cache is set for around 3 days or so, then you may continue to see some more recently downloaded Tasks being done before earlier downloads in order to avoid missing deadlines.

If it's set for less than 2 days, then eventually that behaviour will cease, and it will just process the work in the order it was downloaded (First In, First Out- unless of course there ends up being a day or two where the computer isn't running and no Tasks can be processed, so then it'll concentrate on those most at risk of missing the deadline until it catches up again...).
8) Message boards : Number crunching : why later deadline executed first? (Message 4251)
Posted 3 Mar 2026 by Grant (SSSF)
Post:
1 Your system is overcommitted- ie it's busy trying to do other work as well as BOINC work.
BOINC Tasks are set to run at a low priority level, so they make room for other things running on your computer. That's why it takes your system 7hrs 26min to do 6hrs 40min of actual work (eg Task 282411806)

2 And while your average turnaround time is 1.1 to 1.2 days, there are Taks (such as the one i referred to), which are taking you almost 2 days (or more) to return.

Normal Tasks have a 6 day deadline. Re-sends (those where a Task has been sent out, but no Valid result was returned by the deadline) have a 3 day deadline.

The BOINC Manager does it's best to return all downloaded work before the deadline is reached; so if there are Tasks that are in danger of missing their deadlines, it will start processing those before previously downloaded Tasks. If things are really bad, it will even stop processing currently running Tasks and run those at risk of being late (and if they are late, they may not get Credit).


Reduce the number of cores/threads being used by BOINC (or find out what else is using so much of your CPU time).
If your system is set to suspend computation while the computer is in use, change it to not suspend.
But mostly- Set a smaller cache eg
1 day + 0.01 additional days.

That way, you won't run into deadline issues, and that way BOINC will continue to run in it's default mode- which is First in, First out.
9) Message boards : Number crunching : NumberFields@home | Project requested delay of 31 seconds (Message 4242)
Posted 19 Feb 2026 by Grant (SSSF)
Post:
I think a 31 second project update frequency is too often. I recommend something in the order of 2 minutes or 3 minutes. I have a NVIDIA RTX 5070 Ti the fastest turnaround of task is over 3 minutes.
So a RTX 5090 will knock them over in around 1min 30 sec or less.



A 121 second project update rate is what WCG (World Community Grid) uses.
WCG's seutup could best be described as "extremely fragile."
Not to mention a few hundred thousand more users (and even more systems) than here.



Seems like a longer update rate from clients would lower the server (and client) loads, lower network traffic, etc would be better.
That tends to only be in the case of when recovering from an outage.
The rest of the time the BOINC manager on the clients does incremental increases in the delay before re-trying when it encounters a project server/network error.


The 30second server backoff stops clients from being set to hammer the server every few seconds to try to get work if the supply of work is limited and their cache is low, but allows them to re-fill their caches quickly when work is readily available.
eg after project/network outages.

Given the reliability of work here, i doubt increasing the server timeout delay will have much if any effect on it's load, but it will mean that it'll take a few extra tries before those with large caches can re-fill them after an outage.
And it will significantly increase the time it takes for everyone to return and report and get new work when there are connection issues occurring (eg when there are challenges on).
10) Message boards : Number crunching : Gerasim is not working (Message 4232)
Posted 17 Feb 2026 by Grant (SSSF)
Post:
Yes. I have to delete all such certificates in the popoup not just myphone to get it to work. Browsers only show the certificate selection UI when they have valid candidate client certificates to offer.

After seeing that behavior I read up on why this happens.

The issue is caused by IIS configured to send a TLS CertificateRequest before the handshake.
Once a connection has been established for the first time for a browser, IIS doesn't reissue that request. Also if the browser has no client certificates to offer, it doesn't launch the popup and sends back that it has no certificate to provide.

Its likely that under SSL Settings in IIS, client certificate requests are set to "Accept". This is because clicking cancel gives you access to the website and deleting all client certificates also works. If it was set to "Require" it would block access entirely. Most websites would set this to Ignore, unless they have a valid reason to request a client cert, which is usually on corporate intranets with special authentication requirements. That's the most likely suspect causing the issue, but there could in theory be something else causing the server to issue the CertificateRequest
If neither the sever has it's issue, nor the client has it's issue, the client can connect.
If the server has it's issue, but the client doesn't, the client can connect.
If the client has it's issue, but the server doesn't, the client can connect.
If the client has it's issue, and the server has it's issue, then the client can't connect.

So the problem is due to issues with both the client and the server, but both need to be present for the client to be unable to connect.
11) Message boards : Number crunching : Gerasim is not working (Message 4227)
Posted 16 Feb 2026 by Grant (SSSF)
Post:
In fact, participants don't need certificates, and there's no need to know about them.
Anything that makes use of HTTPS makes use of certificates, and yes there should be no need for users to be aware of them- however when server certificates lapse, or there are issues with certificates used by certain programmes, or there are issues with how an OS handles them, then unfortunately people need to know about them in order to resolve that issue (other than waiting for the server, programme or OS to be updated to fix the issue, assuming that ever happens).
12) Message boards : Number crunching : Gerasim is not working (Message 4218)
Posted 15 Feb 2026 by Grant (SSSF)
Post:
I am aware about my website & how to access it. I do not see how this has any relevance with the Boinc project in question. Thank you for your concern though
Because its easier to blame you then admit the Gerasim site/project is still not up to proper working order.
No, that is not the case.
If you had taken the time to actually read any of the posts you would realise the issue is with Speedy51's system.

There may be all sorts of issues still remaining with the Gerasim project, but accessing it's web site isn't one of them.
13) Message boards : Number crunching : Gerasim is not working (Message 4196)
Posted 10 Feb 2026 by Grant (SSSF)
Post:
No problems here from Darwin in Australia using MS Edge.
14) Message boards : Number crunching : Gerasim is not working (Message 4180)
Posted 1 Feb 2026 by Grant (SSSF)
Post:
For reference, i found a GT 720 that successfully completed a Task.
10hrs 35 min

Better to not use it at all IMHO.
15) Message boards : Number crunching : Gerasim is not working (Message 4178)
Posted 27 Jan 2026 by Grant (SSSF)
Post:
I thought this bound was set conservatively, but I could revisit it. Either way, I don't think the parameter can be changed in the current set of WUs, but I can increase it in the next batch.
GeForceGT730
This card was released 12 years ago.
It has only 384 CUDA cores.
It is also an abomination.
Some cards used GDDR5, others DDR3!

It's OK as a video card, but it's useless for compute work.
16) Message boards : Number crunching : Gerasim is not working (Message 4177)
Posted 27 Jan 2026 by Grant (SSSF)
Post:
Is it possible your benchmarks think your GPU is much faster than it really is? The benchmarks are used to convert the FLOPS bound into a time bound, and 1138 sec sounds too fast for your card. Maybe you could rerun benchmarks, or find a way to spoof them to make your GPU look slower.
Only the CPU has benchmarking to determine it's actual performance.
With GPUs it's hard coded using the GFLOPs reported by the driver, from the video card.
17) Message boards : Number crunching : Reduced credit per work unit (Message 4152)
Posted 16 Jan 2026 by Grant (SSSF)
Post:
I wouldn't worry about overall credit as long as it is fixed going forward as you mentioned.
Yep.
I'm not overly fussed about the Tasks that have already been done with the lower Credit, just glad it's been sorted and all new Tasks are resulting in a more appropriate level of Credit.



You're one of the most communicative and responsive Admins of Projects around
Actually, in a league of your own.
A great example for all the other projects IMHO.
18) Message boards : Number crunching : Reduced credit per work unit (Message 4146)
Posted 15 Jan 2026 by Grant (SSSF)
Post:
That does sound like a problem. I do know that the WUs for the new batch should take longer, so the credits should be higher. I might have inverted the scale factor.

I am currently on vacation, so I won't be able to fix this until I return in 2 days.
Hope you've had a good break, looking forward to your return- RAC has been in freefall for the last few days.
19) Message boards : Number crunching : Reduced credit per work unit (Message 4141)
Posted 14 Jan 2026 by Grant (SSSF)
Post:
Has there been a hiccup with the system?

The current work going through is taking way, way, way longer to process (what were approx 3hr CPU Tasks, are now taking 4-5+hrs), yet the amount of Credit per Task has been reduced?
The reduced throughput of the previous batch resulted in a big drop in RAC (301k dropped to 265k for one system), but this will be even larger again.
20) Message boards : Number crunching : FP64 (Message 4129)
Posted 3 Jan 2026 by Grant (SSSF)
Post:
So my 4070 ti, which takes 3, 4 minutes per task, runs about the same number of tasks per hour?
Roughly.
I'm using the Remaining (estimated time) for unstarted Tasks for comparisons- you're running BOINC 8.2.8 which from memory that got broken and no longer updates as Tasks are returned.


So based on my current numbers
RTX 4080 Super  10min 17sec, 3 at a time = 420 per day.
RTX 4070TI Super 7min 56sec, 2 at a time = 363 per day.
RTX 2060 Super  11min 26sec, 1 at a time = 126 per day.
I worked out what gave the best output per 24hrs ages back, before these much longer running Tasks. So running one less Task may give better throughput, but it probably wouldn't be much of an increase.

If i get bored and have some time i might have a play and see if it is worth it or not.

Basically download a day or more's worth or work, then turn off the BOINC network connection.
For 1 Task at a time do at least 40 Tasks, manually work out their average processing time, then change the number of Tasks to two, do at least 80 Tasks, manually work out their average processing time, etc,etc (making use of GPUz to see what the GPU load is- if it's sustained over 90%, then there's no point running more Tasks, a bit less than 90%, might as well try it and see. Less than 70% is almost always worth running another Task. Less than 60%, it's always worth running another Task).


Next 20


Main page · Your account · Message boards


Copyright © 2026 Arizona State University