A good SD card image for A10-OLinuXino-Lime?

[Siarhei Siamashka]

Hello,

On this weekend, I tried to check the Debian Linux image
provided for A10-OLinuXino-Lime at

http://olimex.wordpress.com/2013/12/13/building-debian-linux-image-for-a10-olinuxino-lime-with-kernel-3-4-67/

As can be seen from the user comments in that blog post, it
happens to be very far from perfect. I also tried to add
some comments myself to point some obvious issues.

It is understandable that the board is very new and it's only
the preliminary test image. However I'm expecting that in a
matter of days, various people and bloggers are going to start
using this particular image (or some minor improvement of it)
and comparing LIME to Raspberry Pi and BeagleBone Black. And,
I guess, negative reviews are not going to do any good for
anyone in the sunxi community.

So I wonder if OLIMEX might use some help from the community
to quickly prepare some decent desktop distro which could be
used to showcase all the recent advancements (like cedar
hardware accelerated video decoding, etc.)?

Just a short (and incomplete) list of things which are
required for a good desktop distro:

1. When running on a power plug (instead of the battery),
the cpufreq governor should be set to "performance". This
is really critical for desktop responsiveness.
2. LIME does not have much RAM, so finally doing something
about the memory reservation mess would be a good idea
(I guess with the other boards going to 1GB and even 2GB
of RAM, the priority for solving this problem was not high
enough up until now).
3. The HDMI EDID code in the kernel needs to be tweaked to use
50Hz refresh rate instead of 60Hz if the monitor or TV
supports it.
4. In the case of X11 desktop, the xf86-video-fbdev driver is
not fast enough and needs to be replaced. In particular,
we can see that the users are typically immediately trying
some sort of video playback and complain if it is not working
nicely.
5. Maybe something else, could probably remember later.

Using LXDE or XFCE is a good choice for desktop. The cedar
hardware accelerated video decoding can be quite nicely
demonstrated using something like smplayer GUI frontend
for mplayer.

What else? Mali 3D acceleration (yeah, that's the only
ugly proprietary bit). The use of glshim to emulate OpenGL
can provide some nice games. And glshim can also can provide
hardware accelerated glxgears! :) Yes, this sounds stupid,
but so many users are trying to check the performance of
glxgears that it's not even funny.

There is just one thing I'm really worried about. The 16-bit
memory interface is a major performance risk factor. I wonder
how LIME performs on memory intensive workloads (such as
graphics) when compared with, for example, Cubieboard.

--
Best regards,
Siarhei Siamashka

[Tsvetan Usunov]

Hi Siarhei
You are right, the RPI fans are a bit dissapointed by the Debian image
generated from Linux-Sunxi GitHub and no hardware acceleration.
Dimitar is trying to make one now with acceleration enabled, meantime
we will release Android image which will have video play hardware
accelerated, so if one wants to use Lime as video player will be able
to do so under Android. IIRC there is also XBMC port which runs on A10
with acceleration, so we will check this also.
Best regards
Tsvetan

2013/12/16 Siarhei Siamashka <siarhei....@gmail.com>:

[Siarhei Siamashka]

On Mon, 16 Dec 2013 14:13:11 +0200
Tsvetan Usunov <tsveta...@gmail.com> wrote:

> Hi Siarhei
> You are right, the RPI fans are a bit dissapointed by the Debian image
> generated from Linux-Sunxi GitHub and no hardware acceleration.

It's not just RPI fans. Trying your debian image (on a cubieboard,
because I don't have lime yet) was kinda a wake up call for me.
And I have also seen some other less than perfect linux distros
earlier. People here may be developing some nice software, trying
their best to optimize it, but still get their efforts wasted by
the "last mile" problem. If distro maintainers don't do a really
good job, then the end users have poor experience and a wrong
impression about the performance of the hardware.

I'll try to make a desktop linux demo image available in a few days,
so that people could compare it with their current distros :)

> Dimitar is trying to make one now with acceleration enabled, meantime
> we will release Android image which will have video play hardware
> accelerated, so if one wants to use Lime as video player will be able
> to do so under Android.

It is surely useful to have an Android image too.

> IIRC there is also XBMC port which runs on A10 with acceleration, so
> we will check this also.

IMHO it does not make much sense to waste time on XBMC hacks
anymore, because we already have an alternative solution for
hardware accelerated video playback, which is 100% free software.
I mean libvdpau-sunxi.

[Tsvetan Usunov]

> It's not just RPI fans. Trying your debian image (on a cubieboard,
> because I don't have lime yet) was kinda a wake up call for me.

send me your address and you will have LIME to test ;)

> And I have also seen some other less than perfect linux distros
> earlier. People here may be developing some nice software, trying
> their best to optimize it, but still get their efforts wasted by
> the "last mile" problem. If distro maintainers don't do a really
> good job, then the end users have poor experience and a wrong
> impression about the performance of the hardware.

this is correct

> I'll try to make a desktop linux demo image available in a few days,
> so that people could compare it with their current distros :)

perfect

Tsvetan

[Michal Suchanek]

On 17 December 2013 07:09, Siarhei Siamashka

