Re: XO-1(.75)
- Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 8:44 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 10:02:15PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 2:10 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. Yes, it does seem that way. I tried 13.2.0-n on XO-1 recently and felt it was quite slow, but I couldn't be sure it wasn't because my XO-1.75 and XO-4 experience influenced me. What I found interesting in this unmatched comparison was the inconsistency. I don't see any inconsistency though, because the comparison was unmatched to begin with. Variables you changed included overclocking, the CPU, the memory, the internal storage, the touchpad, the kernel, the base operating system, the frame buffer, the X server, the OLPC utilities, and Sugar. All I can draw from the results is that you changed a lot of things and a lot of things were different. But this is exactly the point! When a _lot_ of things are changing and you have two groups of activities one going one way and the other the opposite, you look for the least common denominator that will hopefully point to the problem (this is is a very common approach in multi-variable problems). They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. We wait for someone who seems interested in fixing performance problems on the old hardware. It requires quite a depth of knowledge and a lot of time. It isn't something that we can justify a huge investment in. I would think that the performance of newer hardware may be the one that needs attention but certainly can not prioritize it (unless if XO-1.75 classifies under older by now). Best ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 8:19 AM, James Cameron qu...@laptop.org wrote: On Wed, Jul 03, 2013 at 11:03:17PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 8:44 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 10:02:15PM -0700, Yioryos Asprobounitis wrote: - Original Message - From: James Cameron qu...@laptop.org To: Yioryos Asprobounitis mavrot...@yahoo.com Cc: OLPC Devel devel@lists.laptop.org Sent: Thursday, July 4, 2013 2:10 AM Subject: Re: XO-1(.75) On Wed, Jul 03, 2013 at 02:21:08PM -0700, Yioryos Asprobounitis wrote: I'm using the XO-1.75 a bit more these days and gives me a sense of XO-1 performance wise. So I compared my (500/200 overclocked) XO-1 running F14/os885/Sugar-0.94 to XO-1.75 running F-18/13.2.0-11/Sugar-0.98. Since some general performance work was done between those software versions, the comparison is uninteresting. Compare 13.2.0-11 across XO-1 and XO-1.75, or compare XO-1 across os885 and 13.2.0-11, depending on what you are looking to prove. This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. Yes, it does seem that way. I tried 13.2.0-n on XO-1 recently and felt it was quite slow, but I couldn't be sure it wasn't because my XO-1.75 and XO-4 experience influenced me. What I found interesting in this unmatched comparison was the inconsistency. I don't see any inconsistency though, because the comparison was unmatched to begin with. Variables you changed included overclocking, the CPU, the memory, the internal storage, the touchpad, the kernel, the base operating system, the frame buffer, the X server, the OLPC utilities, and Sugar. All I can draw from the results is that you changed a lot of things and a lot of things were different. But this is exactly the point! When a _lot_ of things are changing and you have two groups of activities one going one way and the other the opposite, you look for the least common denominator that will hopefully point to the problem (this is is a very common approach in multi-variable problems). Oh good, now I understand. They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. We wait for someone who seems interested in fixing performance problems on the old hardware. It requires quite a depth of knowledge and a lot of time. It isn't something that we can justify a huge investment in. I would think that the performance of newer hardware may be the one that needs attention but certainly can not prioritize it (unless if XO-1.75 classifies under older by now). XO-1.75 and XO-4 are current, but XO-1.5 and XO-1 are old. We are certainly interested in any ways to make clear performance improvements on XO-1.75 and XO-4. There is performance work that has been done for the XO-1.75 that is still in the queue to be implemented in the OLPC builds. It is on my list for the summer to get this work cleaned up and published in a repo for developer and end user consumption. The performance gains are due to work done by Matt Turner implementing iWMMXt acceleration in pixman, as well as other libraries that when compiled with this support get some performance boosts. Mostly graphics and multimedia apps will benefit from this tuning. On top of that both the XO-1.75 and XO-4 will get graphics performance boosts when I finish up my graphics driver that allows cached pixmaps to be used. We have to do some graphics rendering and manipulations with the CPU instead of the 2D core and we hit a performance bottleneck with the way pixmaps are allocated for use by the graphics engine. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
This comparison has been done a couple of months ago and is clear that F18/S0.98 taxes the systems considerably. What I found interesting in this unmatched comparison was the inconsistency. They might point to specific stacks in the architecture and/or core OS that may need attention (I originally thought was that activities with an extended non-python component or proportionally less gtk3, fair better on the XO-1.75 - but what do I know ;). Anyway, if the knowledgeable believe there is nothing to it or anything to be done about it,' there goes the comparison. No inconsistency here. Most of the activities you see slower were ported to Gtk3. Tam-tam suit, speak, calculate, turtle art, maze, moon, record were not ported scratch and etoys are not related with Gtk Browse received a lot of care this months. Sadly, while the port to Gtk3 and dynamic bindings promised faster start up time (in theory) that was never true. Dsd found performance problems and pushed changes upstream. and 13.2.0 is better than 13.1.0, but anyway more work is needed. Maybe some work can be done in the activities to improve it. Do you have numbers to share? Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Headphone volume adjustment
On Tue, Jun 25, 2013 at 01:57:28AM -0400, John Watlington wrote:
We have noticed that under Fedora 18 (13.2.0 os10 on XO-4), the
headphone volume can't be adjusted to complete silence.
I've looked into this, and have a tentative patch. I'd like it
reviewed to see if the general direction is good. It works for me.
Once the volume falls below a minimum value the audio is muted.
Now, one would think that the mute bits should work, but they did not;
still had audio in headphones after being sure the mute bits in the
headphone volume register were set. Perhaps the documentation is
wrong. So I've ended up using the enable bits for the headphone
volume section.
Also, since we were exposing the mute bits to the layer above, the
mute control was changed to be virtual, and we manage the register
mute bits within the driver instead of exposing them.
This preserves the function of the mute control at the ALSA level
despite our now fiddling with the bits underneath.
Tested here.
diff --git a/sound/soc/codecs/rt5631.c b/sound/soc/codecs/rt5631.c
index 399e5c4..2b44bea 100644
--- a/sound/soc/codecs/rt5631.c
+++ b/sound/soc/codecs/rt5631.c
@@ -94,7 +94,7 @@ struct rt5631_priv {
int rx_rate;
int bclk_rate;
int dmic_used_flag;
- int spkr_mute; /* saved speaker mute at headphone plug time */
+ int mute; /* user level mute */
int hp; /* headphones are plugged */
};
@@ -348,16 +348,22 @@ static int snd_soc_put_vol_rt5631(struct snd_kcontrol
*kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+ struct rt5631_priv *rt5631 = snd_soc_codec_get_drvdata(codec);
unsigned short val, val2, val_mask;
+ unsigned short mutes = (RT5631_L_MUTE | RT5631_R_MUTE);
int ret;
/* Invert so that 0 means +12dB, 39 means -46.5 dB */
val = 39 - ucontrol-value.integer.value[0];
pr_debug(%s: %d (codec) - %ld (control)\n, __func__,
- val 0x3f, ucontrol-value.integer.value[0]);
+ val, ucontrol-value.integer.value[0]);
val2 = (val 8) | val;
val_mask = 0x3f3f;
+ if (rt5631-mute || rt5631-hp) {
+ val2 |= mutes;
+ val_mask |= mutes;
+ }
ret = snd_soc_update_bits(codec, RT5631_SPK_OUT_VOL, val_mask, val2);
@@ -365,11 +371,19 @@ static int snd_soc_put_vol_rt5631(struct snd_kcontrol
*kcontrol,
/* for the fact that the HP range is -46.5dB (31) to 0dB (0) */
/* We truncate at the low-volume end of the range, so that high */
/* volume settings have distinct steps for both SPK and HP. */
- if (val 31)
- val = 31;
-
- val2 = (val 8) | val;
- val_mask = 0x1f1f;
+ unsigned short en = (RT5631_L_EN | RT5631_R_EN);
+ val_mask = 0x1f1f | en;
+ if (val 31) {
+ val2 = 0x1f1f;
+ } else {
+ val2 = (val 8) | val | en;
+ }
+ if (rt5631-mute) {
+ val2 = ~en;
+ val_mask = ~en;
+ }
+ pr_err(rt5631pv: %x/%x (regs) - %d (codec)\n,
+ val2, val_mask, val);
return snd_soc_update_bits(codec, RT5631_HP_OUT_VOL, val_mask, val2);
}
@@ -379,29 +393,38 @@ static int snd_soc_get_volsw_rt5631(struct snd_kcontrol
*kcontrol,
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct rt5631_priv *rt5631 = snd_soc_codec_get_drvdata(codec);
- int reg;
- unsigned short val;
- reg = rt5631-hp ? RT5631_HP_OUT_VOL : RT5631_SPK_OUT_VOL;
- val = snd_soc_read(codec, reg) (RT5631_L_MUTE | RT5631_R_MUTE);
- ucontrol-value.enumerated.item[0] = val ? 0 : 1;
+ ucontrol-value.enumerated.item[0] = rt5631-mute ? 0 : 1;
pr_debug(%s: %d (control) - (codec)\n, __func__,
ucontrol-value.enumerated.item[0]);
return 0;
}
+static void update_mutes(struct snd_soc_codec *codec, struct rt5631_priv
*rt5631)
+{
+ unsigned short hp_out_vol, spk_out_vol;
+ unsigned short mutes = RT5631_L_MUTE | RT5631_R_MUTE;
+
+ if (!rt5631-hp) {
+ spk_out_vol = rt5631-mute ? mutes : 0;
+ hp_out_vol = mutes;
+ } else {
+ spk_out_vol = mutes;
+ hp_out_vol = rt5631-mute ? mutes : 0;
+ }
+ snd_soc_update_bits(codec, RT5631_HP_OUT_VOL, mutes, hp_out_vol);
+ snd_soc_update_bits(codec, RT5631_SPK_OUT_VOL, mutes, spk_out_vol);
+}
+
static int snd_soc_put_volsw_rt5631(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol)
{
struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
struct rt5631_priv *rt5631 = snd_soc_codec_get_drvdata(codec);
- int reg;
- unsigned short val, val_mask = RT5631_L_MUTE | RT5631_R_MUTE;
- reg = rt5631-hp ?
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:53 AM, Gonzalo Odiard gonz...@laptop.org wrote: No inconsistency here. Most of the activities you see slower were ported to Gtk3. Tam-tam suit, speak, calculate, turtle art, maze, moon, record were not ported scratch and etoys are not related with Gtk Browse received a lot of care this months. Sadly, while the port to Gtk3 and dynamic bindings promised faster start up time (in theory) that was never true. Dsd found performance problems and pushed changes upstream. and 13.2.0 is better than 13.1.0, but anyway more work is needed. Maybe some work can be done in the activities to improve it. Do you have numbers to share? Yes, this is the interesting point in this thread. If you take an old release, on any platforms where we have old releases available, and do a side-by-side comparison with the latest release, we may well have a performance regression. However the possible performance regression is not documented in technical terms. People have mentioned a slowdown in previous threads, but nobody posted any numbers. Last time, a video was posted, but that link is no longer working and I'm not sure if it had numbers in it. Last time it was discussed I did generate numbers myself and then solved the problem. However that discussion was focused around Sugar startup time. This discussion now turns to activity startup time. So, having someone generate activity startup time numbers in a fair test (i.e. same platform, different software versions) would be of value. If there is a performance regression here, we don't have a technical diagnosis that I know of. It seems like some people suspect GTK3/gobject-introspection as the cause, and those may be likely candidates, but I don't think we have real diagnosis supporting that (yet), nor any explanation for why those new technologies might be slower than the old ones. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
Tried the following little script but I can not find a way to get the output of
'time' command to the output.txt file.
Any suggestions?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f 2 -d
'=')
do
echo $x output.txt
echo output.txt
time sugar-launch $x 2 output.txt # 'time -o' does not work neither with
at the end
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME 2 output.txt
done
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 12:48 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: Tried the following little script but I can not find a way to get the output of 'time' command to the output.txt file. Not really sure what you are trying to do here - sugar-launch will not return until the activity exits. I ran a couple of experiments here, with XO-1s running 12.1.0 and 13.2.0. Clock (which is a GTK2 activity on both versions) does start 0.5 - 1 second slower on 13.2.0. On 12.1.0 it starts in 10.5 seconds. That is approx 5% change. Running under perf, the most noticable difference is that X uses 5% of CPU time on 12.1.0, and 10% on 13.2.0. A 5% change. Unfortunately perf doesn't tell me which part of X is eating CPU, apart from the fact that it is not in the kernel. Need to figure out why perf can't be more specific. The risk to this work is that we might fix the 5% X issue and see no noticable difference. But I will try to continue a bit of investigation here next week. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:00 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, 2013-07-04 at 13:57 -0600, Daniel Drake wrote: On Thu, Jul 4, 2013 at 12:48 PM, Yioryos Asprobounitis mavrot...@yahoo.com wrote: Tried the following little script but I can not find a way to get the output of 'time' command to the output.txt file. Not really sure what you are trying to do here - sugar-launch will not return until the activity exits. I ran a couple of experiments here, with XO-1s running 12.1.0 and 13.2.0. Clock (which is a GTK2 activity on both versions) does start 0.5 - 1 second slower on 13.2.0. On 12.1.0 it starts in 10.5 seconds. That is approx 5% change. Running under perf, the most noticable difference is that X uses 5% of CPU time on 12.1.0, and 10% on 13.2.0. A 5% change. Of the total available, would that not be a 100% increase in CPU time used by the process running X? Unfortunately perf doesn't tell me which part of X is eating CPU, apart from the fact that it is not in the kernel. Need to figure out why perf can't be more specific. The risk to this work is that we might fix the 5% X issue and see no noticable difference. But I will try to continue a bit of investigation here next week. Jerry Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
While more manual, you can get the activity startup time
uncommenting the line
export SUGAR_LOGGER_LEVEL=debug
in the file .sugar/debug
Gonzalo
On Thu, Jul 4, 2013 at 3:48 PM, Yioryos Asprobounitis
mavrot...@yahoo.comwrote:
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
Tried the following little script but I can not find a way to get the
output of 'time' command to the output.txt file.
Any suggestions?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f
2 -d '=')
do
echo $x output.txt
echo output.txt
time sugar-launch $x 2 output.txt # 'time -o' does not work neither
with at the end
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME 2 output.txt
done
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel My intention is to get a list of the user and system time that takes to launch the activities. The attachments show the results on XO-1 running os885 and 13.2.0-4 (no overclocking or other mods). It stops at Terminal (ooops) but you get the idea.org.sugarlabs.AbacusActivity org.laptop.WebActivity ./test: line 3: 943 Killed sugar-launch $x 2 /dev/null real0m30.344s user0m20.100s sys 0m0.830s org.laptop.Calculate ./test: line 3: 1011 Killed sugar-launch $x 2 /dev/null real0m30.170s user0m14.610s sys 0m7.830s org.sugarlabs.SimpleGraph ./test: line 3: 1092 Killed sugar-launch $x 2 /dev/null real0m30.175s user0m8.630s sys 0m2.420s org.laptop.Chat ./test: line 3: 1161 Killed sugar-launch $x 2 /dev/null real0m30.166s user0m11.510s sys 0m0.670s tv.alterna.Clock ./test: line 3: 1234 Killed sugar-launch $x 2 /dev/null real0m30.185s user0m7.810s sys 0m0.680s org.laptop.AcousticMeasure ./test: line 3: 1308 Killed sugar-launch $x 2 /dev/null real0m30.414s user0m9.670s sys 0m8.260s org.vpri.EtoysActivity ./test: line 3: 1374 Killed sugar-launch $x 2 /dev/null real0m30.237s user0m10.450s sys 0m2.710s org.eq.FotoToon ./test: line 3: 1403 Killed sugar-launch $x 2 /dev/null real0m30.250s user0m16.510s sys 0m6.600s org.sugarlabs.HelloWorld ./test: line 3: 1467 Killed sugar-launch $x 2 /dev/null real0m30.170s user0m10.780s sys 0m1.080s org.laptop.HelpActivity ./test: line 3: 1524 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m7.800s sys 0m0.460s org.laptop.ImageViewerActivity ./test: line 3: 1599 Killed sugar-launch $x 2 /dev/null real0m30.208s user0m9.750s sys 0m4.490s com.jotaro.ImplodeActivity ./test: line 3: 1689 Killed sugar-launch $x 2 /dev/null real0m30.236s user0m9.070s sys 0m0.680s org.sugarlabs.JournalShare ./test: line 3: 1769 Killed sugar-launch $x 2 /dev/null real0m30.246s user0m9.600s sys 0m0.550s org.laptop.sugar.Jukebox ./test: line 3: 1842 Killed sugar-launch $x 2 /dev/null real0m30.266s user0m9.850s sys 0m1.690s org.laptop.Log ./test: line 3: 1913 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m9.820s sys 0m0.890s vu.lux.olpc.Maze ./test: line 3: 1973 Killed sugar-launch $x 2 /dev/null real0m30.177s user0m9.950s sys 0m0.560s org.laptop.MeasureActivity ./test: line 3: 2046 Killed sugar-launch $x 2 /dev/null real0m30.290s user0m13.100s sys 0m3.730s org.laptop.Memorize ./test: line 3: 2114 Killed sugar-launch $x 2 /dev/null real0m30.528s user0m14.830s sys 0m2.400s com.garycmartin.Moon ./test: line 3: 2216 Killed sugar-launch $x 2 /dev/null real0m30.200s user0m11.080s sys 0m2.410s org.sugarlabs.MusicKeyboard ./test: line 3: 2297 Killed sugar-launch $x 2 /dev/null real0m30.175s user0m8.230s sys 0m0.890s org.laptop.Oficina ./test: line 3: 2369 Killed sugar-launch $x 2 /dev/null real0m30.210s user0m11.290s sys 0m2.040s org.laptop.Pippy ./test: line 3: 2437 Killed sugar-launch $x 2 /dev/null real0m30.191s user0m13.980s sys 0m1.210s org.sugarlabs.PortfolioActivity ./test: line 3: 2519 Killed sugar-launch $x 2 /dev/null real0m30.260s user0m11.710s sys 0m1.340s org.laptop.sugar.ReadActivity ./test: line 3: 2594 Killed sugar-launch $x 2 /dev/null real0m30.204s user0m11.390s sys 0m0.770s org.laptop.RecordActivity ./test: line 3: 2665 Killed sugar-launch $x 2 /dev/null real0m30.190s user0m11.340s sys 0m0.750s com.laptop.Ruler ./test: line 3: 2756 Killed sugar-launch $x 2 /dev/null real0m30.296s user0m9.830s sys 0m2.480s edu.mit.media.ScratchActivity ./test: line 3: 2835 Killed sugar-launch $x 2 /dev/null real0m30.176s user0m9.200s sys 0m0.550s vu.lux.olpc.Speak ./test: line 3: 2910 Killed sugar-launch $x 2 /dev/null real0m30.423s user0m9.270s sys 0m2.110s org.laptop.TamTamEdit ./test: line 3: 2990 Killed sugar-launch $x 2 /dev/null real0m30.218s user0m10.180s sys 0m1.760s org.laptop.TamTamJam ./test: line 3: 3076 Killed
Re: XO-1(.75)
I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key=0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. Gonzalo On Thu, Jul 4, 2013 at 5:38 PM, Yioryos Asprobounitis mavrot...@yahoo.comwrote: The following script appears to work as expected, but is the result valid? That's hard to judge without having an explanation for what you are trying to measure. I can't immediately see your intentions from reading the script. Daniel My intention is to get a list of the user and system time that takes to launch the activities. The attachments show the results on XO-1 running os885 and 13.2.0-4 (no overclocking or other mods). It stops at Terminal (ooops) but you get the idea. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 2:13 PM, Jerry Vonau jvo...@shaw.ca wrote: Of the total available, would that not be a 100% increase in CPU time used by the process running X? What do you mean by the process running X? The parent process of the X process? Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 04, 2013 at 01:00:09PM -0700, Yioryos Asprobounitis wrote:
So, having someone generate activity startup time numbers in a fair
test (i.e. same platform, different software versions) would be of
value.
OK.
The following script appears to work as expected, but is the result valid?
ie does the call through sugar-lunch as well as grep, awk, kill etc add to
the time result?
#!/bin/bash
rm -f output.txt
for x in $(cat Activities/*/activity/activity.info | grep bundle | cut -f 2
-d '=')
do
echo $x output.txt
{ time sugar-launch $x 2/dev/null
sleep 30
ME=$(ps aux | grep $x | grep -v grep | awk '{print $2}')
kill -9 $ME ; } 2 output.txt
echo output.txt
done
Interesting, thanks. An explanation was asked for, so here's one:
This script uses CPU time accounting to measure the time the process
and children spend scheduled on the CPU.
Now on to comment:
This measurement would be fine for minimising the startup CPU time of
the activity, but we know that the CPU time of the X server is as
critical to the situation for many activities.
Measuring only the CPU time doesn't take into account the
wait times due to I/O, such as read and write from internal storage,
audio device opening (which has a depop delay on some platforms), and
possible network delays.
A better measurement to look for is the elapsed time of activity
startup.
This is a most interesting value, but it is difficult to obtain
without changing the activity source so that the point of startup
completion is identified. (That task is made more difficult since
some activities schedule some of their startup _after_ their main
startup.)
--
James Cameron
http://quozl.linux.org.au/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 04, 2013 at 07:16:11PM -0300, Gonzalo Odiard wrote: I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key= 0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Good data, thanks. Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. A few questions to help with interpreting this data: - was this on an XO-1 or XO-1.5? I ask because it would help with comparing against other models. - what memory size? I ask because if memory is scarce, startup time will be increased. - if it is an XO-1.5, what microSD device? I ask because the access time and transfer rate of the card can have a dramatic effect on I/O bound startups, - did you start these activities twice and measure the second startup in order to exclude caching effects, or did you only measure the first startup? - was the system rebooted between each test, or were caches already populated? - if it is an XO-1.5, does the test /switches heat spreader test pass? I ask because if it fails, the CPU may slow momentarily during an activity startup, causing a non-linearity in the test results; longer startups become longer. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. However there was also a change to kernel and Fedora version. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
qu...@laptop.org said: A better measurement to look for is the elapsed time of activity startup. This is a most interesting value, but it is difficult to obtain without changing the activity source so that the point of startup completion is identified. (That task is made more difficult since some activities schedule some of their startup _after_ their main startup.) Would it be worth adding a small chunk of code to Sugar to help this area? I'm thinking of an API to say OK, I'm really started now. so Sugar can log a line of data on how long it took to get started. There should probably be an environment variable to or similar enable that performance logging. -- These are my opinions. I hate spam. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: XO-1(.75)
On Thu, Jul 4, 2013 at 9:55 PM, James Cameron qu...@laptop.org wrote: On Thu, Jul 04, 2013 at 07:16:11PM -0300, Gonzalo Odiard wrote: I did another comparison, between 13.2.0 os11 and os883 (sugar 0.94) You can see the results here: https://docs.google.com/spreadsheet/ccc?key= 0As_jQJX0Me6XdDI2clFpX1FFRHhKMHVFZGkyakdST2cusp=sharing Good data, thanks. Metodology: * Changed SUGAR_LOGGER_DEVEL * The activities were started from the listview, then are new instances * The start up time is the time reported by sugar in the log. A few questions to help with interpreting this data: - was this on an XO-1 or XO-1.5? I ask because it would help with comparing against other models. - what memory size? I ask because if memory is scarce, startup time will be increased. This was with a XO-1 C2 with 256 MB (SN SHC84203538) Is the only XO-1 I have. - did you start these activities twice and measure the second startup in order to exclude caching effects, or did you only measure the first startup? Only run one time every activity - was the system rebooted between each test, or were caches already populated? Didn't rebooted after every activity. The column start up difference, if negative, the time was improved. I added a column to show what activities were ported from Gtk2 to Gtk3. In the case of Read activity, the mechanism is confused, because the old activity opened the ObjectChooser in a new instance. I don't know what happen with Scratch. Some activities had a lot of changes, but other like Distance or Implode not, and looks like the change to Gtk3 add a penalty. However there was also a change to kernel and Fedora version. Yes. And changes in libraries, then is difficult point to any particular place. About how the time is measured, I am using the time printed by jarabe/model/shell.py line 566 The shell monitors the window opened event, and have some logic to detect if is the splash screen or the main window activity. I think is similar to what Hal is proposing. Gonzalo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
