Turbo boost and overclocking are completely different things. Overclocking happens at the BIOS and needs to be supported by the mainboard and BIOS. Has nothing to do with the OS.
Turbo boost happens automatically. Anything above base frequency is directly controlled by the cpu. There is no need or real gain (e.g. energy saving) to adjust CPU frequencies manually or via script nowadays; just enable C-states by setting
performance_cx_lowest="Cmax"
and
economy_cx_lowest="Cmax"
and the CPU will send cores to sleep if not used and otherwise run them on 'optimal' or maximum frequencies (or governed/capped by BIOS settings).
For CPUs that have specific frequency steps (i.e. like in your case, visible by multiple values listen for dev.cpu.N.freq_levels, not a single value appended by /-1), a value of "base frequency +1" given by [/cmd]dev.cpu.N.freq[/cmd] means, the CPU has taken over and is running with either max boost clock or anything in between lowest and highest frequency; at least that's the norm for Intel CPUs - I don't have any AMD CPU to check that, but all older Intel CPUs with fixed frequency steps are reporting 'basefreq + 1' for turbo boost.
A quick search for that topic and ryzen suggests that those never report anything higher than base frequency without special drivers, but they *do* engage turbo boost frequencies if all criteria like temperature and avaliable power budgets are met. Again: it is controlled by the CPU itself, not the OS, hence it happens automatically.
What value(s) are shown for
dev.cpu.N.freq:
on that host? (under load)
You *could* run something like
sysutil/powerd or
sysutil/powerdxx to adjust the frequencies, but any daemon or driver for that purpose will always be _much_ slower to react than the CPU itself can adjust its C-states. So there is no advantage in power savings by running those on halfway modern CPUs and it's more likely to somewhat degrade overall performance and maybe even increase power usage due to that daemon waking up the cores from deep C-states more than necessary.