On Sunday, January 5, 2014 5:00:00 PM UTC-5, Siarhei Siamashka wrote:
>
> On Wed, 1 Jan 2014 20:03:35 -0800 (PST)
> Patrick Wood <patric...@gmail.com <javascript:>> wrote:
>
> > On Wednesday, January 1, 2014 5:54:20 PM UTC-5, Siarhei Siamashka wrote:
> > > I myself still see no good reason for using any governor other than
> > > "performance" when running with a wall connected power plug. Poor
> > > default cpufreq behaviour is a major performance pitfall for
> > > inexperienced users and it totally kills desktop responsiveness.
> > >
> > > We may introduce a new customized cpufreq governor and set it by
> > > default. The users can always change the cpufreq settings to whatever
> > > they want.
> > >
> > > Moreover, as a temporary solution, I would probably even advocate
> > > setting the "performance" cpufreq governor for linux-sunxi kernels
> > > by default (for the linux defconfigs). Do we have many tablet users,
> > > who are running linux instead of android and also need good battery
> > > life (have no usb ports or chargers nearby for providing power)?
> >
> > I believe that a minimum setting of 408MHZ with the "interactive"
> governor
> > works quite well. This governor raises the CPU clock much faster than
> > ondemand, and 408MHz seems to be a spot where the SoC will power down a
> lot
> > of blocks when idle.
>
> Is this just a speculation? Or some kind of research has been done?
>
It was based on the comments in this commit:
47d3b18876571835f0fce7b7b8125110713e30fc
Also, my experience with performance on the A10 devices over the last two
years has shown me that ondemand is a really terrible governor, as it
doesn't boost the CPU frequency unless utilization has been high over an
extended period, so even programs that are CPU bound don't cause it to
switch if they spend just a little time reading or writing data.
interactive is much better at increasing the CPU clock even on relatively
small changes in demand.
> What we know for sure is that the current cpufreq defaults ("ondemand"
> for sun4i and "fantasy" for sun7i) are responsible for really poor
> performance. Note that sun4i and sun7i are defaulting to different
> governors for some unknown reason.
>
> And there is one more source of inconsistency. The range of allowed CPU
> frequencies and their voltages can be configured in fex files for
> each device/board individually. For example, compare cubieboard2 and
> cubietruck fex files:
>
> https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubieboard2.fex#L957
>
>
> https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L944
>
> The minimum CPU clock frequency for the cubieboard2 is set to 400MHz.
> And for cubietruck the lowest limit is 60MHz. This means that the
> "fantasy" governor on cubieboard2 will run the idle system at 384MHz,
> but on cubietruck that would be supposedly 60MHz. Funny, isn't it?
>
> This is a big freaking mess.
>
No argument there.
>
> > Also, perhaps the minimum setting should be 1GHz at boot time and not
> > dropped until the UI is up and running, since this affects the overall
> boot
> > speed by quite a bit, and that's the first impression any user gets of a
> > distro -- how long it takes to get my login prompt or splash screen.
>
> Does it mean that currently the "ondemand" / "fantasy" / "interactive"
> governors are also responsible poor boot time? That's one more reason
> to do something about this.
>
I don't know about fantasy, but I do know that boot times are faster with
interactive than ondemand given the same 60 MHz minimum clock frequency
setting (based on the boot log time stamps); boot times don't change much
switching from interactive to performance.
>
> I tried to look into this stuff and run some tests on cubieboard2 and
> cubietruck using the current stage/linux-sunxi-3.4 branch.
>
> As Michal Suchanek mentioned earlier in this thread, we have AXP209
> power management chip. And it has some interesting registers (REG 00H
> and REG 01H):
> http://linux-sunxi.org/AXP209#REG_00H:_Power_input_status
> The values of these registers are exposed to the userspace via
> /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
> AXP209 also has IRQs for the notifications about plugging/removing
> different power sources: ACIN (power plug), VBUS (miniusb) and LiPo
> battery. So looks like the hardware mostly provides all that we need.
>
> Now the results of some tests are below. They were done with screen
> blanked because this saves ~20 mA of current. I also have a LiPo
> battery, earlier bought from OLIMEX:
> https://www.olimex.com/Products/Power/BATTERY-LIPO6600mAh/
> The connector of this LiPo battery is mechanically incompatible
> with cubietruck, but I still got it temporarily connected just
> for the sake of this experiment using jumper wires. Now the results:
>
> === cubietruck ===
>
> # echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
>
> # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
> only power adapter : REG[0x0]=0xc1,REG[0x1]=0x10
> power adapter + miniusb : REG[0x0]=0xf9,REG[0x1]=0x10
> only miniusb : REG[0x0]=0x3d,REG[0x1]=0x70
> miniusb + lipo battery : REG[0x0]=0x3d,REG[0x1]=0x70
> power adapter + lipo battery : REG[0x0]=0xc5,REG[0x1]=0x70
> only lipo battery : REG[0x0]=0x1,REG[0x1]=0x30
>
> Note: "only miniusb" and "miniusb + lipo battery" really have the
> same AXP20 register values, that's not a typo.
>
> Power consumption measurements with a multimeter on the 5V barrel
> power plug:
>
> idle at 60MHz : ~271 mA
> idle at 912MHz : ~287 mA
>
> Note: while cpufreq reports 60MHz clock frequency, the CPU really
> runs faster than this and the benchmarks indicate that it
> is more likely to be something around ~240MHz.
>
> === cubieboard2 ===
>
> # echo 1 > /sys/devices/platform/disp/graphics/fb0/blank
> # echo 60000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
> # echo 60000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
>
> # cat /sys/devices/platform/sunxi-i2c.0/i2c-0/0-0034/axp20_regs
> REG[0x0]=0xc1,REG[0x1]=0x10
>
> Note: The values of AXP20 registers are always the same (no matter
> whether only a miniusb cable is plugged, or a barrel power plug,
> or both of them).
>
> Power consumption measurements with a multimeter on the 5V barrel
> power plug:
>
> idle at 60MHz : ~219 mA
> idle at 912MHz : ~238 mA
>
> Note: the 60MHz CPU clock speed is fake here too (just like for
> the cubietruck).
>
> ===
>
> Now what kind of conclusions can we make? The frequency scaling
> is really broken in linux-sunxi, especially for sun7i (where it is
> even failing to set the correct clock frequency). The power consumption
> reduction on the idle system using "ondemand" instead of "performance"
> governor is currently less than 10% for Allwinner A20 devices. That's
> partially because they don't seem to be really able to clock the
> CPU down to 60MHz.
>
So for A20, it really doesn't make much sense to clock it any slower than
full speed.
>
> Just as a reminder, for cubieboard1 with Allwinner A10 the difference
> between idle 60MHz and idle 1008MHz was more significant (~192 mA vs.
> ~298 mA).
>
Which is why it makes sense to study this some more on the A10.
>
> As a short term solution, I'm now really in favour of setting the
> cpufreq governor to "performance" by default. In the case if there
> are no objections, I'm going to send a defconfig patch in a few days.
> It is in the best interests of the users of the battery power to
> step in and contribute to cleaning this mess. Just setting the cpufreq
> governor to "ondemand" does not really help to improve the battery
> life. That's a kind of fig leaf solution. By the way, the performance
> tuned distributions seem to be already changing the cpufreq governor
> to "performance":
>
> http://cubieboard.org/2013/12/21/a-debian-image-for-cubieboard2-cubieez/
>
> A better solution is to really ramp up the CPU to the maximum clock
> speed if we have some external power source connected (ACIN or VBUS).
> Adhering to the "principle of least surprise", it makes sense to fork
> the "ondemand" governor with some new name and make it the default.
> The users will be able to lookup the name of this new governor in
> google and find linux-sunxi wiki with the detailed explanations
> about how it works :-) Now what it really should do:
> 1. It can subscribe to the notifications from AXP209 about
> plugging/unplugging the external power sources and run the CPU
> at the maximum speed when external power is available.
> This should solve all the performance issues for the
> development boards and any devices running from the external
> power sources. I believe that this is exactly the primary use
> case for the vast majority of linux-sunxi users :-)
> 2. It might include the tweaks from http://linux-sunxi.org/Cpufreq
> in the case if they are confirmed to be useful when running on
> a battery.
> 3. In the case if we have only microusb connected and can take only
> 500 mA from it, then we might be interested in preventing the
> battery from eventually getting drained. As we know, even the
> CPU alone can cause more than 500 mA consumption if really
> stressed. The cpufreq governor may try to limit the maximum
> CPU clock speed if the LiPo battery charge is low and only
> microusb is connected for charging it.
> 4. Maybe do something to prevent SoC overheating if CPU, Mali and
> Cedar are all used at the same time? AXP209 has some ADC and we
> might try to limit the CPU / Mali / Cedar clock frequencies
> if the power drain is too high. But the properly working thermal
> sensor in A10 / A20 (if it exists) would be of course a better
> solution.
>
> I may even give this a try on the next weekend. But frankly speaking,
> I don't want to be sidetracked by this cpufreq stuff because it looks
> like it may take more time than I can really afford to spend on it :(
>
> This would be ideal, but you're right about it possibly being a time sink.
Good luck, though.
Pat
> --
> Best regards,
> Siarhei Siamashka
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
