You got it backwards. The cpu usage reported tells how much cpu support was needed to crunch the gpu task.
It does not indicate the speed of the task at all. Only the gpu utilization indicates the speed, or rather the efficiency the task was crunched.
Since CUDA applications require much less cpu support, you are able to crunch more gpu tasks with your cpu. But if the task utilization is already at 100%, adding another current task in the cpu won't increase the task speed or the host production normally. Only if the 2X time combined/2 is less than the single task time when the gpu is at less than 100% utilization should you try or increase concurrency. Experimentation on multiple tasks is needed to evaluate that proposition.
As long as you have enough spare cpu threads to push data to and fro to each task does the cpu usage matter.
My account is now associated with 5,793 E@H FGRPB1G tasks in progress.
On the other hand, my account is associated with almost 3% of the total FGRPB1G tasks in progress (214,360), so I am not complaining.
My account is now associated with 9,288 E@H FGRPB1G tasks in progress, which is quite an improvement from the weekend. Moreover, the total FGRPB1G tasks in progress (223,931) is approximately 4% greater than last reported, which is a minor improvement.
"I was born in a small town, and I live in a small town." - John Mellencamp
it's data from the server status page, just plotted over time instead of the instantaneous view from the server status page.
another user kiska runs this dashboard. he downloads the project provided xml file, and parses out the data to store it and make plots like this.
it's much more useful to get an idea of what's really happening with the project than just seeing single data points and using your memory about what's happened before.
The surge in tasks ready to send didn't last for long. It seemed to be the last primary tasks for the data file LATEAH3012L12221101.dat - ie. those with the frequency component of 900Hz.
Around 2330 UTC (21st Nov) there seemed to be no further tasks except resends. Just before 0430 UTC (22nd Nov) lots of new tasks became available. It wasn't a continuation of the previous series. The new data file is LATeah3012L09.dat. This is a file that was used previously - on 23rd May, according to the date on my cached copy. I cache all data files and deploy to all hosts so none of mine needed to download a new copy.
The good news is that tasks are flowing freely (it would seem) so the great slowdown seems to be over - at least temporarily :-).
You got it backwards. The
)
You got it backwards. The cpu usage reported tells how much cpu support was needed to crunch the gpu task.
It does not indicate the speed of the task at all. Only the gpu utilization indicates the speed, or rather the efficiency the task was crunched.
Since CUDA applications require much less cpu support, you are able to crunch more gpu tasks with your cpu. But if the task utilization is already at 100%, adding another current task in the cpu won't increase the task speed or the host production normally. Only if the 2X time combined/2 is less than the single task time when the gpu is at less than 100% utilization should you try or increase concurrency. Experimentation on multiple tasks is needed to evaluate that proposition.
As long as you have enough spare cpu threads to push data to and fro to each task does the cpu usage matter.
Tigers_Dave wrote: [heavily
)
My account is now associated with 9,288 E@H FGRPB1G tasks in progress, which is quite an improvement from the weekend. Moreover, the total FGRPB1G tasks in progress (223,931) is approximately 4% greater than last reported, which is a minor improvement.
"I was born in a small town, and I live in a small town." - John Mellencamp
as evidenced by the trends in
)
as evidenced by the trends in tasks ready to send:
now whether this is due to project improvements or megakrunchie dumping their load from the FB finale remains to be seen.
_________________________________________________________________________
Ian, I'd go with the
)
Ian,
I'd go with the latter since I'm more seeing FGRPB1G tasks with the number 2 at the end of the task name.
Is the image your showing for the entire Einstein project? It's not your tasks results, is it?
Proud member of the Old Farts Association
it's data from the server
)
it's data from the server status page, just plotted over time instead of the instantaneous view from the server status page.
another user kiska runs this dashboard. he downloads the project provided xml file, and parses out the data to store it and make plots like this.
it's much more useful to get an idea of what's really happening with the project than just seeing single data points and using your memory about what's happened before.
_________________________________________________________________________
GWGeorge007 wrote: Ian, I'd
)
I answered my own question. This shows the available tasks as of a few minutes ago.
Proud member of the Old Farts Association
the whole dashboard is pretty
)
the whole dashboard is pretty configurable. you can change the time windows or isolate individual plots etc
_________________________________________________________________________
It is certainly going now!
)
It is certainly going now!
Proud member of the Old Farts Association
The surge in tasks ready to
)
The surge in tasks ready to send didn't last for long. It seemed to be the last primary tasks for the data file LATEAH3012L12221101.dat - ie. those with the frequency component of 900Hz.
Around 2330 UTC (21st Nov) there seemed to be no further tasks except resends. Just before 0430 UTC (22nd Nov) lots of new tasks became available. It wasn't a continuation of the previous series. The new data file is LATeah3012L09.dat. This is a file that was used previously - on 23rd May, according to the date on my cached copy. I cache all data files and deploy to all hosts so none of mine needed to download a new copy.
The good news is that tasks are flowing freely (it would seem) so the great slowdown seems to be over - at least temporarily :-).
Cheers,
Gary.
Then if I want to go back to
)
Then if I want to go back to crunching only GRPB GPU work I should uncheck MeerKAT in my Project prefs?