Sprints 2025 - timetable and projects selected

[UBT - Timbo]

Be careful with this page, it's partially broken.
It says, for example, that Einstein and Private GFN has no task available, but it's not true. These projects are correctly monitored by other site:
Einstein
GFN

Hi

I actually use multiple resources to check server uptime, task availability, task queues (such as "awaiting validation" etc) and any information about maintenance periods or downtime suffered due to hardware issues etc.

regards
Tim

[UBT - Timbo]

That keeps the question open why yoyo@home wasn't selected even once and some projects are already the 3rd time a Sprint project.
Which rule has yoyo@home not fullfilled? There are always a lot of jobs available.

Hi

All I can do is to check on the number of jobs/tasks available in the week or so, BEFORE each Sprint.

And right now, this is what it looks like for yoyo project:

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

which currently shows this for the last 30 days:

yoyo-tasks-november-2025.jpg (131.74 KiB) Viewed 203 times

So, with just 6,432 tasks available to send at this moment in time, this is not going to last very long - and then the Sprint will be criticised for choosing a project that cannot support a Sprint with enough tasks.

I would suggest that rule #2 applies - we have over 130 registered FB members and 35 teams (which includes UNregistered members whose credits still count for their team - so, ideally there's needs to be tens (even hundreds) of thousands of available tasks to support the demand for a Sprint.

Of course, if we can reach an understanding that you can make more tasks available to support a Sprint weekend (and only making them available once the Sprint starts, so no-one suspects that the project has been chosen), then of course I would be more than happy to make sure the project is selectable, as there are not enough projects that can support a Sprint.

So, lets have a chat in the new year and we can see how best to support the yoyo project in a Sprint?

regards
Tim

[Tamagoch]

Hi Tim and everyone,

I believe some projects are able to generate new tasks quickly to keep the ready-buffer constantly at 6k level for example, so yoyo possibly does. As Asteroids are showing us, 'tasks available' status doesn't mean the cruncher would get some immediately. And from the other side these 'infinite' math projects like yoyo and Moo! are maybe creating tasks in real time because there's not much data to deal with.

My offer is: winter tests!

Test one will be a private test and will take place at the Circuit de Barcelona-Catalunya between January 26-30, while test two will be held at the Bahrain International Circuit between February 11-13. The Bahrain International Circuit also hosts test three from February 18-20

So we can test three new projects for sprint entry and decide on their future in the coming season. There shouldn't be any points for those but marathon still counts as usual. Additionally it would be nice to have a separate results table for tests.

It could also be used for corrections in league distribution, if you'd like to do so, Tim )

And I hope it would help to maintain better variety in our competition.

[UBT - Timbo]

Hi Tamagoch

Thanks for your message and some good information and suggestions there !!

As far as the projects go, of course each project will set up their server(s) to suit their needs so it is very difficult to guess what the project admins are doing to both protect their systems from DDOS attacks (which we have seen with Asteroids project for instance) and for minimising any potential issues in terms of server management and keeping the tasks "flowing".

And sadly, NONE of the projects are being "pro-active" with regards to supporting Formula BOINC, as it is ALWAYS dependent on me to ask the project admin if it is acceptable to them for hundreds of FB volunteers to dedicate their hosts on their projects tasks.

**No one has actually contacted me and booked a specific calendar date where they will set up their server to provide enough tasks for both their regular volunteers as well as the FB membership. **

re: Testing

I will ask Sebastien if he wants to set up some testing dates, in advance of the 2026 F1 season. We did actually do something like this in "pre-season" in 2024, so as to check the coding changes that Sebastien had made when the website was "refreshed".

https://www.formula-boinc.org/sprints.p ... eam&race=1

But to test the "back-office" coding, these two sprint did give FB points to those who had contributed the most. So, if we want to follow this in 2026, I think that FB points should be awarded...as committing some/all of a members hosts to these tests is justified. But it shouldn't really be necessary, *IF* projects made sure they had plenty of tasks available all the time !

I also think there is room for some tweaks to the conditions as to how the FB points are awarded. Currently, it is purely based on credits awarded within the set period so for the Marathon, from 1st Jan-31st Dec and for the Sprints it is for the 4 days leading up to the actual time when the F1 is due to finish (which is 2 hours AFTER the race start time). But more on that in due course !

regards and thanks again
Tim

[yoyo]

Hi Tim and everyone,

I believe some projects are able to generate new tasks quickly to keep the ready-buffer constantly at 6k level for example, so yoyo possibly does. As Asteroids are showing us, 'tasks available' status doesn't mean the cruncher would get some immediately. And from the other side these 'infinite' math projects like yoyo and Moo! are maybe creating tasks in real time because there's not much data to deal with.

Exactly, this is the case for yoyo@home. To keep the DB small and fast the workunit generator creates new workunits if the ready to sent workunits for an app goes below 1000. What you see as "ready to sent" in Boinc are just the number in the DB. Outside there are infinite workunits.
If I'm ask for a race (Pentathlon, FB Sprint or something else), yoyo@home was always prepared for it and could handle it the last 15 years.

yoyo

[UBT - wbiz]

Hi Tim and everyone,

