Re: XO memory size
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
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
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
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
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
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
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
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
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
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
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
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
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
On Thu, Feb 26, 2009 at 09:19, Derek Zhou 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
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
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
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 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "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" ModelName"Monitor Model" EndSection Section "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " 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" Monitor"Monitor0" 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
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
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
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
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 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "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" ModelName"Monitor Model" EndSection ection "Device" ### Available Driver options are:- ### Values: : integer, : float, : "True"/"False", ### : "String", : " 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" Monitor"Monitor0" 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 __
Re: XO memory size
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
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
Re: XO memory size
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
XO memory size
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