<siarhei....@gmail.com> wrote:
> On Mon, 16 Dec 2013 14:13:11 +0200
> Tsvetan Usunov <tsveta...@gmail.com> wrote:
>
>> Hi Siarhei
>> You are right, the RPI fans are a bit dissapointed by the Debian image
>> generated from Linux-Sunxi GitHub and no hardware acceleration.
>
> It's not just RPI fans. Trying your debian image (on a cubieboard,
> because I don't have lime yet) was kinda a wake up call for me.
> And I have also seen some other less than perfect linux distros
> earlier. People here may be developing some nice software, trying
> their best to optimize it, but still get their efforts wasted by
> the "last mile" problem. If distro maintainers don't do a really
> good job, then the end users have poor experience and a wrong
> impression about the performance of the hardware.

We don't even have anything of value to distro maintainers. Distro
wants something stable that can be packaged and forgot.

With the rapid development of sunxi you would need new package of
something every week.

>
> I'll try to make a desktop linux demo image available in a few days,
> so that people could compare it with their current distros :)

Maybe like an image with checkouts of the current drivers and libs
somewhere in /usr/src or /opt and symlinks and configuration files in
place to use the files built from these checkouts.

Then you update by git pull && make.

That is pretty much what I use but I have quite hackish image where
some libraries are symlinked from the source dir, some are installed,
some are copied because make install puts them in a wrong place, etc.

Thanks

Michal

[Димитър Гамишев]

Hi Siarhei,

i can not agree with everything you say.

1. I think that user may deal with cpu frequency settings, there are many examples to do it.

I could not predict if there would be people wanting their boards working on batery or not

2. There is no effective way to do it, but kernel hacking, or using kernel command line parameters. 

If I hard code this settings in u-boot or kernel, users will not be able to change easily themselfs. This will cause other kind of problems. Some people will tell that i am a dirty bastard who does not give them freedom to do what they want. 

3. Yes I agree with that, and I will do it in shortly

4. also with that, this one is done

5. Siarhei keep in mind that only I work on this image, and the goal is that everyone can build it alone. 

p.s

I will appreciate any help :)

~Best

Dimitar

[Michal Suchanek]

On 17 December 2013 19:15, Димитър Гамишев <gami...@gmail.com> wrote:
> Hi Siarhei,
> i can not agree with everything you say.
>
> 1. I think that user may deal with cpu frequency settings, there are many
> examples to do it.
> I could not predict if there would be people wanting their boards working on
> batery or not

Is there not an event generated when the AC is plugged in/removed?

If not that's certainly a bug that should be fixed in the AXP driver.

If yes there are PM scripts that should do this for you but may need
some setting up/debugging.

Given this is Debian you will probably want something like
acpi-support or powermgmt-base.

I did not get to testing this on CT yet :s

>
> 2. There is no effective way to do it, but kernel hacking, or using kernel
> command line parameters.
> If I hard code this settings in u-boot or kernel, users will not be able to
> change easily themselfs. This will cause other kind of problems. Some people
> will tell that i am a dirty bastard who does not give them freedom to do
> what they want.

You should choose sane defaults. Everyone can change the kernel
argument afterwards but the shipping configuration should be tested to
work reasonably well. Since lime is pretty much the only A10 devboard
with so little RAM this is worth consideration.

Thanks

Michal

[Siarhei Siamashka]

On Tue, 17 Dec 2013 11:36:29 +0100
Michal Suchanek <hram...@gmail.com> wrote:

> On 17 December 2013 07:09, Siarhei Siamashka
> <siarhei....@gmail.com> wrote:
> > On Mon, 16 Dec 2013 14:13:11 +0200
> > Tsvetan Usunov <tsveta...@gmail.com> wrote:
> >
> >> Hi Siarhei
> >> You are right, the RPI fans are a bit dissapointed by the Debian image
> >> generated from Linux-Sunxi GitHub and no hardware acceleration.
> >
> > It's not just RPI fans. Trying your debian image (on a cubieboard,
> > because I don't have lime yet) was kinda a wake up call for me.
> > And I have also seen some other less than perfect linux distros
> > earlier. People here may be developing some nice software, trying
> > their best to optimize it, but still get their efforts wasted by
> > the "last mile" problem. If distro maintainers don't do a really
> > good job, then the end users have poor experience and a wrong
> > impression about the performance of the hardware.
>
> We don't even have anything of value to distro maintainers. Distro
> wants something stable that can be packaged and forgot.

I don't quite agree here. The value of the linux distributions for the
end users are timely updates with the important bugfixes (security fixes
at least) and first-line support for the basic user problems (also
communicating upstream when necessary).

The "packaged and forgot" approach would mean a poor job done on their
side. Yes, they do unpaid volunteer work and we can't demand/expect
much. But most of us are doing the unpaid volunteer work too when
contributing to linux sunxi.

> With the rapid development of sunxi you would need new package of
> something every week.
>
> >
> > I'll try to make a desktop linux demo image available in a few days,
> > so that people could compare it with their current distros :)
>
> Maybe like an image with checkouts of the current drivers and libs
> somewhere in /usr/src or /opt and symlinks and configuration files in
> place to use the files built from these checkouts.
>
> Then you update by git pull && make.
>
> That is pretty much what I use but I have quite hackish image where
> some libraries are symlinked from the source dir, some are installed,
> some are copied because make install puts them in a wrong place, etc.

My vision for this is just some sort of a demo sdcard image, similar
to what they do with livecd in the desktop world. No need for a
properly configured installation with all the security and regular
updates in place. That's would be the job of the distro maintainers,
and I don't want to eat their lunch ;)

Still we can showcase the basic tasks like internet browsing, video
playback, office applications, games and other cool things. All running
with decent performance, just like it should preferably do in a good
linux distro.

[Tim Fletcher]

Maybe something like the NOOBS software from the Raspberri Pi world?

