Github messages for voidlinux
 help / color / mirror / Atom feed
From: Depau <Depau@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: pinebookpro-kernel: overclock patch
Date: Mon, 18 Jan 2021 19:45:04 +0100	[thread overview]
Message-ID: <20210118184504.MoPuO36a-lNjNBWNLn387YEM95bg-7Rar7P5tY9Tc8s@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-28007@inbox.vuxu.org>

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

New comment by Depau on void-packages repository

https://github.com/void-linux/void-packages/pull/28007#issuecomment-762416773

Comment:
> I'm running benchmarks over benchmarks right now, and, if I can say something, the pinebook seems more responsive and stable than before.

**Your** Pinebook.

Again, the device clearly has many other issues and crashes, and until every issue has been bisected and identified you can't be 100% sure that the problems aren't caused by overclocking.

RK3399 chips are real life objects, and as such no chip is made equal and not all chips will run stably at the same high frequencies. Since users will most likely NOT be aware that their device is being overclocked/undervolted/overvolted/anything unless they read the DTS, they will most likely blame it on faulty hardware rather than faulty settings.

Devices crash with tsys' kernel too. If yours doesn't, then you won the silicon lottery, good for you.

I suggest to stick with what rockchip does *for mainstream RK3399* - not for Chromebooks - and with whatever Rockchip has tested and guarantees when they sell the chips to their customers.

But most importantly - and I can't stress this enough - I do not think it is a good idea to imply that since it runs smoothly on **your particular device** it will run smoothly on everyone else's device. Run it on 100 devices, stress test them continuously with a synthetic workload for 24h and see if any of them crashes. I seriously doubt they will all pass the test.

Yes, it is fair to stress test them with a synthetic workload because you want devices to **never** crash, not to not crash when you're "just compiling Linux".

If it runs fine on your machine you can always add an overlay, it's free open-source software.


  parent reply	other threads:[~2021-01-18 18:45 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 11:55 [PR PATCH] " thypon
2021-01-18 11:57 ` [PR PATCH] [Updated] " thypon
2021-01-18 12:16 ` Depau
2021-01-18 12:38 ` Johnnynator
2021-01-18 13:06 ` thypon
2021-01-18 17:40 ` thypon
2021-01-18 17:41 ` thypon
2021-01-18 18:02 ` CameronNemo
2021-01-18 18:10 ` thypon
2021-01-18 18:10 ` thypon
2021-01-18 18:11 ` thypon
2021-01-18 18:12 ` thypon
2021-01-18 18:20 ` CameronNemo
2021-01-18 18:45 ` Depau [this message]
2021-01-18 19:39 ` thypon
2021-01-18 19:41 ` thypon
2021-01-18 19:44 ` thypon
2021-01-18 22:12 ` thypon
2021-01-19 23:07 ` thypon
2021-01-21 14:34 ` thypon
2021-01-21 14:35 ` thypon
2021-01-21 14:37 ` thypon
2021-01-21 14:38 ` thypon
2021-01-21 14:39 ` thypon
2021-01-21 14:39 ` thypon
2021-01-21 14:40 ` thypon
2021-01-21 14:41 ` thypon
2021-01-21 14:42 ` thypon
2021-01-21 14:46 ` thypon
2021-01-21 14:46 ` thypon
2021-01-21 14:50 ` thypon
2021-01-21 14:51 ` thypon
2021-01-21 14:52 ` thypon
2021-01-21 14:53 ` thypon
2021-01-21 14:56 ` thypon
2022-05-02  2:16 ` github-actions
2022-05-17  2:13 ` [PR PATCH] [Closed]: " github-actions

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210118184504.MoPuO36a-lNjNBWNLn387YEM95bg-7Rar7P5tY9Tc8s@z \
    --to=depau@users.noreply.github.com \
    --cc=ml@inbox.vuxu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).