Re: XO memory size

2009-03-02 Thread Derek Zhou
On Thursday 26 February 2009 05:09:27 pm James Cameron wrote:
  Something is wrong with my olpc in either the xserver or hardware. For
  other non-drawing tasks its speed seems to be reasonable.
 
 Yes, something is wrong.  Have you another XO you can test?
 
Now I narrowed down my X related slowdown to one culprit, and I still cannot 
believe it:
It's not different versions of debxo or hardware or nand vs usb or jffs2 vs 
ext3,
It is the window manager I am using: windowMaker.
I've been using windowMaker together with rxvt since forever and both softwares
are very stable (to the point of stagnant) and why oh why windowMaker, rxvt and
olpc make such an unholy threesome.

Derek  

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-03-02 Thread James Cameron
On Mon, Mar 02, 2009 at 02:01:41AM -0800, Derek Zhou wrote:
 Now I narrowed down my X related slowdown to one culprit, and I still cannot 
 believe it:
 It's not different versions of debxo or hardware or nand vs usb or jffs2 vs 
 ext3,
 It is the window manager I am using: windowMaker.
 I've been using windowMaker together with rxvt since forever and both 
 softwares
 are very stable (to the point of stagnant) and why oh why windowMaker, rxvt 
 and
 olpc make such an unholy threesome.

Interesting.  It is probably doing something wrong, or something that is
a particularly bad move on XO.

I use WindowMaker all the time on my main desktop, but because something
went wrong some time ago I held the package version at 0.92.0-5.3.  The
version currently available in Squeeze is 0.92.0-8

So, trying wmaker 0.92.0-8 in rxvt using debxo 0.5, I see entirely
different results to rxvt under kwin: 14.422s, 14.366s, 14.392s.
[80x24]

And for a fully maximised rxvt, 25 seconds.  That's very similar to your
numbers.

You've clearly narrowed the field.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-03-01 Thread James Cameron
On Sat, Feb 28, 2009 at 11:05:51PM -0800, Derek Zhou wrote:
 On Saturday 28 February 2009 05:51:40 pm James Cameron wrote:
   3, every once in a while (10 mins or so) there is a message in console 
   like: 
   JFFS2 warning: jffs2_sum_write_sumnode: Not enough space for summary, 
   padsize=-60
  
  That matches a known problem.  The JFFS2 filesystem is in a suboptimal
  state.
 Can you tell me more about this.

Yes, but I don't know much more about it.  The suboptimal state seems be
triggered by extensive use of the filesystem, or filling to capacity.
It is so easy to fix (by reflashing) that I've never seriously
investigated it.  To investigate it I would look for changes to JFFS2
kernel code since debxo-0.4, and check for trac tickets on
dev.laptop.org, and possibly analyse the filesystem somehow.  I'm not
experienced in that, and I don't have the filesystem available to me.

 I installed debxo-0.5 on a usb drive and rxvt
 speed seems normal. So it comes down to either the jffs2 or the internal nand.

To test for that, use the debxo 0.5 booted from USB to test reading the
NAND flash without using the filesystem.  I haven't derived such a test
yet, maybe you have some ideas.  If you get a block read performance
that is consistent with other units, then you can exclude the NAND flash
as cause, leaving only the JFFS2 filesystem as the cause.

 I thought jffs2 on raw nand is supposed to be better than non-flash
 aware fs on a cheap usb stick...

I don't know about that.  Better in what way?

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-28 Thread James Cameron
On Thu, Feb 26, 2009 at 07:24:19PM -0800, da...@lang.hm wrote:
 On Fri, 27 Feb 2009, James Cameron wrote:

 On Thu, Feb 26, 2009 at 12:50:58PM -0800, da...@lang.hm wrote:
 since the effect seems to be related to the amount of text on the screen
 at any one time that needs to be scrolled, it may be that the larger
 fonts of debxo 0.5 are preventing you from seeing the effect.

 Good point, but no, rxvt is being used with a bitmap font, and it is the
 same size on debxo 0.4 and 0.5, using a side by side comparison of two
 XOs.  An 80x24 character cell window takes up the same physical space on
 the panel.  xwininfo on both shows 979 x 580 pixels.

 but what was reported was that an 80x24 window didn't see much 
 difference, but a window showing more characters took significantly 
 longer.

