Announcement

Collapse
No announcement yet.

Linux In 2020 Can Finally Provide Sane Monitoring Of SATA Drive Temperatures

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

  • Melcar
    replied
    Does HWiNFO really report "everything on earth"? Last I checked some motherboards still need special drivers for sensors to properly work on Windows. The Windows user base interested in such things is far larger too, so "just get the work done" is a bit easier.
    There was the whole drama with the it87 driver some time ago, and it was mostly due to lack of interest/users/testers.

    Leave a comment:


  • birdie
    replied
    Instant blacklist, motherfcker. I've done a hundred times more for open source than most of pathetic open source fanatics here. And you're just despicable.

    And that's the reason, gentlemen, Linux has sucked, sucks and will always suck. For other OSes people usually just get work done ,e.g. HWiNFO reports everything on earth, no questions asked.

    In Linux we have barely functioning something, barely having 20% of the features which are available in Windows because ... reasons!
    Last edited by birdie; 12 January 2020, 08:15 PM.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by Ropid View Post


    I read through the posts in that bug report discussion thread you linked to, and it's explained there. I understand what happened like this:

    First, the code was actually implemented, just like a [single/whining/sniviling/crying/pleading] user asked for. After the code was there, no one wanted to test it besides one single person. Because people didn't want to test and ignored it, the code then never had a chance to get ready for inclusion into the kernel. Over time other parts of the kernel changed and the experimental code was not good anymore. The developer then gave up trying to get it ready.
    TFTFY

    Leave a comment:


  • birdie
    replied
    Originally posted by Ropid View Post


    I read through the posts in that bug report discussion thread you linked to, and it's explained there. I understand what happened like this:

    First, the code was actually implemented, just like people asked for. After the code was there, no one wanted to test it besides one single person. Because people didn't want to test and ignored it, the code then never had a chance to get ready for inclusion into the kernel. Over time other parts of the kernel changed and the experimental code was not good anymore. The developer then gave up trying to get it ready.
    You can find hundreds of people to test sensors for a CPU family. For motherboards, it's usually quite a difficult task since there are literally thousands of different models and Linux is barely used by anyone. Meanwhile lm-sensors devs gladly develop drivers for motherboards yet they couldn't find testers for a CPU driver? Are you BS'ing me? I tested the driver right away and reported it was fine. Guenter Roeck also tested it - we already had two testers.

    No, the reason was different: "Won't fix; the functionality overlaps with other functionality introduced into the kernel in the meantime, and I was unable to get review or test feedback other than my own on the outstanding patch".

    No actual testing was required. He couldn't find the people to review the code. That was it. And then there was a lame excuse in terms of "overlapping". And now we have no lm-sensors drivers for advanced CPU reporting at all. FML.
    Last edited by birdie; 12 January 2020, 08:07 PM.

    Leave a comment:


  • Ropid
    replied
    Originally posted by birdie View Post
    For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

    It's the same for modern AMD CPUs which need a 3d-party driver.

    I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.

    I read through the posts in that bug report discussion thread you linked to, and it's explained there. I understand what happened like this:

    First, the code was actually implemented, just like people asked for. After the code was there, no one wanted to test it besides one single person. Because people didn't want to test and ignored it, the code then never had a chance to get ready for inclusion into the kernel. Over time other parts of the kernel changed and the experimental code was not good anymore. The developer then gave up trying to get it ready.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by numacross View Post
    I hope this is well tested because there are some caveats even with using hddtemp on a HDD that's currently asleep or in low power mode. Depending on the drive type and manufacturer it can work fine, silently fail or in the worst case spin the drive up unnecessarily.
    Your reply, is in the same way of thinking as mine would be..
    Reading temps without waking up disks( as far as I know), is only possible via SCSI..
    I was delaying implementing it in a tool, and now maybe I would need to continue that work because... I don't want the Load/Unload cycles to start killing the discs, and not only that... the power consumption of each disk goes to the roof each time it is waken up..

    Leave a comment:


  • Azrael5
    replied
    Just 30 years. A big improvement since then.

    Leave a comment:


  • birdie
    replied
    Originally posted by stormcrow View Post

    My educated guess would be at least some of the maintainers don't want to add to the burden of support. Any particular device can have different reporting interfaces, different gotchas, and different forms of brokenness, between different generations of hardware, firmware, model type, vendors, etc. The same is true of just about any hardware really. Ideally they'd have to test changes on all of those hardware types to be sure they work.
    This couldn't be further from the truth. lm-sensors support various motherboards monitoring chips which are finicky as hell, vary from vendor to vendor (some of their inputs maybe connected/disconnected), have varying ratios for their outputs and other infinite quirks.

    At the same time CPUs are fairly standard and once you support a CPU family, you're guaranteed it will work forever for all users. The amount of work to support HW monitoring chips vs CPUs is two orders of magnitude more.

    Leave a comment:


  • stormcrow
    replied
    Originally posted by birdie View Post
    For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

    It's the same for modern AMD CPUs which need a 3d-party driver.

    I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.
    My educated guess would be at least some of the maintainers don't want to add to the burden of support. Any particular device can have different reporting interfaces, different gotchas, and different forms of brokenness, between different generations of hardware, firmware, model type, vendors, etc. The same is true of just about any hardware really. Ideally they'd have to test changes on all of those hardware types to be sure they work.

    Leave a comment:


  • birdie
    replied
    For some reasons lm-sensors maintainers have refused to add the reporting of various additional metrics of Intel CPUs, like voltage and power consumption

    It's the same for modern AMD CPUs which need a 3d-party driver.

    I really cannot find any rationale for this decision. As a Ryzen 3000 user I resorted to using the turbostats utility to report power consumption figures but it's so incredibly tedious when I could just type lm-sensors or use a dozen of monitoring apps which support lm-sensors.

    Leave a comment:

Working...
X