It's a bootable card that gives you a decent UI to deploy different OS
images.

--
Tim Fletcher <tim.fl...@gmail.com>

[Siarhei Siamashka]

On Tue, 17 Dec 2013 10:15:56 -0800 (PST)
Димитър Гамишев <gami...@gmail.com> wrote:

> Hi Siarhei,
> i can not agree with everything you say.
>
> 1. I think that user may deal with cpu frequency settings, there are many
> examples to do it.

Sure, the users may tweak cpufreq settings themselves. And there are
guides, wiki pages, mailing list archives, etc. But a significant
fraction of users will still end up coming to a conclusion that
the performance of the hardware just sucks. That's the reality.

In some cases the users will come asking for help though. I have seen
tens of users complaining about performance problems in the #cubieboard
and #linux-sunxi irc channels, which got resolved by changing the
cpufreq governor to "performance".

If the CPU is sitting at 60MHz (or even 400MHz) at the time when the
user tries to type text or click the UI buttons, the response is not
going to be really instant. Even the Raspberry Pi simply running at
700MHz has an advantage here ;)

We can compare the current draw of the cubieboard1 from the 5V PSU
for different clock frequencies using the current stage/sunxi-3.4
kernel (with screen blanked):

idle ondemand 60MHz - ~192 mA
idle userspace 408MHz - ~233 mA
idle userspace 816MHz - ~268 mA
idle performance 1008MHz - ~298 mA

Changing to the "performance" cpufreq governor costs additional ~100 mA,
or ~1.5x idle power consumption increase. Naturally, none of these
numbers is particularly good for battery powered devices (smartphones
typically use a much more sophisticated power management).

This extra idle power consumption is not really significant if we
are using a wall plugged power adapter. Some users on irc expressed
concerns about the CPU potentially overheating more when running the
"performance" cpufreq governor instead of "ondemand". It just makes
sense to explain to them that the power consumption heavily depends
on what the CPU is doing. For prolonged high CPU load, both "ondemand"
and "performance" are running the CPU at the maximum speed, so no
difference for such use case. And the idle power consumption even
with the "performance" governor is still much lower than the power
consumption under high CPU load. For comparison, running tests
with https://raw.github.com/ssvb/cpuburn-arm/master/cpuburn-a8.S :

cpuburn userspace 60MHz - ~215 mA
cpuburn userspace 408MHz - ~406 mA
cpuburn userspace 816MHz - ~784 mA
cpuburn performance 1008MHz - can't be measured (*)

(*) the tested cubieboard1 just deadlocks under high load if multimeter
is connected, but runs fine without multimeter.

> I could not predict if there would be people wanting their boards working
> on batery or not

The question was whether it is possible to detect the connected battery
(or connected power plug) by the software means on A10-OLinuXino-Lime
hardware.

I don't have any battery powered sunxi devices (except for cubietruck,
which seems to have a battery connector). The allwinner based android
tablet users might probably check if the battery state indicator works
there. And if yes, try to check what kind of code is responsible for it.

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)?

> 2. There is no effective way to do it, but kernel hacking, or using kernel
> command line parameters.
> If I hard code this settings in u-boot or kernel, users will not be able to
> change easily themselfs. This will cause other kind of problems. Some
> people will tell that i am a dirty bastard who does not give them freedom
> to do what they want.

Kernel hacking is what we are doing here in this mailing list ;)
Just check the current stage/sunxi-3.4 kernel with CMA support added.
If you provide "sunxi_g2d_mem_reserve=0" option in the kernel cmdline,
then there should be almost no memory wasted. We still can do a
better memory allocation for the sunxi disp though, so that even
the headless servers could work with the same configuration of
the kernel.

Needless to say that testing of the stage/sunxi-3.4 branch is very
much welcome.

> 3. Yes I agree with that, and I will do it in shortly

The modified EDID code needs some kernel hacking too. Because we want
it to be clever enough to use 50Hz refresh automatically, but only in
the case if the monitor or TV really supports it.

The reduced monitor refresh rate saves memory bandwidth and improves
performance.

> 4. also with that, this one is done

Good.

> 5. Siarhei keep in mind that only I work on this image, and the goal is
> that everyone can build it alone.
>
> p.s
> I will appreciate any help :)

Sure.

[Patrick Wood]

On Wednesday, January 1, 2014 5:54:20 PM UTC-5, Siarhei Siamashka wrote:

<snip>

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.

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. 

[Siarhei Siamashka]

On Wed, 1 Jan 2014 20:03:35 -0800 (PST)
Patrick Wood <patric...@gmail.com> 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?

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.