Yes, that's expected ... when there is a shortage of CPU cycles, a
larger window would cause more work, and would appear slower.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-28 Thread James Cameron
On Thu, Feb 26, 2009 at 09:48:22PM -0800, Derek Zhou wrote:
 On Thursday 26 February 2009 05:09:27 pm James Cameron wrote:
   Something is wrong with my olpc in either the xserver or hardware. For
   other non-drawing tasks its speed seems to be reasonable.
  
  Yes, something is wrong.  Have you another XO you can test?
  
 I installed latest 
 xserver-xorg-video-geode_2.11.0-0.3_i386.deb
 from:
 http://lunge.mit.edu/~dilinger/debxo-0.5/
 It got slightly faster, like 10% but the situation is still roughly
 the same. I don't think it is the JFFS2 as top shows most of the cpu
 time is spent in the Xorg process. 

Only some of the JFFS2 problems manifest as CPU time spent in kernel
threads.

 A couple of suspicious things:
 1, /proc/meminfo shows MemTotal: 221776KB Can someone confirm whether
 this is normal?

Looks normal to me.

 2, Console (without X) is also quite slow. I know fbcon can be slow
 and unlike x terminal it is synchronous so it has to draw every char
 literally but still I didn't expect it to be this slow.

That excludes X as the primary cause.  It suggests a shortage of CPU
cycles.

 3, every once in a while (10 mins or so) there is a message in console like: 
 JFFS2 warning: jffs2_sum_write_sumnode: Not enough space for summary, 
 padsize=-60

That matches a known problem.  The JFFS2 filesystem is in a suboptimal
state.

 4, dmesg is flooded with thing like:
 [ 1950.351880] olpc-ec:  received 0xe3
 [ 1950.351880] olpc-ec:  received 0xc2
 [ 1950.352019] olpc-ec:  running cmd 0x15
 [ 1950.353035] olpc-ec:  received 0x41

That is probably unrelated, and the fragment looks normal.  The EC does
not use the JFFS2.

 I could also reflesh debxo0.5 or latest joyride build to try. Is there
 anyway I can build a set of dat/img files from my current nand so I
 can come back easily?

Not at the moment.  This requires save-nand support for partitioned
NAND, and I checked with Mitch a few days ago on IRC and he said it was
not yet available.

I *think* a save-nand to USB disk will work, but I don't know if a
copy-nand from it will work.  I'll give it a go.

If you wish to save your configuration changes, take a copy of the whole
of /etc, and dpkg --get-selections, and anything else you may have
changed.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-28 Thread James Cameron
On Sun, Mar 01, 2009 at 12:51:40PM +1100, James Cameron wrote:
 I *think* a save-nand to USB disk will work, but I don't know if a
 copy-nand from it will work.  I'll give it a go.

Verified.  save-nand succeeds.  copy-nand results in an unbootable
system, on power-up OFW prompts with ok, and if you type boot you get
Unrecognized program format (sic).

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-28 Thread Derek Zhou
On Saturday 28 February 2009 05:51:40 pm James Cameron wrote:
  3, every once in a while (10 mins or so) there is a message in console 
  like: 
  JFFS2 warning: jffs2_sum_write_sumnode: Not enough space for summary, 
  padsize=-60
 
 That matches a known problem.  The JFFS2 filesystem is in a suboptimal
 state.
