Add max_energy_range_uj to deal with RAPL wraparound

[mp15]

When we detect a negative delta from RAPL energy usage then assume we have wrapped around and add max_energy_range_uj to it. According to Intel docs this should happen about every 60 secs under a heavy load. Fixes #322

[mp15]

We probably should write a test to verify the delta functionality with mock rollover readings but this should be better than returning 0.

[benoit-cty]

Thank you very much for this investigation !

If we understand well:

• RAPL write energy to a counter energy_uj.
• At some point the counter energy_uj goes above the constant max_energy_range_uj and fall back to zero.
• RAPL continue to write energy to energy_uj.

So if it goes to zero while codecarbon is running, we have the negative value problem.

With your patch codecarbon will add max_energy_range_uj to last_energy in case of negative energy to avoid the problem.

May I suggest to refactor your code like this ?

if self.last_energy > energy:
    logger.debug(
      f"In RAPLFile : Current energy value ({energy}) is lower than previous value ({self.last_energy}). Assuming wrap-around! Source file : {self.path}"
    )
    energy = energy + self.max_energy_reading
self.power = self.power.from_energies_and_delay(
energy, self.last_energy, duration
)
self.energy_delta = energy - self.last_energy
self.last_energy = energy
return

[mp15]

I've followed your refactor but I have added a new_last_energy variable to it so that it works correctly the next time we call delta(duration). I assume we are accumulating the delta values across calls?
I've also modified the test to compare the results and use almostEqual (as Energy is held as a float internally and non-zero floats are fun to compare).

[SaboniAmine]

Great work, thanks!
This corrects the previous patch we made on this and we have learnt something.
Thanks for your contribution!

[benoit-cty]

Thanks, you're right for new_last_energy 👍