> 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 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.

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).

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 :(

[Michal Suchanek]

Given these stunning power savings I guess playing with cpufreq is
really quite pointless on A20.

The way to go is probably to use performance governor and STR when
battery powered.

It should work on sun7i iirc.

I wonder if there is some way to power down one of the cores and what
savings that could give.

Thanks

Michal

[Olliver Schinagl]

On 01/05/14 23:00, Siarhei Siamashka wrote:
> # 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.

If you look in the AXP 202 (english, the 209 cn version MIGHT be
different (i haven't looked) though Carlo/n01 may say what happens here.
(ugly copy paste from pdf)

The following table has listed the status bits
and meanings of external power registers.
Register Status
Bits
Description
REG00H[7] Indicating the presence of external ACIN
REG00H[6] Indicating whether the external ACIN is usable or not
REG00H[5] Indicating the presence of external VBUS
REG00H[4] Indicating whether the external VBUS is usable or not
REG00H[3] Indicating whether the VBUS voltage is above VHOLD when used
REG00H[1] Indicating whether ACIN/VBUS short circuits on PCB or not
REG00H[0] Indicating whether the system is triggered to startup by
ACIN/VBUS or not

[Carlo Caione]

On Mon, Jan 6, 2014 at 12:04 AM, Olliver Schinagl <oli...@schinagl.nl> wrote:
> On 01/05/14 23:00, Siarhei Siamashka wrote:
>>
>> # 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.
>
>
> If you look in the AXP 202 (english, the 209 cn version MIGHT be different
> (i haven't looked) though Carlo/n01 may say what happens here. (ugly copy
> paste from pdf)

Unfortunately I haven't touched the power subsystem yet.
I'll be more useful in a couple of days :)

--
Carlo Caione

[Patrick Wood]

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> 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. 

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. 

This would be ideal, but you're right about it possibly being a time sink.  Good luck, though.

Pat

[Roman Mamedov]

On Sun, 5 Jan 2014 16:01:20 -0800 (PST)
Patrick Wood <patric...@gmail.com> wrote:

> 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

This is easily tunable via knobs mentioned at http://linux-sunxi.org/Cpufreq

Specifically you want to reduce the up_threshold, in the example on that page
the frequency will be boosted as soon as the CPU utilization even touches 25%.
Not "high over extended period", is it? And then if an issue arises that it
drops back too quickly, that can be tuned by changing sampling_down_factor.

> so even programs that are CPU bound don't cause it to
> switch if they spend just a little time reading or writing data.

Set io_is_busy to 1, and even time spent reading or writing data (in iowait)
will count as "CPU load" for the purposes of frequency switching.

> interactive is much better at increasing the CPU clock even on relatively
> small changes in demand.

My guess is that people tend to invent crazy new obscure governors mostly
because they didn't spend any time reading documentation for the existing ones
(and how to properly configure them for the usage scenario at hand).

--
With respect,
Roman

[Roman Mamedov]

On Mon, 6 Jan 2014 00:00:00 +0200
Siarhei Siamashka <siarhei....@gmail.com> wrote:

> 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.

A new governor (and a platform-specific one, no less) is unlikely to ever be
mainlined. Try mainlining those "fantasy" or "interactive", you'll more likely
be <del>laughed out of the building</del> politely pointed to all the tunables
of "ondemand", some of which I just listed in my other E-Mail.

If you *really* want to react to power events, there is no reason a userspace
program can't change max/min_frequency of the ondemand governor, or even
switch between ondemand and performance as the power situation allows; it could
be either a daemon or a oneshot script called from udev(?), if changes are only
required on plugging/unplugging of power source. In fact I think there should
be something like that already (designed for laptops).

--
With respect,
Roman

[Patrick Wood]

On Sunday, January 5, 2014 7:13:06 PM UTC-5, Roman Mamedov wrote:

On Sun, 5 Jan 2014 16:01:20 -0800 (PST)
Patrick Wood <patric...@gmail.com> wrote:

> 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

This is easily tunable via knobs mentioned at http://linux-sunxi.org/Cpufreq

Specifically you want to reduce the up_threshold, in the example on that page
the frequency will be boosted as soon as the CPU utilization even touches 25%.
Not "high over extended period", is it? And then if an issue arises that it
drops back too quickly, that can be tuned by changing sampling_down_factor.

Yes, but most people don't bother to read that. In fact, most people don't know about the cpu governors; they just complain about performance.  The default settings for ondemand are obviously poor for non-battery use.  Also, none of these knobs helps boot times. 

> so even programs that are CPU bound don't cause it to
> switch if they spend just a little time reading or writing data.

Set io_is_busy to 1, and even time spent reading or writing data (in iowait)
will count as "CPU load" for the purposes of frequency switching.

See comment above. 

>  interactive is much better at increasing the CPU clock even on relatively
> small changes in demand.

My guess is that people tend to invent crazy new obscure governors mostly
because they didn't spend any time reading documentation for the existing ones
(and how to properly configure them for the usage scenario at hand).

See comment above.  The current default governor (ondemand) and/or its default settings need to be changed.

Pat

 

--
With respect,
Roman

[Siarhei Siamashka]

I'm more worried that there seems to be a bug in sun7i cpufreq. It
thinks that the CPU clock frequency is 60MHz, but in fact the
multipliers are likely wrong because the actual performance of
the CPU is higher (~240MHz). Still the voltages are taken from
the table and applied.

One experiment was to force the use of the cpufreq table hardcoded
in the kernel sources instead of taking it from fex by changing
'use_default_table' variable:
https://github.com/linux-sunxi/linux-sunxi/blob/77a43694fca9db61/arch/arm/mach-sun7i/cpu-freq/cpu-freq.c#L84
If I do this, the voltage for 60MHz clock speed would be 0.9V
instead of 1.05V as hardcoded in the cubietruck fex:
https://github.com/linux-sunxi/sunxi-boards/blob/36a6f268b69afde7/sys_config/a20/cubietruck.fex#L961
And after this change, any attempt to use 0.9V with the clock
frequency which happens to be actually used instead of 60MHz
results in a deadlock. The 0.9V is apparently not enough.

I'm also wonder whether 1.05V used by cubietruck when it attempts
to reduce the clock frequency to 60MHz (and uses something else
instead) is still safe. It might be a potential reliability issue.

It would be interesting to test some other kernels (from android?),
because this might be a bug only affecting sunxi-3.4.

> The way to go is probably to use performance governor and STR when
> battery powered.

STR as Suspend-to-RAM? That would be very interesting indeed.

> It should work on sun7i iirc.

With AR100 chip? Or also without it?

> I wonder if there is some way to power down one of the cores and what
> savings that could give.

Yes, an interesting idea indeed.

[Siarhei Siamashka]

It's good to know that somebody is taking care of the power
management in linux-sunxi. Thanks.

About the AXP20 register values. Yes, I have found and checked
the AXP202 manual. And the linux-sunxi wiki also explains these
bits.

It is just interesting how cubieboard2 and cubietruck set the
bits there. And some of them seem to be a bit odd. For example, AXP
in cubietruck seems to think that it has a battery and is charging
it when only miniusb cable is connected. Cubieboard2 can't see any
differences between the power sources at all and always has the
same bits in these registers. So I got the data and dumped it to
the mailing list, with the hope that other people may get some
ideas about why this is happening and how to interpret it :)

It would be also interesting to know how A10-OLinuXino-Lime behaves.
Is it similar to cubietruck or cubieboard2 or maybe in some other
way? The OLIMEX people have avoided this question so far. I guess
they want us to just RTFM the schematics and stop asking silly
questions ;)

[Siarhei Siamashka]

On Mon, 6 Jan 2014 06:39:38 +0600
Roman Mamedov <r...@romanrm.net> wrote:

> On Mon, 6 Jan 2014 00:00:00 +0200
> Siarhei Siamashka <siarhei....@gmail.com> wrote:
>
> > 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.
>
> A new governor (and a platform-specific one, no less) is unlikely to ever be
> mainlined.

It's a bit too early to talk about mainlining. We need to solve the
problem at hand before planning too far ahead. I proposed this
particular solution with the upgrade path for sunxi-3.4 in mind.

Also I don't pretend to know much about power management. But the
current default cpufreq performance is simply unacceptable and
something has to be done about it. Enough is enough.

> Try mainlining those "fantasy" or "interactive", you'll more likely
> be <del>laughed out of the building</del> politely pointed to all the tunables
> of "ondemand", some of which I just listed in my other E-Mail.

Well, it is the primary responsibility of the kernel to provide an
efficient way to use the hardware. If the kernel fails to handle
this efficiently for any reasons, then it is doing a poor job and
needs to be improved.

And the kernel is indeed always evolving. New things are being
introduced whenever they are justified. And for example, do you
remember things like hyper-threading or turbo boost? Why haven't
those dudes been <del>laughed out of the building</del> politely
asked to design the hardware so that it plays nice with the existing
kernel without any need to introduce anything new?

But why am I even explaining these obvious things?

> If you *really* want to react to power events, there is no reason a userspace
> program can't change max/min_frequency of the ondemand governor, or even
> switch between ondemand and performance as the power situation allows; it could
> be either a daemon or a oneshot script called from udev(?), if changes are only
> required on plugging/unplugging of power source. In fact I think there should
> be something like that already (designed for laptops).

AFAIK on the x86 laptops at least part of this functionality is handled
by the BIOS and ACPI. Which makes them a little bit different from ARM
hardware.

In any case, I don't like the idea of forcing the userland to take
special care of sunxi specific power management when this can be better
done in the kernel. How the hell are you going to package it for many
different linux distributions?

[Patrick Wood]

An on a different note, not to make things more difficult: the cpufrequtils package from ubuntu (at least this version: cpufrequtils_008-1_armhf.deb) installs an init.d startup file called cpufrequtils that sets the default governor to... you guessed it -- ondemand.  This is easily overridden by putting

GOVERNOR=performance

in the file /etc/default/cpufrequtils, but requires people to know that this is needed.

[Siarhei Siamashka]

On Sun, 5 Jan 2014 20:05:38 -0800 (PST)
Patrick Wood <patric...@gmail.com> wrote:

> An on a different note, not to make things more difficult: the cpufrequtils
> package from ubuntu (at least this version: cpufrequtils_008-1_armhf.deb)
> installs an init.d startup file called cpufrequtils that sets the default
> governor to... you guessed it -- ondemand. This is easily overridden by
> putting
>
> GOVERNOR=performance
>
> in the file /etc/default/cpufrequtils, but requires people to know that
> this is needed.

Thanks for bringing it up. This might be actually a good justification
for not enabling the "ondemand" governor even as one of the secondary
non-default options in defconfigs. This way a user would need to put
more efforts to shoot himself in the foot. But communicating the issue
to the cpufrequtils packager might be a good idea too.

And for the people who prefer the "ondemand" governor. Please tell
us something about your use case and how "ondemand" helps there.

[Siarhei Siamashka]

On Sun, 5 Jan 2014 16:01:20 -0800 (PST)

Patrick Wood <patric...@gmail.com> wrote:

> 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

Well, my question was more about the "interactive" governor and
https://github.com/linux-sunxi/linux-sunxi/commit/47d3b18876571835
does not say anything about it. And it also does not look like any
power consumption measurements or the response time benchmarks had
been made at that time. It was only assumed that 408MHz should be a
better compromise, but not really verified.

> 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.

Yes, the default settings of "ondemand" are just horrible. I think
everyone has observed this on sunxi hardware and wholeheartedly agrees.

About the "interactive" governor. Appears that it originates from
Android and some attempts have been made to push it to the mainline
kernel. The start of the thread is here:
https://lkml.org/lkml/2012/2/7/479
The patch for the interactive governor itself is here:
https://lkml.org/lkml/2012/2/7/483

And here are some interesting responses:

https://lkml.org/lkml/2012/2/7/504 ("Argh, no.. cpufreq so sucks
rocks. Can we please just scrap it and write an entirely new
infrastructure that is much more connected to the scheduler and do
away with this stupid need to set P-states from a schedulable context.")

https://lkml.org/lkml/2012/2/8/306 ("I think the biggest mistake
we ever made with cpufreq was making it so configurable. If we
redesign it, just say no to plugin governors, and yes to a lot fewer
sysfs knobs.")

https://lkml.org/lkml/2012/2/10/687 ("IMHO, I think the problem
with CPUfreq and its dynamic governors today is that they do a timer
based sampling of the CPU load instead of getting some hints from
the scheduler when the scheduler knows that the load average is
quite high.")

But I actually suggest to read the whole discussion thread on lkml.

Basically, it looks like everyone agrees there that cpufreq is
poorly designed. The "interactive" governor from Android just tries
to do a better job than "ondemand" on this broken foundation.

This seems to debunk the assumptions made by Dimitar Gamishev
and Roman Mamedov, suggesting that the "ondemand" governor is
a great proper thing from the mainline kernel and that it's the
end users who just must configure it right ;)


So now here is a new short term plan:
* Set the "performance" governor in defconfigs by default
* Also offer "interactive" (for battery users) and "userspace" (for
experimenting and benchmarking) as secondary options.
* The "ondemand" governor should be disabled in defconfigs, because
otherwise the init scripts from some distributions might manage
to activate it by mistake and destroy the performance.

Are there any better suggestions?

[Roman Mamedov]

On Mon, 6 Jan 2014 18:37:05 +0200
Siarhei Siamashka <siarhei....@gmail.com> wrote:

> https://lkml.org/lkml/2012/2/8/306 ("I think the biggest mistake
> we ever made with cpufreq was making it so configurable. If we
> redesign it, just say no to plugin governors, and yes to a lot fewer
> sysfs knobs.")

I wonder if that guy also does some GNOME 3 development as a hobby :)