Can you tell me more about this. I installed debxo-0.5 on a usb drive and rxvt
speed seems normal. So it comes down to either the jffs2 or the internal nand.
I thought jffs2 on raw nand is supposed to be better than non-flash aware fs
on a cheap usb stick...
Derek  
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread James Cameron
After generating an xorg.conf using Xorg -configure, restarting X,
results were 3.696s, 3.700s, 3.607s.

After adding 'Option FBSize 8388608', restarting X, results were
3.673s, 3.636s, 3.658s.

The generated xorg.conf is attached.

I'm not seeing what you're seeing.  Perhaps there is something else
affecting your system.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
Section ServerLayout
Identifier X.org Configured
Screen  0  Screen0 0 0
InputDeviceMouse0 CorePointer
InputDeviceKeyboard0 CoreKeyboard
EndSection

Section Files
RgbPath  /etc/X11/rgb
ModulePath   /usr/lib/xorg/modules
FontPath /usr/share/fonts/X11/misc
FontPath /usr/share/fonts/X11/cyrillic
FontPath /usr/share/fonts/X11/100dpi/:unscaled
FontPath /usr/share/fonts/X11/75dpi/:unscaled
FontPath /usr/share/fonts/X11/Type1
FontPath /usr/share/fonts/X11/100dpi
FontPath /usr/share/fonts/X11/75dpi
FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection

Section Module
Load  glx
Load  record
Load  GLcore
Load  extmod
Load  dbe
Load  dri
Load  xtrap
EndSection

Section InputDevice
Identifier  Keyboard0
Driver  kbd
EndSection

Section InputDevice
Identifier  Mouse0
Driver  mouse
Option  Protocol auto
Option  Device /dev/input/mice
Option  ZAxisMapping 4 5 6 7
EndSection

Section Monitor
Identifier   Monitor0
VendorName   Monitor Vendor
ModelNameMonitor Model
EndSection

Section Device
### Available Driver options are:-
### Values: i: integer, f: float, bool: True/False,
### string: String, freq: f Hz/kHz/MHz
### [arg]: arg optional
Identifier  Card0
Driver  geode
VendorName  Advanced Micro Devices [AMD]
BoardName   Geode LX Video
BusID   PCI:0:1:1
Option FBSize 8388608
EndSection

Section Screen
Identifier Screen0
Device Card0
MonitorMonitor0
SubSection Display
Viewport   0 0
Depth 1
EndSubSection
SubSection Display
Viewport   0 0
Depth 4
EndSubSection
SubSection Display
Viewport   0 0
Depth 8
EndSubSection
SubSection Display
Viewport   0 0
Depth 15
EndSubSection
SubSection Display
Viewport   0 0
Depth 16
EndSubSection
SubSection Display
Viewport   0 0
Depth 24
EndSubSection
EndSection

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread Derek Zhou
On Wednesday 25 February 2009 11:52:11 pm James Cameron wrote:
 debxo 0.5 KDE variant booted from USB, installed rxvt, started rxvt -fn
 12x24, maximised, took a sample log (dmesg) which was 523 lines,
 appended it many times to generate a file 7322 lines long, then used:
 
   time cat file
 
 Results were 3.569s, 3.569s, 3.569s.  Very predictable, so I tried with
 
   time cat file file
 
 Results were 7.147s, 7.151s, 7.183s.
 
 I'm certainly not seeing 15 seconds or 45 seconds.
 
 Do you have any rxvt customisations?
 
Not much, just a different font and reverse video. I used straight rxvt -fn 
12x24 just like you have, only to find it is slightly slower, now about 16 
seconds. I think the problem is not in rxvt but in xserver. My olpc is debxo 
0.4 installed in internal flash. Is there a xserver dpkg from debxo 0.5 file I 
can grab to try out? 
Derek 

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread Derek Zhou
On Thursday 26 February 2009 12:02:46 am James Cameron wrote:
 After generating an xorg.conf using Xorg -configure, restarting X,
 results were 3.696s, 3.700s, 3.607s.
 
 After adding 'Option FBSize 8388608', restarting X, results were
 3.673s, 3.636s, 3.658s.
 
 The generated xorg.conf is attached.
 
 I'm not seeing what you're seeing.  Perhaps there is something else
 affecting your system.
 

