FB Sprint 2026 Notifications

[UBT - Timbo]

Timbo,

the FB-Stats from running sprint seems to hang, the website shows:

Last update : 2026-04-12 14:45 UTC

It should be 15:00 Uhr UTC or even 15:15 UTC

Could you please check this ?

Thanks in advance

Yeti

EDIT: Seems as if it fixed just now with 15:15 UTC

Hi

Sorry for the delay in reply.

Unfortunately, I have NO control over the back-office "stats collection" function of the FB Sprint or FB Marathon.

But usually when a stats update fails, it is generally a short term problem, maybe due to a project website being inaccessible (due to a high load on their server) and an issue with the FB webhosting platform or it's service provider.

I'm glad to hear it corrected itself shortly afterwards.

regards
Tim

[yoyo]

BTW: Yafu has always tasks.
Or what is your source saying it dosn't?

Hi

Sorry for the delay in replying.

My source on 11th April was here:

https://grafana.kiska.pw/d/boinc/boinc? ... 30d&to=now

And with a declining number of tasks being available (since a high of 1,882 on 21st March and a LOW of 882 today, 14th April) so, I sadly had to discount the project from the list of suitable projects that could support the high demand for many, many thousands of tasks during a Sprint.

Of course, if the admin wanted to be involved in a Sprint AND by prior arrangement, they could ensure that when the Sprint started that far more tasks would be available over the course of the Sprint period, then of course the project could be selected.

I am very open to the possibility of Yafu being chosen as a Sprint project - but there has to be sufficient tasks available and for the project website not to be saturated with download requests, causing it to go offline.

regards
Tim

As also in yoyo@home, not all work is already a BOINC workunit in the DB. This keeps DB small and fast.

You can also see that yafu (and yoyo@home) runs never out of work. So your indicator of declining number of available tasks seems to be wrong.

Additional in yafu each result leads automatic to a new workunit. So yafu just needs as much workunits as needed to cycle through the volunteer computer and an additional buffer.

In kiskas grafan you can see, that round about 500 workunits are processed (each of them leads to a new workunit) and that 3 times more tasks, round about 1500, are available to sent out.
You can also see, when tasks in progress are increasing, also available tasks are increasing.

tldr;
What kiskas grafana shows of available tasks and what is base on your decission, is not the reality. It is just a small part of available tasks.

yoyo

[UBT - Timbo]

As also in yoyo@home, not all work is already a BOINC workunit in the DB. This keeps DB small and fast.

You can also see that yafu (and yoyo@home) runs never out of work. So your indicator of declining number of available tasks seems to be wrong.

Additional in yafu each result leads automatic to a new workunit. So yafu just needs as much workunits as needed to cycle through the volunteer computer and an additional buffer.

In kiskas grafan you can see, that round about 500 workunits are processed (each of them leads to a new workunit) and that 3 times more tasks, round about 1500, are available to sent out.
You can also see, when tasks in progress are increasing, also available tasks are increasing.

tldr;
What kiskas grafana shows of available tasks and what is base on your decission, is not the reality. It is just a small part of available tasks.

yoyo

Hi

Thanks for your input.

Firstly, I recognise that every project has their own processes by which they make work units available. And generally, speaking this is not something that is shared in the public domain or to me in person.

So, that puts me in a tricky place as I cannot "guess" if a project can withstand the high demands placed upon it by a Sprint.

And I use the grafana website as an indicator of which projects have available tasks, so I can then de-select all the ones that are offline or have few tasks available - and that website saves me a lot of work as otherwise, I'd have to visit every project website, every day to check the task availability...and frankly, I do not have the time to do this, as in the real world, I have a business to run and I have a personal life as well.

Of course the stats shown on grafana might be slightly wrong...but I do not really have any other choice, as I can select on their website, the length of time to show the stats...so I can look at 7 days worth of stats to see a trend.

Also: we both know that if FB Teams and Members cannot get enough tasks, then a) I get blamed and b) the project gets blamed. And I really want to avoid this, which is why I try to make contact with project admins a week before a Sprint so that they are prepared.

Ultimately, it is up to project admins to generate enough tasks for their day to day operations and if they can ramp up the number of "ready to send" tasks, just for a Sprint, then that's even better.