--
With respect,
Roman

[Olliver Schinagl]

Hey Siarhei,

On 01-01-14 23:54, Siarhei Siamashka wrote:
<snip>

I ran some performance tests of my own, so here's the numbers.

I'm using Hansg's Fedora 19 image from a class 4 MMC on the cubietruck.
I did modify script.bin to change usbc to port_type 1 and detect_type 0
to drop the loadavg to 0 from 1.

Also I changed the display output to mode 4, 1280x1024 on VGA.

I have connected, ethernet, VGA, USB keyboard, USB mouse and uart cable.
I did run tests with and without the uart cable, but didn't really
notice a huge change.

Running cpuburn-a7 which burns both cores, from the xfce desktop in a
terminal I get the following:

userfreq: 0.47 amps @ 5.15 V (60 MHz)
userfreq: 0.49 amps @ 5.15 V (408 MHz)
userfreq: 0.65 amps @ 5.15 V (600 MHz)
ondemand: 0.90 amps @ 5.15 V (912 MHz)
performance: 0.90 amps @ 5.15 V (912 MHz)


having just the idle desktop open with 1 terminal yields the following:

ondemand: 0.37 amps @ 5.15 V (60 MHz)
userfreq: 0.37 amps @ 5.15 V (132 MHz)
userfreq: 0.37 amps @ 5.15 V (204 MHz)
userfreq: 0.38 amps @ 5.15 V (408 MHz)
userfreq: 0.39 amps @ 5.15 V (600 MHz)
userfreq: 0.40 amps @ 5.15 V (816 MHz)
performance: 0.39 - 0.45 amps @ 5.15 V (912 MHz) (Yes it was fluctuating
that much)