Agreed. Now instead of a logfile which is different from computer to computer, 
now I do a:

time gunzip -c /usr/share/man/man1/perlfunc.1.gz ( a nice long manpage, 7958 
lines 357544 bytes )

in a rxvt -fn 12x24, I have 
38.772s with FBSize 8M, rxvt size 80x24
59.500s with FBSize 8M, rxvt size 98x36
33.042s no FBSize limit, rxvt size 80x24 (actually faster than with FBSize 
limit)
1m31.104s no FBSize limit, rxvt size 98x36 (pathetically slow)
Doing anything that output lots of text is painful. 
For comparison, my other laptop (also debian lenny, not a fast one by any mean, 
AMD 1.6G single processor integrated ATI graphic) has:
1.050s rxvt size 80x24
1.306s rxvt size 105x33
ssh into olpc:
0.129s rxvt size 80x24
0.125s rxvt size 105x33
So the non-drawing part cpu time on the olpc is tiny. 
Something is wrong with my olpc in either the xserver or hardware. For other 
non-drawing tasks its speed seems to be reasonable.
Derek

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread Tomeu Vizoso
On Thu, Feb 26, 2009 at 09:19, Derek Zhou agonyz...@comcast.net wrote:
 On Wednesday 25 February 2009 11:52:11 pm James Cameron wrote:
 debxo 0.5 KDE variant booted from USB, installed rxvt, started rxvt -fn
 12x24, maximised, took a sample log (dmesg) which was 523 lines,
 appended it many times to generate a file 7322 lines long, then used:

       time cat file

 Results were 3.569s, 3.569s, 3.569s.  Very predictable, so I tried with

       time cat file file

 Results were 7.147s, 7.151s, 7.183s.

 I'm certainly not seeing 15 seconds or 45 seconds.

 Do you have any rxvt customisations?

 Not much, just a different font and reverse video. I used straight rxvt -fn 
 12x24 just like you have, only to find it is slightly slower, now about 16 
 seconds. I think the problem is not in rxvt but in xserver. My olpc is debxo 
 0.4 installed in internal flash. Is there a xserver dpkg from debxo 0.5 file 
 I can grab to try out?

As a wild guess, may be related to jfffs2? It may be garbage
collecting at that time or some other stuff.

I have seen that measuring performance on the XO is quite daunting and
time consuming because the state of the nand flash can radically
affect observations. Also making less useful user reports of slowness
because you can never be sure if jfffs2 house-keeping or
autocompression was stealing precious cpu cycles to the user.

Regards,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread david
On Thu, 26 Feb 2009, Derek Zhou wrote:

 On Thursday 26 February 2009 12:02:46 am James Cameron wrote:
 After generating an xorg.conf using Xorg -configure, restarting X,
 results were 3.696s, 3.700s, 3.607s.

 After adding 'Option FBSize 8388608', restarting X, results were
 3.673s, 3.636s, 3.658s.

 The generated xorg.conf is attached.

 I'm not seeing what you're seeing.  Perhaps there is something else
 affecting your system.

since the effect seems to be related to the amount of text on the screen 
at any one time that needs to be scrolled, it may be that the larger fonts 
of debxo 0.5 are preventing you from seeing the effect.