If you want to send me a PM with a proposal for a specific date when one of your projects would be chosen, then I'm happy to give it a test and we can then see how it goes.

regards
Tim

[UBT - Timbo]

Hi all

The 4th Sprint starts next week !!

2026-04-09 18:00 UTC - 2026-04-12 18:00 UTC

Edit: 9th April In case you did not know, it's NumberFields

regards
Tim

Hi all

I had this message back from the NumberFields admin concerning the above Sprint:

I just wanted to let you know, the sprint went very well (from my perspective). The estimated time left on the current batch of work dropped from 210 days to 61 days. This estimate is based on the task rate, so that would imply at least a 3x increase in throughput. I think that's the best it's ever been.

Thanks again and I appreciate you selecting us for the sprint.

So, there we have it - a great success for the project and all due to those who contributed their hosts by helping the project during the Sprint.

Thanks to everyone who took part !
Tim

[UBT - Timbo]

Hi all

The 6th Sprint starts next week !!

2026-04-30 23:00 UTC - 2026-05-03 23:00 UTC

and the project has now been randomly selected.

Once their admin confirms there are no planned maintenance periods for the above dates and that tasks will be available, then it will be "locked in".

UPDATE: Admin has now confirmed that all should be well for the forthcoming Sprint #6 !

regards
Tim

[JeromeC]

This year L2 is a PINA for me as expected

Do we know how L4 is quite more powerful than L3 ? on this sprint the 1st in L3 would have achieved only 8th in L4

[Tamagoch]

Do we know how L4 is quite more powerful than L3 ? on this sprint the 1st in L3 would have achieved only 8th in L4

L4 is for newcomers whatever computing powers they posess

[UBT - Timbo]

L4 is for newcomers whatever computing powers they posess

Hi

Yes, this is correct.

A brief explanation:

Each year, I tabulate *all* of the BOINC credits earned by each of the Teams and the Members in the Sprints and then, depending on the average credits earned per Sprint, each Team and Member is ranked and then they are placed in one of the 4 Leagues.

And I try to pitch Teams with similar average BOINC credit totals, in the same League table. And it is the same with Members.

The lowest ranked Team and Members are placed in League 4 as are any new Teams/Members, who I have no idea of how well they might be able to generate BOINC credits. So, once they have "proved their worth", they will probably be elevated in the following year.

So, the League tables do represent how well each Team (and each Member) performs throughout the 24 Sprints. This is because it is the Sprints that can generate the most FB points - and at present there are only 22 projects "active" on the Marathon and some of those are borderline in terms of how active they are during the year

regards
Tim

[UBT - Timbo]

This year L2 is a PINA for me as expected

Do we know how L4 is quite more powerful than L3 ? on this sprint the 1st in L3 would have achieved only 8th in L4

Hi

I do sympathise with you...but across all of the Sprint projects, some Teams (and Members) will favour certain projects, just due to their personal choices of which project they like. So, it could be that on average, more L4 Members use host machines that are more suited to a specific project than the L3 members. And this is going to vary across every Sprint and every selected project !

And of course, some projects award higher credits, for GPU based tasks, compared to CPU tasks. And it is likely that there are many external factors and variables that will mean that on any given Sprint project, the number of credits earned by a Team (or Member) will not be proportional to the League table they have been assigned to.

In your case, you earned 49,173,304 BOINC credits on Sprints in 2025. This compares very favourably with the average BOINC credits earned by League 2 members of just 32.3m during the year. You took part in 22 Sprints, though the average for L2 Member Sprint participation was just 16.

For comparison: League 1 members earned an average of 216 million BOINC credits across all the Sprints in 2025. League 3 Members earned an average 7.4m in 2025 and (excluding one member** in League 4), the average BOINC credits earned was just 1.1m.

(Note: ** That one L4 member took part in just one Sprint (#15) and earned 158 million BOINC credits, which increased the average to 4.1m !!)

Hope this helps.

regards
Tim

[JeromeC]

Hope this helps.

Yes no worry Tim, I perfectly understand, and on top of all that we must consider that individual behaviour of each member (= involvement) may also greatly vary from one year to another, so there is no magic wand to make the perfect mix ! I just hope I go back to L3 next year