Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Temperature Widget Incorrect

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 3 Posters 615 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G Offline
      Griffo
      last edited by

      Has anyone else noticed that in recent versions, that the temperature dashboard widget can show wildly incorrect results?
      I often find that when hitting the dashboard, the value is way too high, wait 30 seconds, hit refresh, and the values then look accurate.

      e.g my passively cooled box showed this:

      676888b8-e6a9-4d83-83be-88903495134d-image.png

      Then on refresh a few seconds later
      ac666f9f-765c-4a11-ae4c-45750566a59d-image.png

      T 1 Reply Last reply Reply Quote 0
      • T Offline
        tquade @Griffo
        last edited by

        @griffo What is the CPU usage during these temperature excursions?

        Ted

        G 1 Reply Last reply Reply Quote 0
        • G Offline
          Griffo @tquade
          last edited by Griffo

          @tquade said in Temperature Widget Incorrect:

          @griffo What is the CPU usage during these temperature excursions?

          Ted

          They don't align - they appear normal

          92abef49-228b-4963-963f-c8d9eb439df1-image.png

          1 Reply Last reply Reply Quote 0
          • stephenw10S Offline
            stephenw10 Netgate Administrator
            last edited by

            No, I've not noticed that. What CPU is that?

            The widget gets those values from the sysctls so I'd suggest you might just be missing the peak values that are caused by loading the dashboard.

            Try loading the CPU artificially and see if the steady state values match.
            When I'm doing that I use:

            [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null &
            [1] 6443
            [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null &
            [2] 6589
            [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null &
            [3] 6594
            [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null &
            [4] 6923
            

            That makes the 4 cores there run at 100%:

            last pid:  7719;  load averages:  2.28,  0.69,  0.29                       up 2+01:00:56  22:36:41
            64 processes:  5 running, 59 sleeping
            CPU: 15.7% user,  0.0% nice, 84.3% system,  0.0% interrupt,  0.0% idle
            Mem: 20M Active, 152M Inact, 437M Wired, 3229M Free
            ARC: 175M Total, 42M MFU, 129M MRU, 172K Anon, 785K Header, 3756K Other
                 57M Compressed, 175M Uncompressed, 3.05:1 Ratio
            Swap: 1024M Total, 1024M Free
            
              PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
             6443 root          1 103    0    10M  2068K CPU1     1   0:49 100.06% yes
             6594 root          1 103    0    10M  2068K CPU3     3   0:47  99.90% yes
             6589 root          1 103    0    10M  2068K RUN      2   0:47  99.86% yes
             6923 root          1 103    0    10M  2068K CPU0     0   0:46  99.83% yes
             7719 root          1  20    0    13M  3572K CPU2     2   0:00   0.21% top
            87020 root          1  20    0    14M  5068K nanslp   1   0:21   0.02% vnstatd
            

            On the 5100 the core temps are help pretty close:

            [22.01-RELEASE][admin@5100.stevew.lan]/root: sysctl -a | grep temperature
            hw.acpi.thermal.tz0.temperature: 0.1C
            dev.cpu.3.temperature: 46.0C
            dev.cpu.2.temperature: 46.0C
            dev.cpu.1.temperature: 46.0C
            dev.cpu.0.temperature: 47.0C
            

            Other CPUs may not be coupled as well to the heatsink, or internally each core.

            You can run killall yes to stop those.

            Steve

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.