David Lang


 Agreed. Now instead of a logfile which is different from computer to 
 computer, now I do a:

 time gunzip -c /usr/share/man/man1/perlfunc.1.gz ( a nice long manpage, 7958 
 lines 357544 bytes )

 in a rxvt -fn 12x24, I have
 38.772s with FBSize 8M, rxvt size 80x24
 59.500s with FBSize 8M, rxvt size 98x36
 33.042s no FBSize limit, rxvt size 80x24 (actually faster than with FBSize 
 limit)
 1m31.104s no FBSize limit, rxvt size 98x36 (pathetically slow)
 Doing anything that output lots of text is painful.
 For comparison, my other laptop (also debian lenny, not a fast one by any 
 mean, AMD 1.6G single processor integrated ATI graphic) has:
 1.050s rxvt size 80x24
 1.306s rxvt size 105x33
 ssh into olpc:
 0.129s rxvt size 80x24
 0.125s rxvt size 105x33
 So the non-drawing part cpu time on the olpc is tiny.
 Something is wrong with my olpc in either the xserver or hardware. For other 
 non-drawing tasks its speed seems to be reasonable.
 Derek

 ___
 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 memory size

2009-02-26 Thread James Cameron
On Thu, Feb 26, 2009 at 01:16:24AM -0800, Derek Zhou wrote:
 On Thursday 26 February 2009 12:02:46 am James Cameron wrote:
  
  I'm not seeing what you're seeing.  Perhaps there is something else
  affecting your system.
  
 
 Agreed. Now instead of a logfile which is different from computer to
 computer, now I do a:
 
 time gunzip -c /usr/share/man/man1/perlfunc.1.gz
 ( a nice long manpage, 7958 lines 357544 bytes )

The file /usr/share/man/man1/perlfunc.1.gz is from package perl-doc,
version 5.10.0-19 in Debian Lenny.

04f8da39cd0d2c290f762d2a47c7bf2c  /usr/share/man/man1/perlfunc.1.gz
357544 bytes
7958 lines

Those numbers look the same, so we're working with identical test data now.

Installed debxo 0.4 GNOME variant on jffs2.

http://lunge.mit.edu/~dilinger/debxo-0.4/images/jffs2/gnome.{img,dat}
ae9463081688155e550b99a7e87e01a8  gnome.dat
882748504c2800bf4e82cac33e5b7bfd  gnome.img

Installed rxvt and perl-doc.  rxvt package version 1:2.6.4-14 

Started rxvt -fn 12x24, left it size 80x24, tested using this
file, results are:

4.818s, 4.494s, 4.490s.

Maximised rxvt.  Tested again, results are:

4.829s, 4.809s, 4.809s.

This was without xorg.conf creation or changes.

 So the non-drawing part cpu time on the olpc is tiny. 

Yes, my tests over wireless yield 0.131s, 0.134s, 0.138s.  Tests to
/dev/null yield 0.047s.

 Something is wrong with my olpc in either the xserver or hardware. For
 other non-drawing tasks its speed seems to be reasonable.

Yes, something is wrong.  Have you another XO you can test?

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread James Cameron
On Thu, Feb 26, 2009 at 10:18:46AM +0100, Tomeu Vizoso wrote:
 As a wild guess, may be related to jffs2? It may be garbage
 collecting at that time or some other stuff.

Agreed, that is a possibility.  I'm avoiding that by installing afresh,
not filling up the free space, doing nothing else on the unit, and
allowing the boot time garbage collection enough time to complete.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread James Cameron
On Thu, Feb 26, 2009 at 12:50:58PM -0800, da...@lang.hm wrote:
 since the effect seems to be related to the amount of text on the screen  
 at any one time that needs to be scrolled, it may be that the larger 
 fonts of debxo 0.5 are preventing you from seeing the effect.

Good point, but no, rxvt is being used with a bitmap font, and it is the
same size on debxo 0.4 and 0.5, using a side by side comparison of two
XOs.  An 80x24 character cell window takes up the same physical space on
the panel.  xwininfo on both shows 979 x 580 pixels.