Now, the same tests idle without USB keyboard/mouse connected, as they
naturally increase power draw considerably.

ondemand: 0.34 amps @ 5.15 V (60 MHz)
userfreq: 0.34 amps @ 5.15 V (132 MHz)
userfreq: 0.35 amps @ 5.15 V (204 MHz)
userfreq: 0.35 amps @ 5.15 V (408 MHz)
userfreq: 0.35 amps @ 5.15 V (600 MHz)
userfreq: 0.36 amps @ 5.15 V (816 MHz)
performance: 0.36 - 0.41 amps @ 5.15 V (912 MHz)

Btw, i did mention ondemand, userfreq and performance settings here, but
i noticed (as expected) no differences here)

Power did fluctuate to 5.13 occasionally, but the avg probably was just
a little above 5.14 i estimate. USB keyboard/mouse was the same change
as with IDLE loads.

I think its pretty fair to conclude, that power draw when IDLE is almost
the same on min freq and max freq. During load it does matter but why
would you run your CPU lower during load? So for the default governor,
performance without a doubt and if you insist on ondemand, 408 for the
minimum is quite alright.

Interesting result to say the least.

Oliver

[Robin Humble]

On Thu, Jan 09, 2014 at 03:47:22PM +0100, Olliver Schinagl wrote:
>I think its pretty fair to conclude, that power draw when IDLE is
>almost the same on min freq and max freq. During load it does matter
>but why would you run your CPU lower during load? So for the default
>governor, performance without a doubt and if you insist on ondemand,
>408 for the minimum is quite alright.
>
>Interesting result to say the least.

a few years ago I measured the same thing on intel server chips
(nehalem and older xeons in HPC clusters).
server idle power @ 200Mhz == server idle power @ 3GHz.

