On our machines the runtimes of the old an new workunits are comparable. So far I don't have enough results for a statistical evaluation.
My observations thus far across several of my hosts (those that have been able to get any new O3 tasks, that is) with different architectures and power ratings suggests that the run-time for the new low-frequency tasks are 2-3 times of the old high-frequency tasks. That in itself isn't a major problem, but the estimated run-time for the new tasks is a fraction of the old tasks. This causes a huge skew in work requests and I suspect that as we collectively make this transition to the new tasks, people's machines are requesting on the basis of estimated time for the old tasks and therefore are over-requesting work, hence the dearth of available work for O3.
Edit: If run-times are similar between old and new tasks for CUDA-based applications, then there may need to be some optimisation of the OpenCL applications. I only have v1.07 available.
Edit: If run-times are similar between old and new tasks for CUDA-based applications, then there may need to be some optimisation of the OpenCL applications. I only have v1.07 available.
they're not. it's about the same 2-3x runtime that you observed on 1.07 with OpenCL. though I havent tested both 1.08 and 1.14 apps extensively or checked further optimization yet.
just need to wait for more tasks to be available to do more testing.
We also saw the 2x-3x slowdown for the brief period that I saw a few of these tasks run (cuda).
I didn't catch them on the windows boxes (opencl).
If this app is going to be around for a while, I hope to see a windows version of the cuda application at some point! If not, opencl it is (3x slower than cuda).
...the estimated run-time for the new tasks is a fraction of the old tasks. This causes a huge skew in work requests and I suspect that as we collectively make this transition to the new tasks, people's machines are requesting on the basis of estimated time for the old tasks and therefore are over-requesting work, hence the dearth of available work for O3.
I forgot to mention that compounding the problem is the short deadline for these new tasks. I suppose some tasks may become available for redistribution after they're expired/aborted.
As a point of reference from a windows 11 pc running the stock version of boinc on a 4070 super + amd 7800x3d cpu: the new lower frequency tasks seem to be about the same ~3x increase in run time you guys are experiencing. They're up from ~10-11 to just under 30 minutes run time for single task processing.
If the new tasks still give 10,000 credit per task, the 3x increase makes them significantly "worse" to run from a RAC perspective for me in comparison to the BRP7 tasks, which complete in just under 6 minutes (~555.5 credit/min for BRP7 vs ~344.8 credit/min for 03 currently and ~900-1000 credit/min previously). Does anyone know if there are any plans to adjust the credit given for the new gravity wave tasks? Or maybe we are just being incentivized to run BRP7 haha
I forgot to mention that compounding the problem is the short deadline for these new tasks. I suppose some tasks may become available for redistribution after they're expired/aborted.
There's a good reason for the small task pool and the short deadline: we're acting responsibly. See, whenever we set up a new run we run internal tests before a public release. However, given the vast heterogeneity of the volunteer system out there, we are rolling out new runs in stages. The first set of ~800 workunits is used to see if things work as expected. That is with regards to resource requirements, runtime/credit, stability and correctness. This way we minimize the waste of precious compute cycles at your end, caused by a potentially flawed release. Depending on the results we might issue a larger set or go full throttle. In order to keep the staging phase as short as possible we're setting the deadline to, say, 3 days only (instead of the usual 14). This way we're getting the required feedback quickly and can speed up the rollout for everyone.
In order to keep the staging phase as short as possible we're setting the deadline to, say, 3 days only (instead of the usual 14). This way we're getting the required feedback quickly and can speed up the rollout for everyone.
That makes perfect sense and the deadline wouldn't be an issue if the estimated runtime wasn't completely wrong, it's around 20% of the old tasks while the actual runtime is pretty much exactly 3x of the old tasks (on my system at least), that's a huge discrepancy. So my BOINC client was happily asking for more and more of those 17 minute tasks and than it found out, that in reality they take around 4 and a half hours, so now it's in panic mode and I might need to abort some of the tasks.
Bernd Machenschalk wrote:On
)
My observations thus far across several of my hosts (those that have been able to get any new O3 tasks, that is) with different architectures and power ratings suggests that the run-time for the new low-frequency tasks are 2-3 times of the old high-frequency tasks. That in itself isn't a major problem, but the estimated run-time for the new tasks is a fraction of the old tasks. This causes a huge skew in work requests and I suspect that as we collectively make this transition to the new tasks, people's machines are requesting on the basis of estimated time for the old tasks and therefore are over-requesting work, hence the dearth of available work for O3.
Edit: If run-times are similar between old and new tasks for CUDA-based applications, then there may need to be some optimisation of the OpenCL applications. I only have v1.07 available.
Soli Deo Gloria
Wedge009 wrote:Edit: If
)
they're not. it's about the same 2-3x runtime that you observed on 1.07 with OpenCL. though I havent tested both 1.08 and 1.14 apps extensively or checked further optimization yet.
just need to wait for more tasks to be available to do more testing.
_________________________________________________________________________
We also saw the 2x-3x
)
We also saw the 2x-3x slowdown for the brief period that I saw a few of these tasks run (cuda).
I didn't catch them on the windows boxes (opencl).
If this app is going to be around for a while, I hope to see a windows version of the cuda application at some point! If not, opencl it is (3x slower than cuda).
I havent received any OAS
)
I havent received any OAS work since Monday
and me too. why?
)
and me too.
why?
Wedge009 wrote:...the
)
I forgot to mention that compounding the problem is the short deadline for these new tasks. I suppose some tasks may become available for redistribution after they're expired/aborted.
Soli Deo Gloria
tish wrote: and me
)
Most likely because there is a short supply of work available at the moment. No idea when supply will improve
As a point of reference from
)
As a point of reference from a windows 11 pc running the stock version of boinc on a 4070 super + amd 7800x3d cpu: the new lower frequency tasks seem to be about the same ~3x increase in run time you guys are experiencing. They're up from ~10-11 to just under 30 minutes run time for single task processing.
If the new tasks still give 10,000 credit per task, the 3x increase makes them significantly "worse" to run from a RAC perspective for me in comparison to the BRP7 tasks, which complete in just under 6 minutes (~555.5 credit/min for BRP7 vs ~344.8 credit/min for 03 currently and ~900-1000 credit/min previously). Does anyone know if there are any plans to adjust the credit given for the new gravity wave tasks? Or maybe we are just being incentivized to run BRP7 haha
Wedge009 wrote:I forgot to
)
There's a good reason for the small task pool and the short deadline: we're acting responsibly. See, whenever we set up a new run we run internal tests before a public release. However, given the vast heterogeneity of the volunteer system out there, we are rolling out new runs in stages. The first set of ~800 workunits is used to see if things work as expected. That is with regards to resource requirements, runtime/credit, stability and correctness. This way we minimize the waste of precious compute cycles at your end, caused by a potentially flawed release. Depending on the results we might issue a larger set or go full throttle. In order to keep the staging phase as short as possible we're setting the deadline to, say, 3 days only (instead of the usual 14). This way we're getting the required feedback quickly and can speed up the rollout for everyone.
Hope this helps,
Oliver
Einstein@Home Project
Oliver Behnke wrote:In order
)
That makes perfect sense and the deadline wouldn't be an issue if the estimated runtime wasn't completely wrong, it's around 20% of the old tasks while the actual runtime is pretty much exactly 3x of the old tasks (on my system at least), that's a huge discrepancy. So my BOINC client was happily asking for more and more of those 17 minute tasks and than it found out, that in reality they take around 4 and a half hours, so now it's in panic mode and I might need to abort some of the tasks.
.