Testing now with debxo 0.5 KDE booted from USB: 4.406s, 4.360s, 4.369s
... same as the results from debxo 0.4.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread david
On Fri, 27 Feb 2009, James Cameron wrote:

 On Thu, Feb 26, 2009 at 12:50:58PM -0800, da...@lang.hm wrote:
 since the effect seems to be related to the amount of text on the screen
 at any one time that needs to be scrolled, it may be that the larger
 fonts of debxo 0.5 are preventing you from seeing the effect.

 Good point, but no, rxvt is being used with a bitmap font, and it is the
 same size on debxo 0.4 and 0.5, using a side by side comparison of two
 XOs.  An 80x24 character cell window takes up the same physical space on
 the panel.  xwininfo on both shows 979 x 580 pixels.

but what was reported was that an 80x24 window didn't see much difference, 
but a window showing more characters took significantly longer.

I'm going to have to try and test this on my systems when I get home.

David Lang

 Testing now with debxo 0.5 KDE booted from USB: 4.406s, 4.360s, 4.369s
 ... same as the results from debxo 0.4.


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-26 Thread Derek Zhou
On Thursday 26 February 2009 05:09:27 pm James Cameron wrote:
  Something is wrong with my olpc in either the xserver or hardware. For
  other non-drawing tasks its speed seems to be reasonable.
 
 Yes, something is wrong.  Have you another XO you can test?
 
I installed latest 
xserver-xorg-video-geode_2.11.0-0.3_i386.deb
from:
http://lunge.mit.edu/~dilinger/debxo-0.5/
It got slightly faster, like 10% but the situation is still roughly the same. I 
don't think it is the JFFS2 as top shows most of the cpu time is spent in the 
Xorg process. 
A couple of suspicious things:
1, /proc/meminfo shows MemTotal: 221776KB Can someone confirm whether this is 
normal?
2, Console (without X) is also quite slow. I know fbcon can be slow and unlike 
x terminal it is synchronous so it has to draw every char literally but still I 
didn't expect it to be this slow.  
3, every once in a while (10 mins or so) there is a message in console like: 
JFFS2 warning: jffs2_sum_write_sumnode: Not enough space for summary, 
padsize=-60
4, dmesg is flooded with thing like:
[ 1950.351880] olpc-ec:  received 0xe3
[ 1950.351880] olpc-ec:  received 0xc2
[ 1950.352019] olpc-ec:  running cmd 0x15
[ 1950.353035] olpc-ec:  received 0x41

I could also reflesh debxo0.5 or latest joyride build to try. Is there anyway I 
can build a set of dat/img files from my current nand so I can come back easily?
Derek  
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-25 Thread quozl
On Mon, Feb 23, 2009 at 04:33:59PM -0800, Derek Zhou wrote:
 Another thing is X drawing is very slow; however if I add:
 Option FBSize 8388608
 to xorg.conf, it becomes visibly faster.

I've tried to reproduce this, and failed.  Please give me a copy of your
xorg.conf file.

What I did was install debxo 0.4 gnome.img, then investigate /etc/X11,
only to find that xorg.conf is no longer there in that version.  So I
don't know how you have one, and I don't know what you have in it.

I tried placing just the Option line you specified in an empty
xorg.conf, but X would not start, complaining of syntax error in the
file.

Then I copied an xorg.conf from rsync://updates.laptop.org/build-ubuntu, and
looked through it.

Then I installed the Debian x11-apps package, and did some performance
timings, using time x11perf -time 1 -repeat 1 -all, with different
configurations, to try to reproduce your observation;

1.  debxo 0.4 standard gnome configuration, without xorg.conf file, the
test took 29m 43s,

2.  debxo 0.4 standard gnome configuration, with xorg.conf file as is
from build-ubuntu, the test took 29m 45s,

3.  debxo 0.4 standard gnome configuration, with the above xorg.conf
file, with your Option line added to the Driver section, the test took
29m 47s.

 Why is limiting the video ram to half the size make it faster? 

It doesn't.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-25 Thread Derek Zhou
On Wednesday 25 February 2009 02:11:08 am qu...@laptop.org wrote:
 I tried placing just the Option line you specified in an empty
 xorg.conf, but X would not start, complaining of syntax error in the
 file.
