Re: RELENG_13 and min cpu frequency

On 22 November 2022 6:08:02 am AEDT, mike tancsa <mike@sentex.net> wrote:
 > On 11/18/2022 4:28 PM, mike tancsa wrote:
 > > I noticed that when I moved from an old RELENG11 to RELENG13
 > firewall, 
 > > I was starting to get dropped packets.  Looking at when it was 
 > > happening, it actually seems to happen at times where the network
 > load 
 > > is really low?!?!  When I see a high PPS or high bandwidth, I dont
 > get 
 > > overruns on the nic.  Trying to figure out whats going on, it seems
 > to 
 > > correlate with when the CPU reduces its frequency to save on power.
 > 
 > > When its in turbo mode, it scales up to 4300, but then in the quiet
 > 
 > > hours, it goes down to 800 and that seems to be when I start
 > getting 
 > > the odd overrun.


 > OK, some possible progress. I noticed that
 > 
 >   sysctl -a dev.cpufreq.0.freq_driver
 > dev.cpufreq.0.freq_driver: hwpstate_intel0
 > 
 > Looking at the man page
 > 
 > dev.hwpstate_intel.%d.epp
 >              Energy/Performance Preference.  Valid values range from
 > 0 to 100.
 >              Setting this field conveys a hint to the hardware
 > regarding a
 >              preference towards performance (at value 0), energy
 > efficiency
 >               (at value 100), or somewhere in between.
 > 
 > it defaults to 50.  I changed the value to 5
 > 
 > sysctl -w dev.hwpstate_intel.0.epp=5
 > 
 > 
 > Looking at the freq value
 > 
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > dev.cpu.0.freq: 4410
 > 
 > 
 > Should have a better sense in a couple of days
 > 
 >      ---Mike

Ah, well.  hwpstate_intel was new in 13, I had to read the man online.

I guess you'll try various values from 0 to 100?

Maybe this indicates where powerd or successors might move?

I noticed also that you can turn it off at boot to perhaps re-engage est(4), or choose between the default package-level or per-cpu control, so  there's lots of scope for fine-tuning (or disastrous mismanagement :)

You might find sysutils/stress helpful with tests; loading up N cpus and/or io and/or memory malloc/free, for specified lengths of time.

It might be useful to record, say, cpu.0.temperature with frequencies? And maybe vm.loadavg, if it's behaving itself these days ...

Ah, I really haven't the spare time to be this interested :)

cheers, Ian

 > > CPU is CPU: Intel(R) Xeon(R) E-2226G CPU @ 3.40GHz (3400.00-MHz 
 > > K8-class CPU)