A D510MO board was lying in the shelves and I decided to give a try for some FreeBSD testing. One topic I wanted to check out was power saving and getting to know. Most CPUs nowadays (even the now dated D510 Atom) support frequency scaling and most often C-States. Without digging into the details of FreeBSD's 'powerd' enabling basic frequency scaling works as simple as adding the following line to \/etc\/rc.conf<\/p>\n
powerd_enable=\"YES\"<\/p>\n
sysctl can tell us what frequencies the CPU can work at ans the current freqency:<\/p>\n
# sysctl dev.cpu | grep freq\r\ndev.cpu.0.freq: 208\r\ndev.cpu.0.freq_levels: 1666\/-1 1457\/-1 1249\/-1 1041\/-1 833\/-1 624\/-1 416\/-1 208\/-1<\/pre>\nNow to check if the frequency scaling was working, hitting the CPU with some load was required, but where to take? On Windows a pretty simple tip taken from old journals was to fire up the system calculator app in scientific mode and let it calculcate very large factorials (german: Fakult\u00e4t) like 999999999999! which will load the CPU and cause some heating in order to verify how loud a system can become - or in this case: Cause the CPU frequency to go up under load and scale down when back idle. It turns out FreeBSD base ships a with console-based calculator \u00a0called bc (on most Linuxes it's GNU bc) which according to this yet old but still working article in Linux journal allows exactly this with a factorial function:<\/p>\n
# bc\r\ndefine f(x) {\r\n if (x <= 1) return (1);\r\n return (x*f(x-1));\r\n}\r\n\r\nf(999999999)<\/pre>\nIn parallel on a second terminal execute \"powerd -v\" to see how the frequency goes up and down:<\/span><\/p>\n
# powerd -v\r\npowerd: unable to determine AC line status\r\n[... system is idle, starting bc in the meantime ...]\r\nload 0%, current freq 208 MHz ( 7), wanted freq 208 MHz\r\nload 0%, current freq 208 MHz ( 7), wanted freq 208 MHz\r\nload 4%, current freq 208 MHz ( 7), wanted freq 208 MHz\r\n[...]\r\nload 38%, current freq 416 MHz ( 6), wanted freq 261 MHz\r\nload 141%, current freq 416 MHz ( 6), wanted freq 1044 MHz\r\nchanging clock speed from 416 MHz to 1249 MHz\r\nload 100%, current freq 1457 MHz ( 1), wanted freq 3332 MHz\r\nchanging clock speed from 1457 MHz to 1666 MHz\r\nload 93%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 101%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\n[ ... bc is running and now gets stopped ...]\r\nload 100%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 68%, current freq 1666 MHz ( 0), wanted freq 3332 MHz\r\nload 0%, current freq 1666 MHz ( 0), wanted freq 3227 MHz\r\nload 0%, current freq 1666 MHz ( 0), wanted freq 3126 MHz\r\nload 0%, current freq 1666 MHz ( 0), wanted freq 3028 MHz\r\n[...]\r\nload 0%, current freq 1666 MHz ( 0), wanted freq 1453 MHz\r\nchanging clock speed from 1666 MHz to 1457 MHz\r\nload 0%, current freq 1457 MHz ( 1), wanted freq 1407 MHz\r\n[...]\r\nload 0%, current freq 1457 MHz ( 1), wanted freq 1238 MHz\r\nchanging clock speed from 1457 MHz to 1249 MHz\r\nload 0%, current freq 1249 MHz ( 2), wanted freq 1199 MHz\r\n[... we see all supported clock speeds freq_levels passing by]\r\nload 0%, current freq 416 MHz ( 6), wanted freq 208 MHz\r\nchanging clock speed from 416 MHz to 208 MHz\r\nload 6%, current freq 208 MHz ( 7), wanted freq 208 MHz<\/pre>\nThis little experiment show that powerd is not that agressive when slowing the frequency back down as quickly as it rushes up, maybe tha its something to tune more aggressively on laptops.<\/p>\n
Temperature readings<\/strong><\/p>\n
For CPU temperatures it happens to be as simple as loading the 'coretemp' module via kldload coretemp. Adding\u00a0coretemp_load=\"YES\" to \/boot\/loader.conf enables the module ad system start. Afterwards CPU temperatures were readable via sysctl too:<\/p>\n
# sysctl dev.cpu | grep temperature\r\ndev.cpu.0.temperature: 44.0C\r\ndev.cpu.1.temperature: 44.0C\r\ndev.cpu.2.temperature: 41.0C\r\ndev.cpu.3.temperature: 42.0C<\/pre>\nC-States<\/strong><\/p>\n
Now most CPUs also support C-States to send to sleep when possible which would be actually quite good for power saving. In FreeBSD it seems sysctl can be used to query what C-states the CPU cores support via dev.cpu.<id>.cx_supported i.e.<\/p>\n
# sysctl dev.cpu.1\r\n[...]\r\ndev.cpu.1.cx_supported: C1\/1\/3\r\ndev.cpu.1.cx_lowest: C1\r\ndev.cpu.1.cx_usage: 100.00% last 58973us\r\n[...]<\/pre>\nTechnically this would suggest that the CPU has the capability to use C3 but the current lowest C-State would be C1? I tried sysctl dev.cpu.1.cx_lowest=C3 as well as the global hw.acpi.cpu.cx_lowest=C3 (for boot this would be put in \/etc\/syctl.conf) but allas it remained always using 1 C-State.<\/span><\/p>\n
It seems the Atom D510 is one of those low-end CPUs that do not support C-States anyway as per ark.intel.com<\/a>. I've come across this thanks to FreeBSD PR 160561<\/a> where a very similar D525 was reported.
\nPossibly the CPU isn't telling correctly about its supported C-states allas.<\/p>\nThis was done on FreeBSD 10-BETA3 btw.<\/p>\n","protected":false},"excerpt":{"rendered":"
A D510MO board was lying in the shelves and I decided to give a try for some FreeBSD testing. One topic I wanted to check out was power saving and getting to know. Most CPUs nowadays (even the now dated D510 Atom) support frequency scaling and most often C-States. Without digging into the details of … more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","footnotes":""},"categories":[1],"tags":[37,36,38],"class_list":["post-351","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-atom","tag-freebsd","tag-powerd"],"_links":{"self":[{"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/posts\/351","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/comments?post=351"}],"version-history":[{"count":0,"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/posts\/351\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/media?parent=351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/categories?post=351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.simweb.ch\/blog\/wp-json\/wp\/v2\/tags?post=351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}