You have to make valid xorg.conf file and add it to the Device section. The 
easiest way to get a valid xorg.conf is:
Xorg -configure
 
 Then I copied an xorg.conf from rsync://updates.laptop.org/build-ubuntu, and
 looked through it.
 
 Then I installed the Debian x11-apps package, and did some performance
 timings, using time x11perf -time 1 -repeat 1 -all, with different
 configurations, to try to reproduce your observation;
 
 1.  debxo 0.4 standard gnome configuration, without xorg.conf file, the
 test took 29m 43s,
 
 2.  debxo 0.4 standard gnome configuration, with xorg.conf file as is
 from build-ubuntu, the test took 29m 45s,
 
 3.  debxo 0.4 standard gnome configuration, with the above xorg.conf
 file, with your Option line added to the Driver section, the test took
 29m 47s.
x11perf takes a lot of time, can you suggest a shorter benchmark? What I did is 
just cating a 7000 lines (400K bytes) log file in a rxvt window (Maximized to 
full screen with a 12x24 xfont). Without restraining the FBSize, it take 45 
seconds. With the 8M limit, it takes 15 seconds. If I ssh into the olpc from my 
other laptop and cat the same file from a rxvt window, it only takes ~2 
seconds. For this test all rxvt does is drawing some xfont and scrolling, and 
7000 lines is not whole lot. 45 seconds is ridiculously slow; even 15 seconds 
is kind of slow. I don't have another slow computer to compare but it surely 
feel like the slowest terminal I've ever seen (for about 10 years).

By the way, are you seeing 221M total memory too?

Some more information:   
I am using the stock xserver package from debxo 0.4:

xserver-xorg 1:7.3+18
xserver-xorg-video-geode 2.11.0-0.1

here is my xorg.conf: (from Xorg -configure with only minor modification)
Section ServerLayout
Identifier X.org Configured
Screen  0  Screen0 0 0
InputDeviceMouse0 CorePointer
InputDeviceKeyboard0 CoreKeyboard
EndSection

Section Files
RgbPath  /etc/X11/rgb
ModulePath   /usr/lib/xorg/modules
FontPath /usr/share/fonts/X11/misc
FontPath /usr/share/fonts/X11/cyrillic
FontPath /usr/share/fonts/X11/100dpi/:unscaled
FontPath /usr/share/fonts/X11/75dpi/:unscaled
FontPath /usr/share/fonts/X11/Type1
FontPath /usr/share/fonts/X11/100dpi
FontPath /usr/share/fonts/X11/75dpi
FontPath /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType
EndSection

Section Module
Load  glx
Load  GLcore
Load  extmod
Load  xtrap
Load  record
Load  dbe
Load  dri
EndSection

Section InputDevice
Identifier  Keyboard0
Driver  kbd
EndSection

Section InputDevice
Identifier  Mouse0
Driver  mouse
Option  Protocol auto
Option  Device /dev/input/mice
Option  ZAxisMapping 4 5 6 7
EndSection

Section Monitor
Identifier   Monitor0
VendorName   Monitor Vendor
ModelNameMonitor Model
EndSection

ection Device
### Available Driver options are:-  
  
### Values: i: integer, f: float, bool: True/False,   
  
### string: String, freq: f Hz/kHz/MHz
  
### [arg]: arg optional 
  
Identifier  Card0
Driver  geode
### Option  FBSize 8388608  
  
### Option  NoCompression true  
  
VendorName  Advanced Micro Devices [AMD]
BoardName   Geode LX Video
BusID   PCI:0:1:1
EndSection

