Email-Thread with GUDE regarding integration of the measurement

Fri Sep 2 16:06:39 BST 2022

Thank you, Arne!

On 9/1/22 16:56, Arne Tarara wrote:
> Hey Joseph,
> 
> you get multiple readings per second from the script because it just polls multiple times per second.
> 
> This does however not indicate that the resolution is higher than 1 S/s (Sample per second).
> You can see in the raw data that changes of the value occur almost in a 1 second interval.
> 

Great, thank you for the clarification!

> 
> 2. Regarding the info from GUDE
> This info is not really relevant for the Watts reading we use. It is nice to know that the actual energy measurement though
> is quite precise since it integrates. But we are using only the Power reading as the energy is way too coarse.
> 
> 3. So in summary what you are doing is all right.
> The n value of of 4,5 and 3 respectively is correct. Since the two clocks of the GUDE and the PC are not synchronized
> you would not know when exactly their measurement interval starts.
> So it is fine to just sample with a higher rate as we do and then average that again.
> 

Then the n column is irrelevant except as an indication of the raw data 
used to calculate the values.

Relieved it seems I am on the right track :)

BTW Blog post from July has been updated with info from last weekend's 
achievements. Read more here: 
https://eco.kde.org/blog/2022-07-25-sprint-lab-follow-up/#followup

Cheers,
Joseph

> Besten Gruß / Best regards,
> 
> Arne Tarara
> 
> Green Coding Berlin GmbH
> Jablonskistr. 24
> 10405 Berlin
> 
> Mobil.: +49 160 947 930 24
> Web: https://www.green-coding.org <https://www.green-coding.org/>
> Github: https://github.com/green-coding-berlin <https://github.com/green-coding-berlin>
> Linkedin: https://www.linkedin.com/in/arne-tarara/ <https://www.linkedin.com/in/arne-tarara/>
> 
> -
> Green Coding Berlin GmbH, Sitz Berlin
> Amtsgericht Charlottenburg HRB 243137 B
> Geschäftsführer:  Arne Tarara
> 
> 
> 
> 
>> On 1. Sep 2022, at 1:09 PM, Joseph P. De Veaugh-Geiss <joseph at kde.org> wrote:
>>
>> Hi all,
>>
>> I wanted to follow up to this post with some questions about the GUDE output after Saturday's Sprint.
>>
>> I tested the lab setup last weekend with the GUDE Python script (https://invent.kde.org/teams/eco/feep/-/tree/master/tools/GUDEPowerMeter <https://invent.kde.org/teams/eco/feep/-/tree/master/tools/GUDEPowerMeter>) and the Kate Standard Usage Scenario.
>>
>> The output looks like this:
>>
>> 1661611601615724	28
>> 1661611601738979	28
>> 1661611601862415	28
>> 1661611601985623	28
>> 1661611602109482	28
>> 1661611602233380	28
>> 1661611602558003	30
>> 1661611602681602	30
>> 1661611602804709	30
>> 1661611603131084	30
>> 1661611603254468	30
>> 1661611603377331	29
>> 1661611604517858	36
>>
>>
>> When converting the nanoseconds in Epoch time (first column) to timestamps (last two columns), I see that there are several measurements per second. FYI the first timestamp keeps the microseconds, the second timestamp is just in seconds.
>>
>> nanoseconds    watts    timestamp (microseconds)  timestamp (seconds)
>> 1661611601615724  28  2022-08-27 16:46:41.615724  2022-08-27 16:46:41
>> 1661611601738979  28  2022-08-27 16:46:41.738979  2022-08-27 16:46:41
>> 1661611601862415  28  2022-08-27 16:46:41.862415  2022-08-27 16:46:41
>> 1661611601985623  28  2022-08-27 16:46:41.985622  2022-08-27 16:46:41
>> 1661611602109482  28  2022-08-27 16:46:42.109482  2022-08-27 16:46:42
>> 1661611602233380  28  2022-08-27 16:46:42.233380  2022-08-27 16:46:42
>> 1661611602558003  30  2022-08-27 16:46:42.558002  2022-08-27 16:46:42
>> 1661611602681602  30  2022-08-27 16:46:42.681602  2022-08-27 16:46:42
>> 1661611602804709  30  2022-08-27 16:46:42.804708  2022-08-27 16:46:42
>> 1661611603131084  30  2022-08-27 16:46:43.131083  2022-08-27 16:46:43
>>
>> Regarding the following information from GUDE:
>>
>>> According to their support the hardware does integration of the Energy result with results measured at 8 kHz.
>>> Even the power measurements are internally more often sampled (at least 3 times), than the output resolution of 1 s.
>>
>> Sorry for the newbie questions, I am still new to this type of data having worked almost exclusively with binary or ordinal data in behavioral studies.
>>
>> How should I understand the output given the above information from GUDE?
>>
>> Does each result per row include at least 3 samples?
>>
>> Does the above output with multiple results per second suggest we are getting a higher output resolution than 1s?
>>
>> Finally, if I calculate the average per second and use this for the analysis, how do I interpret it? See, for instance, the column "watts (m)" below (I have kept the information about the number of samples used to calculate it in the column n). Does this mean for the first row there are at least 12 samples -- 4 samples per second with at least 3 samples each?
>>
>> timestamp (seconds)  n watts (m)
>> 2022-08-27 16:46:41  4  28.00000
>> 2022-08-27 16:46:42  5  29.20000
>> 2022-08-27 16:46:43  3  29.66667
>>
>> If yes, the number of samples seems very low for a professional power meter. If I recall correctly the Janitza power meter (used to measure Okular) obtained 1000 samples per second and provided in the output the average, min, and max values. And the hacked Gosund power plug is getting about 5 samples per second I believe.
>>
>> BTW If it seems I am doing something wrong in the above calculations, please let me know.
>>
>> Also, attached are some graphs using the above numbers for the Kate SUS run for 3 iterations (only shared here for presentational purposes, not final data). For the GUDE power meter results, gray lines show the above values (i.e., averaged per second), and the red line shows the average for all 3 iterations. The other plot shows the CPU results from collectl measured on the reference system. It seems they correlate nicely, I hope suggesting I am on the right track :) If you are wondering, the spikes are when typing "lorem ipsum ...".
>>
>> I hope my questions are clear and thanks for any help with understanding this!
>>
>> Cheers,
>> Joseph
>>