Sprints 2025 - timetable and projects selected

[UBT - Timbo]

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.

Hi yoyo

Speaking honestly, I have absolutely NO REASON to arbitarily think up reasons or excuses to exclude yoyo project.

However, as I already mentioned, the fact is that there is a high probability that FB Sprint members might find they are being sent very long run time tasks, which they have no way of completing within the 4 day Sprint "window".

And you offer *no* choices to members to download specific work units that have a short run time.

At least with PrimeGrid, there are many different types of work units - some are long and some are much shorter - and members *can* choose which ones suit their hardware AND the PrimeGrid website indicates the typical run times for each sub-project of work units.

And for both the FB Marathon and the FB Sprint (when PrimeGrid is selected), *any* credits earned on *any* class of work unit counts towards the members total - so members do not have to select any specific sub-project of work unit.

yoyo project does not offer a choice of being able to select short runtime tasks.

And this is why I think in the new year, we can discuss whether yoyo can allow members to select which type of work units they can download.

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.

Yes, I know this...but just look at the range of "typical" completion times:

Code: Select all

ecm from 0.43 to 101.08 hours !!
Siever from 3.00 to 18.21 hours 
ecm P2 from 0.35 to 60.91 hours !!

So, the ecm tasks could be almost impossible to complete more than one task (per CPU) within the 96 hours of a Sprint.

Of course, there is a real risk that FB members would download some tasks and then selectively ABORT all those tasks that have long run times and these will go back into the queue, using up more of the server bandwidth as tasks are downloaded, aborted and then more new tasks are requested...only for even more to be aborted.

And this also will require member to micro-manage their host machines to ensure they can select which tasks they want to crunch.

This is SERIOUSLY unacceptable to me and I guess most FM members would also have better things to do with their lives, than to have to watch their host machines every few hours so they can abort unwanted tasks.

As I said before, let's work together in the new year and find a way for you to allow short run time tasks to be made available for a Sprint.

regards
Tim

[yoyo]

You can select which subproject you want and the long runtimes are the max values and mostly from slow ARM devices. On the charts you see the average runtime for always the last 100 results.

And as you already stated you used the criteria of less "ready to sent workunits" from Kiska*s Grafana. This value is not a criteria, because outside of the Boinc DB is nearly infinite work. I just put not millions of jobs into the DB and make the DB slow. This is one measurement to stay stable in big races also on small server, as yoyo did in last 15 years. This BTW I described here https://www.rechenkraft.net/wiki/Benutz ... ver_Tuning and offered also help in the past to projects which crashed during race.

I think you should rethink about the rules for Sprint projects. You can see that only 8 projects are used in 24 sprints. But there are much more projects which have work. Even if a project is not perfect and has long tasks or too short tasks or runs partly out of work or has only work for CPU or doesn't allow bunkering or, or, or... , those are conditions with which all teams have to deal with. This makes a race more interesting and thrilling.

Anyway, those are just my 2 cent. I will not make a app for races.

[UBT - Timbo]

Hi yoyo

Thanks for your feedback.

I do understand your position, but you need to recognise mine.

I volunteered to take on this job as admin for both the forum and for the Sprints simply because a) Sebastien did not have the time and b) because there were so many "bad actors" on this forum who would complain about many different, even crazy, things, including the availability of work units from Sprint projects.

So, I have to weigh up the pro's and con's of which projects are suitable for a Sprint and that's why I made a set of "rules" that I think are reasonable. And as I have already mentioned, some projects are no longer making enough tasks available for a few hundred FB host machines to then start downloading (and maybe filling up their bunkers) at one second after the project is announced.

And I prefer to be the captain of a steady ship, and not one that is rocking from side to side due to negativity. And since I took over, this forum is now a more friendly and positive place to visit. There is no abuse, no bad sh1t happening and everyone can enjoy being part of the FB "support" that we give to projects.

So, if you are not able to support the needs of the FB Sprint, that's fine - and I do not expect you to "build" a special app - but I would suggest you make more sub-projects available so that BOINC crunchers can selectively choose either short, medium or long duration ECM tasks. That's just makes a whole lot more sense?

And you can continue to be a project that is part of the Marathon, if you so wish.

regards
Tim

[UBT - wbiz]

You can select which subproject you want and the long runtimes are the max values and mostly from slow ARM devices. On the charts you see the average runtime for always the last 100 results.

Its not just slow ARM processors, how about a AMD EPYC 9354P 32-Core Processor [Family 25 Model 17 Stepping 1] taking 26 DAYS https://www.rechenkraft.net/yoyo/workun ... d=81593820

You have the true stats, you know the truth.

[yoyo]

The workunit was sent on 2.12. and received back on 4.12..
SO very fast 26 days

[Tamagoch]

The workunit was sent on 2.12. and received back on 4.12..
SO very fast 26 days

CPU time of course, but most of us do not posess EPYC

the discussion may be going to loop of no compromise, so let us do some clear decisions:

1. The project 'yoyo' naturally unable to be divided by subprojects or project admin has no time|wish to do so. Yes or no. Whatever the cause, we will just understand that it is impossible to control the tasks lenght.

2. Regardless of #1 could we make a test sprint for yoyo so we make an evaluation how it goes for real?

I would like to try this one at a full speed

[UBT - wbiz]

The workunit was sent on 2.12. and received back on 4.12..
SO very fast 26 days

So what went wrong there?

In the opposite direction, work unit with zero CPU time and zero claimed credits getting awarded credits. https://www.rechenkraft.net/yoyo/workun ... d=81601271. The results log show CPU time was spent, there is something going very wrong.

The scoring is going wrong elsewhere, if I have no "buddy" I get low credits awarded, if I have a "buddy" my credits usually get boosted. I do the benchmarks every time boinc has been restarted.