Welcome to our peer-to-peer forums, where owners help owners. Need help now? Visit eSupport here.

English Community

Linux Operating SystemsOther Linux Discussions
All Forum Topics
Options

48 Posts

10-11-2020

United States of America

47 Signins

445 Page Views

  • Posts: 48
  • Registered: ‎10-11-2020
  • Location: United States of America
  • Views: 445
  • Message 11 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-08, 19:49 PM

@ MarkRHPearson wrote:

 

I'm genuinely not trying to obfuscate anything here.

 

 

I've asked you 3 times in this new thread to "Post the current, expected S3 drain in mwh, that you claim makes this resolved"

 

If you refuse to do that, you are indeed obfuscating. 

Reply
Options

407 Posts

03-06-2021

Germany

227 Signins

2420 Page Views

  • Posts: 407
  • Registered: ‎03-06-2021
  • Location: Germany
  • Views: 2420
  • Message 12 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 13:00 PM

Ehh.. let's start with you are missing P14s in that Topic name.

 

Please fix.

Reply
Options

407 Posts

03-06-2021

Germany

227 Signins

2420 Page Views

  • Posts: 407
  • Registered: ‎03-06-2021
  • Location: Germany
  • Views: 2420
  • Message 13 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 13:36 PM

@ E.Q, wrote:

@ MarkRHPearson wrote:

Energy Star 8.0

https://www.energystar.gov/products/spec/computers_version_8_0_pd

 

I have looked at the document. The relevance of that document and the associated certification is the P_sleep variable's value used (and therefore measured on a model representative of those sold) by Lenovo for the certification of the T14 AMD G1, where sleep=S3, of course. Can you share this value for S3 P_sleep [mW] in this thread, please? It may also be necessary to include the duration(s) T of the sleep periods used for the measurement, as I noticed that the time-average power draw during S3 sleep depends on that duration (it decreases with longer durations).

 

Sharing that information would be most helpful to assess where things stand. If it is higher than what most people here are already now getting, we should conclude that the Energy Start compliance is not relevant (as some have already suggested). If it is clearly lower than what most people are getting, then Lenovo should work with us to at least attain a discharge rate as low as claimed for the certification. (Afterwards, we could work towards a value even lower, but that would be a next step.)

 

BTW: I have seen people use units in these threads that are incorrect (likely due to the fact that one measurement script had wrong units for a while). The (average) discharge rate for a period of sleep is measured in mW (milliWatt) and the total energy consumption in mWh (milliWatt-hour, i.e., one just multiplies the rate by the time in hours). (Shameless plug: my script does this correctly AFAICT.) One can also use W and Wh, but then usually we'd need to bother with fractional values.

 

He can't post anything. Please see notes on the IEC used to calculate and try to get it.

IEC 62623:2012 is not freely available. We don't need only the numbers but 'how' they do that.

 

I'm not even sure why Mark is starting this again since is irrelevant to that issue.

 

Why? well, e-cert in general, is 'average' of things with the scope to stay below a predefined target.

 

I didn't read 8.0, but I don't believe anything changed since IEC 62623:2012 is still used, so we should have the run like this:

 

Short idle state

Long idle state

Off mode

Sleep mode

 

each with a predefined percentage:

 

10%

30%

25%

35%

 

( note on laptops with <4G, >8G the formula needs some adjustment but is irrelevant to all these issues)

 

We apply now the formula and if the result is below 'predefined target' it passes. And it will even pass with

Sleep mode = (around) 2W, if the other modes compensate for that. 

 

IOW, this e-cert argument is used to shut us up.

 

I won't participate anymore in the discussion, not worth wasting my time.

It is obvious Lenovo won't fix it.

 

( PS: people can still PM me, I will do my best to help if time permits )

 

Gabriel

Reply
Options

57 Posts

01-27-2021

Netherlands

44 Signins

375 Page Views

  • Posts: 57
  • Registered: ‎01-27-2021
  • Location: Netherlands
  • Views: 375
  • Message 14 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 15:08 PM

@ osnix wrote:

@ E.Q, wrote:

@ MarkRHPearson wrote:

Energy Star 8.0

https://www.energystar.gov/products/spec/computers_version_8_0_pd

 

