Announcement

Collapse
No announcement yet.

Raspberry Pi On Linux 4.19 Will Be Able To Report Under-Voltage Issues

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Raspberry Pi On Linux 4.19 Will Be Able To Report Under-Voltage Issues

    Phoronix: Raspberry Pi On Linux 4.19 Will Be Able To Report Under-Voltage Issues

    The Linux 4.19 kernel will be introducing a new "raspberrypi-hwmon" driver capable of reporting under-voltage conditions for Raspberry Pi boards...

    http://www.phoronix.com/scan.php?pag...mon-Linux-4.19

  • #2
    Originally posted by tichun
    Raspberry Pi does it for years already.
    This is only upstreaming.
    Yes but the clueless users using RPi on 96 node clusters don't know if they have undervoltage / throttling issues. Even the SoC MHz number is fake, iirc.

    Comment


    • #3
      I don't get it.
      On archlinuxarm, i get undervolt messages this in the kernel logs everytime i connect usb to the ups, running 4.14.33.
      Does it means they compiled in a module that was not upstream yet?
      pi ~ # lsmod|grep -i hw
      ...returns nothing.

      Comment


      • #4
        kokoko3k : yup, its the upstreaming that is supposed to be new.


        caligula : it boils down to the fact that it's the VC that is in charge of handling low level stuff. The OS (here: linux) can politely ask for a clockspeed over the mailbox, but the Linux governor has no actual idea what clockspeed the CPU runs. You only get the real value if you ask the VC over the mailbox. There's some tools for that (e.g.: raspimoni). But the upstream kernel doesn't have any code written yet to handle this class of situation 'i.e.: when the speed that the governor wants is overridden by a different OS running on an entirely different CPU core).

        This is all due to the weird architecture of Raspi's Broadcom soc. it's not as much a single board computer as a it is a cluster of 2 different computer on the same soc, each running an entirely different OS, only one of them is Linux. (devs used to modern smartphones should feel at home).

        if that's not your liking, hey it's okay, you can still pick-up one of the more modern boards with saner architectures, no grudge held.


        (but these boards might be more expensive and/or require blobs in your linux kernel and/or might not be as widely supported and/or might show weird incompatibility or even not be supported by modules that mainly target raspis - there is still no such thing as a perfect embed platform yet.

        With all their deffects and weirdness, raspis are simply a different compromise on these scales, and maybe not the best suited to your needs).

        Comment


        • #5
          Originally posted by DrYak View Post
          if that's not your liking, hey it's okay, you can still pick-up one of the more modern boards with saner architectures, no grudge held.
          I very much like RPi. I don't know if any of the other boards are as versatile. For example the throttling might be better way to deal with low voltages (caused by long low quality cables) than hard lockups on some other boards. I'm just criticizing the cluster approach because many assume it has awesome performance and scalability when it doesn't.

          I've seen some RPi clusters and they often have serious flaws. For example
          - you'll need custom hardware or a way bypass the polyfuses to really power up the boards without undervoltage issues.
          - overall, the power consumption is pretty large due to all the extra stuff on board but the supply of zero boards has been / is limited
          - they only started using onboard copper as a better heatsink in RPi 3B+.
          - many hackaday style articles on RPi clusters don't have sufficient cooling solutions.
          -> People don't realize that their "high performance" cluster in a sealed plastic box might do throttling, decreasing the performance significantly, as this occurs "silently"
          -> Those people probably run Raspbian ARM11 binaries on the new 64-bit RPi 3B+ with lower performance.
          -> and with HDMI and other non-cluster functionality enabled, leading to increased energy consumption.
          - the power on/off switch isn't practical for remote administration (like IPMI)
          - you'll need SD cards since there's no builtin netboot. If you're mainly just booting images from the LAN, this is wasteful
          - the first RPis used to corrupt SD cards quite often. This leads to extra maintenance work when booting off of SD cards
          - the ethernet is very bandwidth limited. On the 3B+, the GB ethernet is actually only 300 Mbps (half duplex). Old Rpi clusters users needed separate USB3 gigabit adapters to reach this.
          - if I needed a budget cluster, I'd probably daisy chain the boards to avoid the need for a huge switch. But due to limited ethernet bandwidth this is impractical, which makes the budget cluster quite expensive.
          Last edited by caligula; 07-22-2018, 07:54 PM.

          Comment

          Working...
          X