VIA C7 Pegged at 200 MHz?

Brawndo · Jul 23, 2011, 4:39 PM

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.

stephenw10 · Jul 25, 2011, 1:20 PM

Do you have powerd enabled?

Steve

Brawndo · Jul 26, 2011, 2:34 AM

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.

stephenw10 · Jul 26, 2011, 3:15 AM

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

Brawndo · Jul 26, 2011, 5:58 PM

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.

stephenw10 · Jul 26, 2011, 6:11 PM

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

Brawndo · Jul 26, 2011, 9:59 PM

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

stephenw10 · Jul 26, 2011, 7:51 PM

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

Brawndo · Jul 26, 2011, 9:57 PM

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

stephenw10 · Jul 26, 2011, 10:21 PM

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

Brawndo · Jul 26, 2011, 10:54 PM

@stephenw10:

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

That was my next question! Thanks again!