I believe some projects are able to generate new tasks quickly to keep the ready-buffer constantly at 6k level for example, so yoyo possibly does. As Asteroids are showing us, 'tasks available' status doesn't mean the cruncher would get some immediately. And from the other side these 'infinite' math projects like yoyo and Moo! are maybe creating tasks in real time because there's not much data to deal with.

Exactly, this is the case for yoyo@home. To keep the DB small and fast the workunit generator creates new workunits if the ready to sent workunits for an app goes below 1000. What you see as "ready to sent" in Boinc are just the number in the DB. Outside there are infinite workunits.
If I'm ask for a race (Pentathlon, FB Sprint or something else), yoyo@home was always prepared for it and could handle it the last 15 years.

yoyo

yoyo had two sprints in 2023, I haven't looked back at the feedback from those sprints but I suspect there were moans about randomly long tasks. Long tasks aren't suitable for sprints eg if a task takes 25 hours you can only get 50 hours work out of a 72 hour sprint plus you lose the competitiveness of monitoring scores changing regularly during the sprint.

I'm sure I aborted more than one task recently that were estimating 29 days albeit on one of my slowest computers (Raspberry Pi4), I've aborted tasks that had 3 days of work done because it is pointless leaving them running if they are going to continue a long way after the deadline and get no credits.

At this moment in time if it was not for those extra-long tasks (way beyond the deadlines) I would have four RP4's and one RPi5 on yoyo all day, instead they are on asteroids which isn't on my current list of target projects.

[UBT - Timbo]

yoyo had two sprints in 2023, I haven't looked back at the feedback from those sprints but I suspect there were moans about randomly long tasks. Long tasks aren't suitable for sprints eg if a task takes 25 hours you can only get 50 hours work out of a 72 hour sprint plus you lose the competitiveness of monitoring scores changing regularly during the sprint.

I'm sure I aborted more than one task recently that were estimating 29 days albeit on one of my slowest computers (Raspberry Pi4), I've aborted tasks that had 3 days of work done because it is pointless leaving them running if they are going to continue a long way after the deadline and get no credits.

At this moment in time if it was not for those extra-long tasks (way beyond the deadlines) I would have four RP4's and one RPi5 on yoyo all day, instead they are on asteroids which isn't on my current list of target projects.

Hiya

Actually you've just mentioned something that is HIGHLY relevant.

Projects that are suitable for a Sprint need to be able to offer a large number of relatively short tasks, which can be downloaded from the moment the Sprint starts and that can completed (succesfully) quickly within a short period of time.

And checking a few randomly selected "tasks" on the yoyo website, I can see that tasks are taking from around 4,000 seconds (just over 1 hour) to nearly 40,000 seconds (about 11 hours).

Here is one example

https://www.rechenkraft.net/yoyo//resul ... tid=534840

And given the inconsistent amount of time taken for each task, implies that anyone who takes part in a Sprint might only finish maybe 12-15 tasks over the 4 days, which is hardly a fair way of allowing FB members to be rewarded if one host is allocated lots of short tasks and another host is awarded very long tasks.

And sadly, the credits awarded are not proportional to the time take:

Code: Select all

Result ID 	Work ID		Outcome	Client State	CPU Time	claimed credit	granted credit
115309121	81653798	Success	Done		4,197.53	148.22		90.97

115307303	81587613	Success	Done		38,867.82	1,372.50	685.21

So, maybe a suitable range of short duration tasks can be made available specifically for a Sprint?

Otherwise, maybe yoyo project is not so suitable for a Sprint?

regards
Tim

[yoyo]

Sorry guys, Primegrid has also very long running tasks on CPU. I have some which runs for many days.
It sounds that you just look for arbitrary reasons to exclude yoyo.
I just require fairness between projects which are usable for sprints.

The runtimes for the last month are openly communicated here https://www.rechenkraft.net/yoyo/server_status.php and yes, sometimes there are long running jobs, especially on Raspi.

[Tamagoch]

Hi yoyo,

is it possible to divide ECM task to more subprojects like short/average/long as for example SRBase did for its CPU tasks? Then it would be likely no more reasons to avoid this project for sprints. In Primegrid we have a huge number of subprojects to choose and mostly the shorter ones are used for sprints

[UBT - wbiz]

Sorry guys, Primegrid has also very long running tasks on CPU. I have some which runs for many days.
It sounds that you just look for arbitrary reasons to exclude yoyo.
I just require fairness between projects which are usable for sprints.

The runtimes for the last month are openly communicated here https://www.rechenkraft.net/yoyo/server_status.php and yes, sometimes there are long running jobs, especially on Raspi.

Its not so much the absolute length of task that is a problem, its the massive ratio between the shortest task and the longest task in a given application which sometimes exceeds 30:1. I had a good spell of a week or more without any extra-long tasks then I got a chunk of tasks in that are way beyond and this has also nearly always happened during sprints.

I'd love to see yoyo in the sprints but as @Tim says it wouldn't be suitable unless you or the user can filter out the excessively long tasks, many competitors would give up halfway through the sprint. The alternative is that long tasks have trickle up credits but I imagine achieving that would be a whole world of pain at your end if indeed it is possible for your applications.