Section Screen
Identifier Screen0
Device Card0
MonitorMonitor0
SubSection Display
Viewport   0 0
Depth 1
EndSubSection
SubSection Display
Viewport   0 0
Depth 4
EndSubSection
SubSection Display
Viewport   0 0
Depth 8
EndSubSection
SubSection Display
Viewport   0 0
Depth 15
EndSubSection
SubSection Display
Viewport   0 0
Depth 16
EndSubSection
SubSection Display
Viewport   0 0
Depth 24
EndSubSection
EndSection

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-25 Thread Derek Zhou
On Wednesday 25 February 2009 02:11:08 am qu...@laptop.org wrote:
 Then I installed the Debian x11-apps package, and did some performance
 timings, using time x11perf -time 1 -repeat 1 -all, with different
 configurations, to try to reproduce your observation;
By the way, I don't think timing the run time of x11perf is a usable benchmark. 
From the manpage:

By default x11perf automatically calibrates the number of repetitions of each 
test, so  that each  should take approximately the same length of time to run 
across servers of widely differing speeds.

And it looks like x11perf -time 1 -repeat 1 -all just run all the tests (there 
are lots of tests) for roughly one second each.

Derek
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-25 Thread James Cameron
debxo 0.5 KDE variant booted from USB, installed rxvt, started rxvt -fn
12x24, maximised, took a sample log (dmesg) which was 523 lines,
appended it many times to generate a file 7322 lines long, then used:

time cat file

Results were 3.569s, 3.569s, 3.569s.  Very predictable, so I tried with

time cat file file

Results were 7.147s, 7.151s, 7.183s.

I'm certainly not seeing 15 seconds or 45 seconds.

Do you have any rxvt customisations?

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-25 Thread James Cameron
On Wed, Feb 25, 2009 at 11:42:52PM -0800, Derek Zhou wrote:
 I don't think timing the run time of x11perf is a usable benchmark.

Agreed.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-24 Thread Derek Zhou
On Monday 23 February 2009 04:48:52 pm qu...@laptop.org wrote:
 Sounds interesting.  Which version of debxo?
0.4
 Show us the output of /proc/meminfo.
de...@debxo:~$ cat /proc/meminfo 
MemTotal:   221776 kB
MemFree:174732 kB
Buffers: 0 kB
Cached:  19192 kB
SwapCached:  0 kB
Active:  13728 kB
Inactive:10432 kB
SwapTotal:   0 kB
SwapFree:0 kB
Dirty:   0 kB
Writeback:   0 kB
AnonPages:4988 kB
Mapped:   6476 kB
Slab:15064 kB
SReclaimable: 1616 kB
SUnreclaim:  13448 kB
PageTables:660 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:110888 kB
Committed_AS:14196 kB
VmallocTotal:   810956 kB
VmallocUsed: 19696 kB
VmallocChunk:   790904 kB
HugePages_Total: 0
HugePages_Free:  0
HugePages_Rsvd:  0
HugePages_Surp:  0
Hugepagesize: 4096 kB
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


XO memory size

2009-02-23 Thread Derek Zhou
Hi all,
I am running debxo on a XO I got from 2008 G1G1. I just noticed that the memory 
size is only 
221776K according to /proc/meminfo. I know that there is 16M used as video 
memory, so there should be 256M-16M = 240M available to linux, right? I search 
around and see some people has about 237M. What does it should be and what else 
is occupying memory? I am on the latest firmware Q2e32; before that I was 
running Q2e22 and they all report the same. I forgot what I got from the 
original software that bundled with the machine, though.
Another thing is X drawing is very slow; however if I add:
Option FBSize 8388608
to xorg.conf, it becomes visibly faster. Why is limiting the video ram to half 
the size make it faster? 
Thanks in advance
Derek  
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Re: XO memory size

2009-02-23 Thread quozl
Sounds interesting.  Which version of debxo?

Show us the output of /proc/meminfo.

 Another thing is X drawing is very slow; however if I add:
 Option FBSize 8388608
 to xorg.conf, it becomes visibly faster. Why is limiting the video ram to 
 half the size make it faster? 

Good question, I'll try that too on debxo.

-- 
James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel