On Tue, 17 Dec 2013 10:15:56 -0800 (PST)
Димитър Гамишев <[email protected]> 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.
> ~Best
> Dimitar
>
> On Monday, December 16, 2013 6:44:03 AM UTC+2, Siarhei Siamashka wrote:
> >
> > 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
> >
--
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
