rrolsbe wrote:Since the OLPC booting Puppy Linux uses half of the available SDRAM for the /tmp RAM file system, I was wondering what performance would be like if /tmp was reduced and a zram compressed swap were used in the freed up ram? Since the OLPC only has 256Mb of RAM, is it necessary to use half of the RAM for /tmp (pros/cons)? The xopup-XXX.sfs file is being loaded into RAM when Puppy boots on the OLPC, correct?
http://en.gentoo-wiki.com/wiki/Zram_disks
Anyone tried this or something similar?
Regards, Ron
Since the OLPC booting Puppy Linux uses half of the available SDRAM for the /tmp RAM file system, I was wondering what performance would be like if /tmp was reduced and a zram compressed swap were used in the freed up ram? Since the OLPC only has 256Mb of RAM, is it necessary to use half of the RAM for /tmp (pros/cons)? The xopup-XXX.sfs file is being loaded into RAM when Puppy boots on the OLPC, correct?
http://en.gentoo-wiki.com/wiki/Zram_disks
Anyone tried this or something similar?
Regards, Ron
Puppylinux for the OLPC laptops: XOpup
Re: Body of post not showing up?
Re: Crazy thought reduce /tmp and use a compressed zram swap
rrolsbe wrote:Since the OLPC booting Puppy Linux uses half of the available SDRAM for the /tmp RAM file system, I was wondering what performance would be like if /tmp was reduced and a zram compressed swap were used in the freed up ram? Since the OLPC only has 256Mb of RAM, is it necessary to use half of the RAM for /tmp (pros/cons)? The xopup-XXX.sfs file is being loaded into RAM when Puppy boots on the OLPC, correct?
http://en.gentoo-wiki.com/wiki/Zram_disks
Anyone tried this or something similar?
Regards, Ron
Fixed the url so post would show.
Re: Crazy thought reduce /tmp and use a compressed zram swap
Hi Ron,rrolsbe wrote:Since the OLPC booting Puppy Linux uses half of the available SDRAM for the /tmp RAM file system, I was wondering what performance would be like if /tmp was reduced and a zram compressed swap were used in the freed up ram? Since the OLPC only has 256Mb of RAM, is it necessary to use half of the RAM for /tmp (pros/cons)? The xopup-XXX.sfs file is being loaded into RAM when Puppy boots on the OLPC, correct?
http://en.gentoo-wiki.com/wiki/Zram_disks
Anyone tried this or something similar?
Regards, Ron
you are touching on several issues.
I believe that puppy takes all the available RAM as /tmpfs by default since its running in RAM.
You can stop loading the main sfs in the RAM by adding "pfix=nocopy" to line 116 of /boot/olpc.fth like this
Code: Select all
" console=ttyS0,115200 console=tty0 fbcon=font:SUN12x22 ${PD} pfix=nocopy" expand$ to boot-file
Regarding compcache (zram) requires a new kernel, which I had tried some time ago without obvious benefits or issues over standard swap. It has the standard Space-time tradeoff, so "more" RAM but "slower" RAM. The fact that the XO-1 has a 433-500MHz CPU and DDR1(133/166MHz) RAM, makes the tradeoff even worse.
Given that neither OLPC nor Puppy is using it (eg not tested at all for this setting), I thought is better to pass.
Standard swap on a good SD card I believe is better. Though finding a good SDcard may not be that easy. This article has valuable relevant info and a big list of cards and their characteristics at the end.
It is even better if you have the OS and swap in different devices (eg a USB stick and an SDcard) because you can have more simultaneous read/writes which is the major speed-limiting factor with these devices.
Here, among other things, you can find a HowTo test the performance of your card(s) and the app to do it.
ThanksJames C wrote:Fixed the url so post would show.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
XO1.5 temperature monitor
If you are of the rare few with a wild XO-1.5, here is a tray temperature monitor to check the VIA cpu temperature.
Is based on 01micko's tempicon-0.06 but is lm-sensors independent.
Will NOT work on the XO-1 (unless you want to physically modify registers on the CPU chip )
Is based on 01micko's tempicon-0.06 but is lm-sensors independent.
Will NOT work on the XO-1 (unless you want to physically modify registers on the CPU chip )
- Attachments
-
- tempicon_XO-0.06.pet
- temperature tray monitor for the XO-1.5 only
- (6.94 KiB) Downloaded 819 times
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
OLPC questions
Mavothal
Thanks for the reply to my previous post regarding /tmp and Zram.
I haven't installed and tried the latest 2.2 version of Puppy Linux for the OLPC version 1.0 hardware.
The following is my understanding of how Puppy Linux ,by default, runs on the OLPC 1.0 platform:
1/2 of the RAM is allocated to the /tmp RAM file system.
Since /tmp is NOT used to temporarily store cached flash writes (as it normally is), it could be reduces in size by modifying the initrd.img file?
The pup.sfs file is loaded into RAM (not in /tmp?) which should make application load quicker but takes up limited RAM space. The boot options could be modified (as per your last post) to NOT load the .sfs file but this might make the applications load slower.
The pupsave.2fs/3fs file stores all the users installed applications and configurations. This mountable file system is not compressed and a binary such as Seamonkey must be read from the flash (failrly slow). A remaster could be performed to install Seamonkey in the .sfs file which might load quicker from the sfs file if it were loaded into RAM at boot? not loaded into RAM (ie.. sfs loop mounted Read-Only using the .sfs. file on the SDCH flash card)?
The point of all this rambling is I guess considerable testing would be required to determine my best performance options for my particular usage model. Seamonkey currently loads slow from my loop mounted pupsave.2fs file stored on the boot SDHC flash device; likewise, very little RAM is available after boot requiring a mandatory SWAP file (maybe if the sfs file weren't loaded into RAM and/or /tmp used must less RAM the system might perform better?)
IE.....
1.) How big of SWAP file to use if any.
2.) If it makes sense to reduce the /tmp file size
3.) Binary load times depending where/how they are loaded
RAM loaded sfs/remastered sfs file loop mounted from RAM/Flash device
Before I start testing my different options, Am I correctly understanding how the default operational configuration is working and what modification could be made to improve binary load time?
Thanks Much
Regards, Ron
Thanks for the reply to my previous post regarding /tmp and Zram.
I haven't installed and tried the latest 2.2 version of Puppy Linux for the OLPC version 1.0 hardware.
The following is my understanding of how Puppy Linux ,by default, runs on the OLPC 1.0 platform:
1/2 of the RAM is allocated to the /tmp RAM file system.
Since /tmp is NOT used to temporarily store cached flash writes (as it normally is), it could be reduces in size by modifying the initrd.img file?
The pup.sfs file is loaded into RAM (not in /tmp?) which should make application load quicker but takes up limited RAM space. The boot options could be modified (as per your last post) to NOT load the .sfs file but this might make the applications load slower.
The pupsave.2fs/3fs file stores all the users installed applications and configurations. This mountable file system is not compressed and a binary such as Seamonkey must be read from the flash (failrly slow). A remaster could be performed to install Seamonkey in the .sfs file which might load quicker from the sfs file if it were loaded into RAM at boot? not loaded into RAM (ie.. sfs loop mounted Read-Only using the .sfs. file on the SDCH flash card)?
The point of all this rambling is I guess considerable testing would be required to determine my best performance options for my particular usage model. Seamonkey currently loads slow from my loop mounted pupsave.2fs file stored on the boot SDHC flash device; likewise, very little RAM is available after boot requiring a mandatory SWAP file (maybe if the sfs file weren't loaded into RAM and/or /tmp used must less RAM the system might perform better?)
IE.....
1.) How big of SWAP file to use if any.
2.) If it makes sense to reduce the /tmp file size
3.) Binary load times depending where/how they are loaded
RAM loaded sfs/remastered sfs file loop mounted from RAM/Flash device
Before I start testing my different options, Am I correctly understanding how the default operational configuration is working and what modification could be made to improve binary load time?
Thanks Much
Regards, Ron
Re: OLPC questions
Ronrrolsbe wrote:
IE.....
1.) How big of SWAP file to use if any.
2.) If it makes sense to reduce the /tmp file size
3.) Binary load times depending where/how they are loaded
RAM loaded sfs/remastered sfs file loop mounted from RAM/Flash device
Before I start testing my different options, Am I correctly understanding how the default operational configuration is working and what modification could be made to improve binary load time?
Thanks Much
Regards, Ron
I run the XO-1 with 256MB swap the last 4 years and never run out of RAM, so I would think 256MB swap is OK.
I do not think will make a difference if you reduce tmpfs size. If it did would be probably for the worse. But frankly I never tried it
I find that there is not big difference, if any, between having the binaries on the sfS of savefile, because on the sfs they are compressed, so you read faster but you need some time to decompress them.
If you want to test you can try a Racy build that I made some time ago which has seamonkey in the main sfs. Takes quite some time to load...
BTW seamonkey is probably one of the slowest to load. Unless you want the mail and html editor all in one, i find it fairly poor. Google-chrome or Midori are better options
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
sisusbvga
Here is a pet that hopefully fixes the connection of an external monitor/projector to the XO via a usb2vga adaptor. It also provides a desktop application that can switch to the external monitor without the need to reboot.
Unfortunately, I have no way to test it since I do not have such an adaptor
So if you use it please report either way.
Unfortunately, I have no way to test it since I do not have such an adaptor
So if you use it please report either way.
- Attachments
-
- sisusb.pet
- usb2vga for the XO (do not use with other puppies)
- (7.3 KiB) Downloaded 1077 times
Last edited by mavrothal on Tue 27 Mar 2012, 10:48, edited 1 time in total.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Hi, mavrothal,
Many thanks for your hard work and a great new JWM. Running it on a Lenovo S10-3t touchscreen netbook and 5.3 dpup-exprimo with the 3.1* kernel, frugal install on 8GB usb stick.
The larger title buttons are great. I'm still having trouble with screen rotation, however. I get the full rotation (something that didn't happen with previous JWMs), but the task bar remains in the middle of the screen (as though the screen were still in landscape mode).
I can not replicate this problem in IceWM,which rotates fine, but without the great new titlebar.
Any workarounds to this?
Many thanks,
Jake
Many thanks for your hard work and a great new JWM. Running it on a Lenovo S10-3t touchscreen netbook and 5.3 dpup-exprimo with the 3.1* kernel, frugal install on 8GB usb stick.
The larger title buttons are great. I'm still having trouble with screen rotation, however. I get the full rotation (something that didn't happen with previous JWMs), but the task bar remains in the middle of the screen (as though the screen were still in landscape mode).
I can not replicate this problem in IceWM,which rotates fine, but without the great new titlebar.
Any workarounds to this?
Many thanks,
Jake
This sounds like an older jwm version. What "jwm -version" reports?jakfish wrote: The larger title buttons are great. I'm still having trouble with screen rotation, however. I get the full rotation (something that didn't happen with previous JWMs), but the task bar remains in the middle of the screen (as though the screen were still in landscape mode).
The jwm-2.1.1_2.pet also contains /usr/bin/olpc-rotate and /usr/sbin/olpc-rotate_shell. They should not affect non-XO buids but remove them just in case.
Also make sure that you to not have any other jwm executable but the one in /usr/bin.
Finally run in terminal (or from your rotation script)
Code: Select all
/usr/sbin/fixPuppyPin /root/Choices/ROX-Filer/PuppyPin
rox -p /root/Choices/ROX-Filer/PuppyPin
If all fails it may have to do with something exprimo specific. You may want to recompile for exprimo (is very simple), or ask Pemasu to do it.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Thank you for such a quick, helpful reply.
I did all your steps, but I'm still getting the failed transition from landscape to portrait, BUT only if the taskbar is set to auto-hide.
If it's set to "false," the rotation is fine.
A hassle, though, to have to keep resetting jwm-tray. Is there a workaround to this, or at least a piece of code that I can put in a script that will change auto-hide back and forth b/w true and false?
At this point, for simplicity, I have two desktop scripts:
xrandr -o left
and
xrandr -o normal
Any commands to add, that might change the taskbar hide/show, and I guess it would have to reset jwm as well?
Again, thank you for such great help,
Jake
I did all your steps, but I'm still getting the failed transition from landscape to portrait, BUT only if the taskbar is set to auto-hide.
If it's set to "false," the rotation is fine.
A hassle, though, to have to keep resetting jwm-tray. Is there a workaround to this, or at least a piece of code that I can put in a script that will change auto-hide back and forth b/w true and false?
At this point, for simplicity, I have two desktop scripts:
xrandr -o left
and
xrandr -o normal
Any commands to add, that might change the taskbar hide/show, and I guess it would have to reset jwm as well?
Again, thank you for such great help,
Jake
Try thisjakfish wrote: A hassle, though, to have to keep resetting jwm-tray. Is there a workaround to this, or at least a piece of code that I can put in a script that will change auto-hide back and forth b/w true and false?
Code: Select all
sed -i 's/autohide\="false"/autohide\="true"/' /root/.jwmrc-tray # hide
sed -i 's/autohide\="true"/autohide\="false"/' /root/.jwmrc-tray # show
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
mavrothal, one more thing, and it's more aesthetics than anything. While the taskbar (and w/ it, access to all programs) is now properly placed, the actual desktop screen remains in landscape mode.
So a lot of the desktop icons are hidden, as is the conky that lives at the upper right corner of my landscape screen, etc.
It's not a big deal, as long as any needed program is launched *after* a change to portrait.
Do you think that's a xrandr issue or something to do w/ jwm?
Thanks again for your assistance,
Jake
So a lot of the desktop icons are hidden, as is the conky that lives at the upper right corner of my landscape screen, etc.
It's not a big deal, as long as any needed program is launched *after* a change to portrait.
Do you think that's a xrandr issue or something to do w/ jwm?
Thanks again for your assistance,
Jake
Re: sisusbvga
C'mon people be nice.mavrothal wrote:Here is a pet that hopefully fixes the connection of an external monitor/projector to the XO via a usb2vga adaptor. It also provides a desktop application that can switch to the external monitor without the need to reboot.
Unfortunately, I have no way to test it since I do not have such an adaptor
So if you use it please report either way.
If anybody actually used it on an XO, please report
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Sorry Jake, somehow I missed your post.jakfish wrote:mavrothal, one more thing, and it's more aesthetics than anything. While the taskbar (and w/ it, access to all programs) is now properly placed, the actual desktop screen remains in landscape mode.
So a lot of the desktop icons are hidden, as is the conky that lives at the upper right corner of my landscape screen, etc.
It's not a big deal, as long as any needed program is launched *after* a change to portrait.
Do you think that's a xrandr issue or something to do w/ jwm?
Thanks again for your assistance,
Jake
The fixPuppyPin command given above should fix the desktop icons and the background if you have selected the "stretched" option. Doesn't it?
I do not know about conky as I never used it. Check to see if it has any placement options.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
JWM 579
Jake
you may want to try the latest jwm snv 579. Supposingly handles xrandr better.
The pet below is compiled in XOpup and has the bigger buttons too.
Works fine in Lupu 528.005 that I tried it though I did not rotate the screen.
In XOpup-2.2 (Lupu 5.2) rotation works fine.
you may want to try the latest jwm snv 579. Supposingly handles xrandr better.
The pet below is compiled in XOpup and has the bigger buttons too.
Works fine in Lupu 528.005 that I tried it though I did not rotate the screen.
In XOpup-2.2 (Lupu 5.2) rotation works fine.
- Attachments
-
- jwm-579_XOpup-1.pet
- JWM svn-579 patched for bigger buttons. Works fine in Lupu 5.x too
- (73.26 KiB) Downloaded 1068 times
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
No. But restart X, not just jwm, after you install.jakfish wrote:Looking forward to trying this. Should I uninstall jwm 2.1 before installing this version?
Jake
Type "jwm -version" in the terminal to make sure it says "jwm svn 579"
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Hi, mavrothal,
Successfully installed this update over jwm 2.1 on dpup exprimo w/ frugal install.
On hardware of Lenovo S10-3t, I don't find any difference, meaning that jwm 2.1 works pretty good with the S10's touchscreen.
I have, however, abandoned the fixPuppyPin command. While it brings out all my desktop icons in portrait, after returning to landscape, my conky and rainlendar calendar are gone until I reset X. I think this has to do w/ their fixed x and y coordinates.
I've simply moved the icons necessary to portrait mode (Opera, ebooks, etc) to the left-hand of the screen. In portrait, there they are, and without fixPuppyPin, I can have landscape restored to all its splendor w/o X restart.
jwm 2.1, with your nifty commands to reset the autohide taskbar, is very stable going back and forth b/w portrait and landscape.
Jake
Successfully installed this update over jwm 2.1 on dpup exprimo w/ frugal install.
On hardware of Lenovo S10-3t, I don't find any difference, meaning that jwm 2.1 works pretty good with the S10's touchscreen.
I have, however, abandoned the fixPuppyPin command. While it brings out all my desktop icons in portrait, after returning to landscape, my conky and rainlendar calendar are gone until I reset X. I think this has to do w/ their fixed x and y coordinates.
I've simply moved the icons necessary to portrait mode (Opera, ebooks, etc) to the left-hand of the screen. In portrait, there they are, and without fixPuppyPin, I can have landscape restored to all its splendor w/o X restart.
jwm 2.1, with your nifty commands to reset the autohide taskbar, is very stable going back and forth b/w portrait and landscape.
Jake