Incorrect use of `cores` vs `threads`

[Bastian-Eisenmann]

The plugin will currently may report much higher TDP values as it should.

Depending on the CPU architecture a CPU often has several physical cores (e.g. 4) which are later split into multiple threads. (2 per core -> 8)

The used cpu capacity is reported by nextflow on a thread level.
That means, that a cpu utility of 200% reflects the utilization of 2*1 Threads which refers to one CPU core.
Given a sample system with 4 cpus and 8 logical threads nextflow can report an utilization up to 800%.

The energy consumption is currently based on a TDP per core level. That means: A cpu with a TDP of 100 and 4 cores will have a TDP of 25 per core.

A full utilized system with 8 Threads, 4 CPU and a TDP per core of 25 will afterwards be measured with a overall TDP of 200 (800% * 25 = 200)
As a solution the calculation parameter could be changed from "TDP per CPU" to "TDP per Thread" instead.

Some additional side nodes:

• The hypervisor under the used virtualization level will may distribute tasks in it´s own way. E.g. docker on OSX will try to distribute the load on different threads (if the application does support it) rather than utilize one thread/core complete.
• The power consumption of a core does not scale perfect linear based on its utilization level but it is a good approximation.
• The nextflow cpu boundaries chosen in the workflow configuration (e.g. cpu: 2) will may be ignored by the target system. (Tested with OSX running docker)

[skrakau]

Just to extend this view a bit:

• The TDP values are computed for the max. load of the CPU using multi-threading.
• The power draw in the single-threaded case gets close to the power draw in the hyper-threading case (due to the shared components).
• The highest fraction of the power draw is coming from the shared components, which make it a bit more tricky to model it correctly.

Looking at the two simple modelling approaches for calculating the power consumption:

Current status: the calculation uses p_c, the power draw per core value, while the used Nextflow metric cpu_usage refers to the usage of the individual thread

• single-threading: roughly correct ✅ , since the power draw in this case gets close to the hyper threaded scenario
• hyper-threading: overestimated ❌ (up to 2x ?), since it's assuming each thread requires p_c

Alternative approach: use p_c/#threads

• single-threaded: underestimated ❌ (but not close to 0.5 ?), since all of the shared components can be used
• hyper-threaded: roughly correct ✅ (still depends on the workload)

Thus, it's also a question which scenarios happen more frequently. Slurm, for example, by default uses first different physical cores and then makes use of hyperthreading.

For the future, this could be modelled more accurately. Although not all relevant information might be available through Nextflow, or we need to figure out how to retrieve this.

Please correct or extend, if you know more!

@Llannelongue it would be also great if we can discuss this together

[skrakau]

For the beginning it would be good to make sure this is at least clearly documented for the hyperthreading case.

[github-actions]

This issue had no contributions for some time. It will be marked as stale and may be closed upon further inspection.

[JosuaCarl]

It seems that this is not a straightforward case with Nextflow because it often fails in allocating (or reporting, depending on the perspective) the correct number of logical cores (see nextflow-io/nextflow#6743).