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

    VIA C7 Pegged at 200 MHz?

    Hardware
    2
    11
    4.0k
    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.
    • B
      Brawndo
      last edited by

      I'm using a Jetway ITX board with the VIA C7 Processor, and am finding that I am easily keeping it at 100%, often causing the admin interface to become completely unresponsive. When I can get it to update, I see this on the front page:

      CPU Type VIA C7 Processor 1500MHz
      Current: 200 MHz, Max: 1500 MHz

      Occasionally it instead says 100MHz but never goes over 200MHz. Is this an accurate reading of what the CPU is running at? If so it would definitely explain why it gets pushed to 100% so easily. It begins to hit 100% right around 10K-15K states, and I would like to be able to push it a lot higher than that.

      I am running: 2.0-RC3 (i386) built on Mon Jul 4 16:48:37 EDT 2011

      I have not installed any packages, I am not using VPN or any other features needing encryption, its basically set up as a simple gateway.
      I've checked the BIOS options for anything looking like it might cause this but didn't see anything - the multiplier is set to 15X and the bus is at 100MHz. CPU throttling is enabled but the CPU only reports about 55C max when loaded. If the C7 throttles at a low temp then this might explain it.

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

        Do you have powerd enabled?

        Steve

        1 Reply Last reply Reply Quote 0
        • B
          Brawndo
          last edited by

          Hi Steve, thanks for your reply. I have not explicitly done anything to enable powerd, in fact I didn't even know it existed until you mentioned it. So, if it is enabled by default with 2.0 RC2 then I do, otherwise I do not.

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

            It is normally disabled by default but the fact that pfSense is reporting your CPU as 200MHz out of 1500 implies it knows about it's power saving features. Usually you only see that after enebling powerd.

            Steve

            1 Reply Last reply Reply Quote 0
            • B
              Brawndo
              last edited by

              Thanks again for shedding some light Steve. I've been watching since my original post and have started to see some higher values come up, with a maximum so far of 1125MHz just a minute ago (previously max was about 700MHz). My guess at this point is that this figure simply doesn't update at the same time as the CPU % does, and maybe the C7 just isn't as adequate as I'd thought it would be.

              One interesting thing to note: There doesn't seem to be the typical correlation between how hard the CPU is working, and the reported MHz. I'm used to watching Sandy Bridge CPUs turbo and this one doesn't seem to follow the expected patterns. 1125MHz came up during a period of low CPU usage, and when I push full load it shows typically 500-700MHz.

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

                Hmm, well perhaps some mechanism is in place to drive the cpu frequency.
                You may be able to overide it for better control by using powerd or by setting the frequency directly.
                Are there any sysctrls present?

                 sysctl -a | grep freq
                

                Steve

                1 Reply Last reply Reply Quote 0
                • B
                  Brawndo
                  last edited by

                  Here is the output of that command:

                  [2.0-RC3][root@guardian.vortex]/root(2): sysctl -a | grep freq
                  kern.acct_chkfreq: 15
                  kern.ntp_pll.time_freq: 0 0
                  kern.ntp_pll.pps_freq: 0 0
                  kern.timecounter.tc.i8254.frequency: 1193182
                  kern.timecounter.tc.ACPI-fast.frequency: 3579545
                  kern.timecounter.tc.TSC.frequency: 1125000000
                  net.inet.sctp.sack_freq: 2
                  debug.cpufreq.verbose: 0
                  debug.cpufreq.lowest: 0
                  machdep.acpi_timer_freq: 3579545
                  machdep.tsc_freq: 1125000000
                  machdep.i8254_freq: 1193182
                  dev.cpu.0.freq: 1125
                  dev.cpu.0.freq_levels: 1500/15000 1312/13125 1125/11250 937/9375 800/8000 700/7000 600/6000 500/5000 400/4000 300/3000 200/2000 100/1000
                  dev.est.0.freq_settings: 1500/15000 800/8000
                  dev.cpufreq.0.%driver: cpufreq
                  dev.cpufreq.0.%parent: cpu0
                  dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
                  
                  
                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Interesting!  :)
                    You could try setting the frequency directly with:

                    sysctl dev.cpu.0.freq=1500
                    

                    But since something else is managing the frequency that may be overidden.
                    You could also try setting the minimum frequency:

                    sysctl debug.cpufreq.lowest=1500
                    

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • B
                      Brawndo
                      last edited by

                      Thanks again Steve, you are truly deserving of your title.

                      So first I tried this:

                      [2.0-RC3][root@guardian.vortex]/root(1): sysctl dev.cpu.0.freq=1500
                      dev.cpu.0.freq: 1312
                      sysctl: dev.cpu.0.freq: Operation not permitted
                      

                      That didn't work, but this did:

                      [2.0-RC3][root@guardian.vortex]/root(3): sysctl debug.cpufreq.lowest=1500
                      debug.cpufreq.lowest: 0 -> 1500
                      

                      Then, a few seconds apart shortly after the previous commands:

                      [2.0-RC3][root@guardian.vortex]/root(4): sysctl -a | grep freq
                      kern.acct_chkfreq: 15
                      kern.ntp_pll.time_freq: 0 0
                      kern.ntp_pll.pps_freq: 0 0
                      kern.timecounter.tc.i8254.frequency: 1193182
                      kern.timecounter.tc.ACPI-fast.frequency: 3579545
                      kern.timecounter.tc.TSC.frequency: 1312000000
                      net.inet.sctp.sack_freq: 2
                      debug.cpufreq.verbose: 0
                      debug.cpufreq.lowest: 1500
                      machdep.acpi_timer_freq: 3579545
                      machdep.tsc_freq: 1312000000
                      machdep.i8254_freq: 1193182
                      dev.cpu.0.freq: 1312
                      dev.cpu.0.freq_levels: 1500/15000
                      dev.est.0.freq_settings: 1500/15000 800/8000
                      dev.cpufreq.0.%driver: cpufreq
                      dev.cpufreq.0.%parent: cpu0
                      dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
                      [2.0-RC3][root@guardian.vortex]/root(5): sysctl -a | grep freq
                      kern.acct_chkfreq: 15
                      kern.ntp_pll.time_freq: 0 0
                      kern.ntp_pll.pps_freq: 0 0
                      kern.timecounter.tc.i8254.frequency: 1193182
                      kern.timecounter.tc.ACPI-fast.frequency: 3579545
                      kern.timecounter.tc.TSC.frequency: 1500000000
                      net.inet.sctp.sack_freq: 2
                      debug.cpufreq.verbose: 0
                      debug.cpufreq.lowest: 1500
                      machdep.acpi_timer_freq: 3579545
                      machdep.tsc_freq: 1500000000
                      machdep.i8254_freq: 1193182
                      dev.cpu.0.freq: 1500
                      dev.cpu.0.freq_levels: 1500/15000
                      dev.est.0.freq_settings: 1500/15000 800/8000
                      dev.cpufreq.0.%driver: cpufreq
                      dev.cpufreq.0.%parent: cpu0
                      dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1
                      
                      

                      The CPU seems to be locked at 1500MHz and I do seem to be unable to get it to go beyond 40% utilization no matter how hard I stress test it. At this point I'd say its maybe too early to decide conclusively due to the previously erratic behavior, but based on my observations so far it looks like I have made a significant improvement in performance by using```
                      sysctl debug.cpufreq.lowest=1500

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

                        If you can't get it to use more than 40% cpu then you probably don't need to peg it at 1500MHz. Try one of the other values, 1312 or 1125. This will save power and heat.

                        You can probably set the value permanently in: System >> Advanced >> System Tunables

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • B
                          Brawndo
                          last edited by

                          @stephenw10:

                          You can probably set the value permanently in: System >> Advanced >> System Tunables

                          That was my next question! Thanks again!

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