likely internal blocks in the chip are smart and clock themselves
down/off when they detect they're idle. on the intel chips (and it
looks like on allwinner too) this happens regardless of any OS cpufreq
settings.

in reality (which isn't a case commonly covered by benchmarks :-) the
main effect of lower MHz cpu governors is probably to make apps that
are spinwaiting for i/o or network use less power. unfortunately lower
MHz can also mean higher latency from the i/o and network subsystems,
so it may not be a win. my conclusion (in the HPC workload case) was
that max MHz was clearly the best choice.

IMHO it's hard to construct cases where max MHz is wrong... (+/- chip
might melt)

BTW, intel have gradually been improving the whole-server idle/max
power usage ratio - largely by moving functionality off the board and
into the cpu die - SoC style. the ratio used to be about 1/2 on Core2
era servers, was about 1/3 on Nehalem, and I'd guess it is now probably
closer to 1/4.
from your numbers it looks like allwinner/cubie2 is 0.34/.9 ~= 0.38
which isn't too bad, but isn't great either.

cheers,
robin

[Siarhei Siamashka]

On Tue, 17 Dec 2013 10:15:56 -0800 (PST)
Димитър Гамишев <gami...@gmail.com> wrote:

> On Monday, December 16, 2013 6:44:03 AM UTC+2, Siarhei Siamashka wrote:
> > There is just one thing I'm really worried about. The 16-bit
> > memory interface is a major performance risk factor. I wonder
> > how LIME performs on memory intensive workloads (such as
> > graphics) when compared with, for example, Cubieboard.

Now that I got A10-OLinuXino-Lime device (thanks Tsvetan!), I could
run some OpenGL ES benchmarks in X11 with Mali r3p0 binary drivers.
Mele A2000 and Cubieboard1 devices are used for comparison because
they have 32-bit memory interface, but different memory clock speed.
The default memory timings configuration for LIME is using dram_cas=9
set in dram_a10_olinuxino_l.c in u-boot, but I also tried the
cubieboard memory timings (dram_cas=6) as an extra test just to
see how it may affect performance.

== The final score for glmark2-es2 2012.12 (test in 800x600 window) ==

LIME (CAS=9) - 480MHz dram clock, dram_bus_width=16, dram_cas=9
LIME (CAS=6) - 480MHz dram clock, dram_bus_width=16, dram_cas=6
Mele A2000 - 360MHz dram clock, dram_bus_width=32, dram_cas=6
Cubieboard1 - 480MHz dram clock, dram_bus_width=32, dram_cas=6

In all cases ARM Cortex-A8 in Allwinner A10 is clocked at 1008MHz
(performance cpufreq governor) and Mali400 MP1 is clocked at 320MHz.
Desktop color depth is 32bpp.

| 1280x720p50 | 1280x720p60 | 1920x1080p50 | 1920x1080p60
-------------+-------------+-------------+--------------+--------------
LIME (CAS=9) | 85 | 75 | 46 (**) | 41 (**)
LIME (CAS=6) | 100 | 91 | 56 (**) | 48 (**)
Mele A2000 | 151 | 148 | 140 (**) | 136 (**)
Cubieboard1 | 166 | 166 | 161 (*) | 157 (*)
-------------+-------------+-------------+--------------+--------------

(*) minor occasional glitches on screen
(**) severe screen shaking effect is observed

Note that the window size is the exactly same in all tests. Only the
screen resolution is different, and this only affects how much of the
memory bandwidth is drained by maintaining the screen refresh.

With 16-bit memory bus width, the 3D graphics performance becomes very
bad very quickly when the screen resolution and refresh rate increase.
Trying to use the 50Hz monitor refresh rate is more important than
ever, because it both increases the performance and also rendering
perfect tear-free 50Hz animation is somewhat less demanding than
60Hz animation.

The performance of hardware accelerated video decoding using CedarX
with 1080p monitor is going to be really interesting too. And common
sense dictates that it is very important not to waste memory bandwidth
unnecessarily.

BTW, for 32-bit memory bus width, Mali performance does not seem to
be affected that much by the screen resolution and refresh rate
increase. But software graphics rendering done on the CPU (or any
other memory intensive activity) is still taking a performance hit
even with the 32-bit memory bus:
http://ssvb.github.io/2013/06/27/fullhd-x11-desktop-performance-of-the-allwinner-a10.html
The X11 desktop performance on LIME is going to be challenging
at high screen resolutions too, unless the desktop color depth
is reduced to 16bpp.

The memory timings with dram_cas=9 also affect performance.
While dram_cas=6 might be considered as an unsafe choice for
480MHz, it would be really great if we could use some better
safe/fast settings.

I was not going to sugar-coat anything here. And I understand that
using the 16-bit memory bus width was a side effect of extreme cost
reduction. The primary LIME competitors are likely not high end
ARM devices, but Raspberry Pi and low cost microcontrollers.
The whole point of my e-mail is just that clearly outperforming
them may need some tuning on the software side for better
utilization of the memory bandwidth that is available.

A verification of benchmark results is always welcome. Also for
the people not having a LIME board yet, just taking the u-boot
dram settings from LIME and using them on Cubieboard1 appears
to result in exactly the same memory performance. So Cubieboard1
hardware can be used to simulate the 16-bit memory bus
performance too.

[TsvetanUsunov]