I have looked at the document. The relevance of that document and the associated certification is the P_sleep variable's value used (and therefore measured on a model representative of those sold) by Lenovo for the certification of the T14 AMD G1, where sleep=S3, of course. Can you share this value for S3 P_sleep [mW] in this thread, please? It may also be necessary to include the duration(s) T of the sleep periods used for the measurement, as I noticed that the time-average power draw during S3 sleep depends on that duration (it decreases with longer durations).

 

[…]

 

He can't post anything. Please see notes on the IEC used to calculate and try to get it.

IEC 62623:2012 is not freely available. We don't need only the numbers but 'how' they do that.

 

[…]

 

Why? well, e-cert in general, is 'average' of things with the scope to stay below a predefined target.

 

I didn't read 8.0, but I don't believe anything changed since IEC 62623:2012 is still used, so we should have the run like this:

 

I read enough of the document to get the information necessary to ask an intentionally specific question about a quantity that is relevant for this issue and @ MarkRHPearson should be able to provide. The details for the measurement approach to obtain S3 P_sleep are, for a first step, not important.

Reply
Options

27 Posts

11-17-2013

Toronto

30 Signins

115 Page Views

  • Posts: 27
  • Registered: ‎11-17-2013
  • Location: Toronto
  • Views: 115
  • Message 15 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 16:49 PM

@ E.Q, wrote:

 

BTW: I have seen people use units in these threads that are incorrect (likely due to the fact that one measurement script had wrong units for a while). The (average) discharge rate for a period of sleep is measured in mW (milliWatt) and the total energy consumption in mWh (milliWatt-hour, i.e., one just multiplies the rate by the time in hours). (Shameless plug: my script does this correctly AFAICT.) One can also use W and Wh, but then usually we'd need to bother with fractional values.

 

 

Hey EQ - actually your script is measuring the DELTA in mWh over a period of time. The standard way to summarize your script's findings is mWh per hour (mWh/h).  Yes the h cancels out, but using just mW implies an instantaneous rate of energy consumption rather than average.

 

Best way to think about this as a physicist: use Joules unit. 1Wh = 1000mW = 1J = 1000mJ. Here's an example: if your battery is at 50,000 mWh  (50J) and stop when your battery is at 45000 mWh  (45J) whilst spending 10hrs in standby, then you have an average consumption of 500mJ per hour. Or the industry way of saying it is 500mWh/h. 

 

 

See this thread https://electronics.stackexchange.com/questions/5120/does-it-make-sense-to-use-mwh-h-as-unit-of-measure   

 

 

Reply
Options

83 Posts

04-17-2021

Greece

59 Signins

380 Page Views

  • Posts: 83
  • Registered: ‎04-17-2021
  • Location: Greece
  • Views: 380
  • Message 16 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 17:37 PM

The only real solution is a wide spread recall.

Reply
Options

57 Posts

01-27-2021

Netherlands

44 Signins

375 Page Views

  • Posts: 57
  • Registered: ‎01-27-2021
  • Location: Netherlands
  • Views: 375
  • Message 17 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 19:29 PM

@ joni1101 wrote:

Hey EQ - actually your script is measuring the DELTA in mWh over a period of time. The standard way to summarize your script's findings is mWh per hour (mWh/h).  Yes the h cancels out, but using just mW implies an instantaneous rate of energy consumption rather than average.

 

There is no way around the fact that mWh/h=mW. I see the point you are trying to make, namely, conveying more information about the quantity than can normally be encoded in a unit. However, in this case, there is not more information to encode, as the 1 h in the denominator is arbitrary. It would be different in case 1 h would for example be a billing period or something like that, then it could make sense. So, I'd like to respectfully disagree. I would be interested in a standard (ISO or so) for electronics power consumption that prescribes using something like mWh/h instead of mW.

 

@ joni1101 wrote:

[…] Or the industry way of saying it is 500mWh/h.

 

Which industry? I've not come across it for electronics and also not in power production. (I've worked a couple of years in power production research. I'm a physics engineer, so I also have some affinity with units, and am specialized in uncertainty, so I know a bit about dealing with averages. But I like to be proven wrong or overconfident!)

 

@ joni1101 wrote:

See this thread https://electronics.stackexchange.com/questions/5120/does-it-make-sense-to-use-mwh-h-as-unit-of-measure   