I was not going to sugar-coat anything here. And I understand that
using the 16-bit memory bus width was a side effect of extreme cost
reduction. The primary LIME competitors are likely not high end
ARM devices, but Raspberry Pi and low cost microcontrollers.
The whole point of my e-mail is just that clearly outperforming
them may need some tuning on the software side for better
utilization of the memory bandwidth that is available.

exactly, LIME was build to show/proof that something low cost like RPi/BBB but more powerful could be made with Allwinner chips :-)

LIME2 which we work now with A20 will have 1GB RAM (32 bit width) and Gigabit Ethernet, but it will be not possible to make LIME2 for price similar to LIME, unless hundreds of thousands devices are produced which I do not see realistic the market for small Linux boards already is highly saturated and unless community with the size of RPi is built there will be no such sales. BBB with all efforts and money TI throw in is still 10-20 times smaller in sales.

 

I believe there is a long way to further optimize the running software to utilize the all co-processor power as BBB is also 16 bit data bus, have no idea about RPi databus width but LIME with Cortex-A8 should outperform RPi too with equal databus width

Tsvetan

[Hans de Goede]

Hi,

On 01/15/2014 09:08 AM, TsvetanUsunov wrote:
> I was not going to sugar-coat anything here. And I understand that
> using the 16-bit memory bus width was a side effect of extreme cost
> reduction. The primary LIME competitors are likely not high end
> ARM devices, but Raspberry Pi and low cost microcontrollers.
> The whole point of my e-mail is just that clearly outperforming
> them may need some tuning on the software side for better
> utilization of the memory bandwidth that is available.
>
>
> exactly, LIME was build to show/proof that something low cost like RPi/BBB but more powerful could be made with Allwinner chips :-)
>
> LIME2 which we work now with A20 will have 1GB RAM (32 bit width) and Gigabit Ethernet, but it will be not possible to make LIME2 for price similar to LIME, unless hundreds of thousands devices are produced which I do not see realistic the market for small Linux boards already is highly saturated and unless community with the size of RPi is built there will be no such sales. BBB with all efforts and money TI throw in is still 10-20 times smaller in sales.

I did not know you were working on a LIME2, it sounds really cool.

While showing of the LIME to people at the local hackerspace yesterday
I had an idea for something which would be a great improvement IMHO,
would it be possible to add a mini pci-e connector on the back-side of
the pcb? This could then have sata wired to it for use with m-sata ssd's
and maybe / optionally also one of the usb ports for a 3g modem, or other
mini-pci-e usb card.

I guess people don't want to sacrifice the external sata for this,
so I'm not sure how well this would work wrt reflections if you
just put on both. Maybe use solder jumpers? Anyways just an idea,
I don't know how much cost a mini-pci-e connector would add to the
BOM, but if it is possible it would be really cool, as then one can
have decent storage (often io-speed is a big bottle-neck) inside
the nice and small lime case. And m-sata ssds have come down to the
same pricelevel as regular ssds.

Regards,

Hans

[Siarhei Siamashka]

And a new entry for this table (the details are at the end of my post):

| 1280x720p50 | 1280x720p60 | 1920x1080p50 | 1920x1080p60
-------------+-------------+-------------+--------------+--------------

LIME (CAS=7) | 114 | 110 | 94 | 85

As now we know a lot more about the dram controller in A10/A13/A20,
we can generate exact timings for any dram clock speed. Targeting
480MHz for A10-OLinuXino-Lime would be something like this:

static struct dram_para dram_para = { /* DRAM timings: 7-7-7-17 */
.clock = 480,
.type = 3,
.rank_num = 1,
.density = 4096,
.io_width = 16,
.bus_width = 16,
.cas = 7,
.zq = 0x7b,
.odt_en = 0,
.size = 512,
.tpr0 = 0x30917790,
.tpr1 = 0xa078,
.tpr2 = 0x23200,
.tpr3 = 0x0,
.tpr4 = 0x0,
.tpr5 = 0x0,
.emr1 = 0x4,
.emr2 = 0x8,
.emr3 = 0x0,
};

This has been generated by the a10-dram-timings-calculator.rb script
from https://github.com/ssvb/a10-meminfo

Please note that these settings result in slightly worse performance
than the current CAS6 set of settings, which are configured in
u-boot-sunxi for A10-OLinuXino-Lime. But they are not violating the
timing specs of the used DDR3 memory chips anymore. These new CAS7
settings are still faster than the typical CAS9 settings used by
u-boot-sunxi for the other boards.

However having the following u-boot patch has *critical* importance for
the proper FullHD desktop resolution support on A10-OLinuXino-Lime:
https://github.com/linux-sunxi/u-boot-sunxi/commit/4e1532df5ebc6e0d
Using DEFE instead of DEBE and fixing the arbitration of the DEFE
port in the DRAM controller provides a huge graphics performance
boost. And it also resolves all the HDMI signal disruption glitches.

A quickly hacked test branch, enforcing the use of DEFE scaled
layers in the xf86-video-fbturbo driver:
https://github.com/ssvb/xf86-video-fbturbo/tree/20140504-test-enforced-defe-scaler
The drawback is that relying only on DEFE, we are down to just 2
disp layers instead of 4. This causes a lot of practical issues
with multi-monitor support and libvdpau-sunxi compatibility. Unless
we can also find some magic fix for DEBE, some special layers
allocation logic may be necessary to decide whether the DEBE
layers can be safely used for each particular configuration
(depending on the SoC type, the dram clock speed, bus width, the
screen resolution, color depth and refresh rate). All the joy of
having a http://en.wikipedia.org/wiki/Leaky_abstraction :-(