I disagree with the accepted answer. I find FinGrid's usage on that page to be silly, really, for the same reason I gave above: the 1 h in the denominator is arbitrary.

My apologies for going off-topic.

Reply
Options

27 Posts

11-17-2013

Toronto

30 Signins

115 Page Views

  • Posts: 27
  • Registered: ‎11-17-2013
  • Location: Toronto
  • Views: 115
  • Message 18 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-09, 21:45 PM

@E.Q,    yep, 1h is arbitrary unlike seconds which is a fundamental unit....  as for industry standard, Wh/h is a thing, and billing by kWh and MWh also... ... but all this is nitpik, ultimately I'm satisfied customer using your script (unmodified) to make all my reports! Thank you for your contribution to the community! 

Reply
Options

17 Posts

09-08-2021

United States of America

14 Signins

135 Page Views

  • Posts: 17
  • Registered: ‎09-08-2021
  • Location: United States of America
  • Views: 135
  • Message 19 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-10, 19:15 PM

Same issue with my latest Gen 2 t14, ran the script to see whatsup:

 

System:

T14 Gen 2 5850U (20XK001AUS)

Kernel:

5.14.2

 

BIOS:

1.09

 

Sep 10 19:57:13 thinkpad systemd-sleep[6438]: Entering sleep state 'suspend'...
Sep 11 00:09:22 thinkpad systemd-sleep[6438]: System returned from sleep state.
Sep 11 00:09:22 thinkpad systemd-sleep[6465]: Currently on battery.
Sep 11 00:09:22 thinkpad systemd-sleep[6465]: Duration of 0 days 4 hours 12 minutes sleeping (suspend).
Sep 11 00:09:22 thinkpad systemd-sleep[6465]: Battery energy change of -5.6 % (-2910 mWh) at an average rate of -1.33 %/h (-692 mW).
Sep 11 00:09:22 thinkpad systemd[1]: systemd-suspend.service: Deactivated successfully.
Sep 11 00:09:22 thinkpad systemd[1]: Finished System Suspend.

 

 

I really hope this can be fixed because at this rate I lose about 20-30% battery in a single night.

 

Reply
Options

3 Posts

09-10-2021

China

2 Signins

15 Page Views

  • Posts: 3
  • Registered: ‎09-10-2021
  • Location: China
  • Views: 15
  • Message 20 of 48

Re:T14, T14s & X13 G1 AMD Linux - S3 standby battery drain improvements

2021-09-11, 6:56 AM

This is my laptops information, I hope it can help others,

 

Thinkpad X13 Gen1 AMD 4750U version, Arch linux

 

Kernel:

Linux x13 5.14.2-arch1-2 #1 SMP PREEMPT Thu, 09 Sep 2021 09:42:35 +0000 x86_64 GNU/Linux

 

BIOS:

# sudo dmidecode -t bios                 
    Vendor: LENOVO
    Version: R1CET66W(1.35 )
    Release Date: 07/30/2021
    Address: 0xE0000
    Runtime Size: 128 kB
    ROM Size: 32 MB

 

Battery consume:

$ sudo journalctl -u systemd-suspend.service | tail
-- Boot 1a74d1217e0f44a99819cc1034129af8 --
9月 10 22:03:52 x13 systemd[1]: Starting System Suspend...
9月 10 22:03:52 x13 systemd-sleep[4102]: Saving time and charge.
9月 10 22:03:53 x13 systemd-sleep[4100]: Entering sleep state 'suspend'...
9月 11 14:41:11 x13 systemd-sleep[4100]: System returned from sleep state.
9月 11 14:41:11 x13 systemd-sleep[4404]: Suspend duration: 16h 37m.
9月 11 14:41:11 x13 systemd-sleep[4385]: Discharge rate: .62026 W/h.
9月 11 14:41:12 x13 systemd[1]: systemd-suspend.service: Deactivated successfully.
9月 11 14:41:12 x13 systemd[1]: Finished System Suspend.
9月 11 14:41:12 x13 systemd[1]: systemd-suspend.service: Consumed 1.480s CPU time.

Reply
Forum Home

Community Guidelines

Please review our Guidelines before posting.

Learn More

Check out current deals!

Go Shop
X

Save

X

Delete

X

No, I don’t want to share ideas Yes, I agree to these terms