ThinClientMemoryUsage

Differences between revisions 1 and 19 (spanning 18 versions)
Revision 1 as of 2005-11-03 05:25:50
Size: 3083
Editor: 180_220_103_66-WIFI_HOTSPOTS
Comment: Initial entry.
Revision 19 as of 2005-11-04 00:15:17
Size: 6255
Editor: 209
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
 * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/foo  * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/thin-client-memory-usage
Line 10: Line 10:
In order to have a good chance of Dapper being used in an older school lab, or non-profit organization, Dapper will have to be able to boot thin clients that have, at a minimum, of 32 megabytes of memory. In order for Dapper to be considered as a solution for breathing new life into old machines by using them as thin clients, Dapper will have to be able to boot thin clients that have as low as 32 megabytes of memory.
Line 14: Line 15:
There are a lot of older machines out there, and one of the huge selling points of any thin client GNU/Linux solution will be to use existing, older hardware that's unable to be used with other operating system. Third world countries, schools, non-profits, and cost-conscious companies will all be interested in taking advantage of hardware they already own. There are a lot of older machines out there, and one of the huge selling points of any thin client GNU/Linux solution will be to use existing, older hardware that's unable to be used with other operating systems. Developing countries, schools, non-profits, and cost-conscious companies will all be interested in taking advantage of hardware they already own.
Line 18: Line 19:
Jeff has an old lab with a bunch of old Pentium 120's with 32 megs of memory. He's been informed that to upgrade his current operating system that he bought in 1998, to the current one will be both expensive and painful, as it will require him to replace all of his lab machines. However, his good friend Mark gives him a Dapper Drake Ubuntu cd, and within a few hours, he's got it installed on his file server, and has got a shiny new lab without having to buy a single workstation. Jeff has an old lab with a bunch of old Pentium 120's with 32 megabytes of memory. He's been informed that to upgrade his current operating system that he bought in 1998, to the current one will be both expensive and painful, as it will require him to replace all of his lab machines. However, he hears about Edubuntu on Slashdot, and downloads a Dapper Drake Ubuntu CD, and within a few hours, he's got it installed on a spare file server. He shows his boss the shiny new lab with great educational software without having to upgrade a single workstation, or buy a software license.
Line 20: Line 21:
Scott is a systems administrator at a government agency that is chronically underfunded. His boss wants full internet, email, web browsing, office suite, and other apps on every box, but tells him he must do it without upgrading machines, as, "it isn't in the budget". His friend Mark (yes, the same Mark as above) just happens to pass by with, surprise, surprise, a Dapper Drake CD. The day is saved, once again thanks to Mark. Scott is a systems administrator at a government agency that is chronically underfunded. His boss wants email, web browsing, office suite, and other applications on every box, but tells him he must do it without upgrading machines, as, "it isn't in the budget". His friend Oliver meets with him for lunch, and gives him a Dapper Drake CD, and offers to come by and help to get it installed. It fits the bill perfectly, and Scott's boss is impressed with the speed, and ease of administration. She tells him to deploy it in some of their out of town offices as well.
Line 22: Line 23:
Amina and Tiye are the founders of a small start up company working on an embeded thin client kiosk solution to be used in homeless shelters in a developing country. Money's tight, being a startup, and their kiosk portal's a web based solution, but they need something to power the minimal kiosk machine. Mark (this guy gets around) is once again on the scene, with the solution to their problems: A shiny new Dapper CD.

As Jeff, Scott, Amina and Tiye all watch Mark rocket off into the sunset, they turn to each other, and ask, "Who was that masked superhero"?
Amina and Tiye are the founders of a small start up company working on an embedded thin client kiosk solution to be used in homeless shelters in a developing country. Money's tight, being a startup, and their kiosk portal's a web based solution, but they need something to power the minimal kiosk machine. Dapper once again to the rescue, and the embedded boards they chose to use (with only 48 megs of ram) work wonderfully.
Line 28: Line 27:
Saving memory's easy: it's just a case of removing all the bits not needed. The swap stuff's a bit harder, but not much. See Implemntation. To provide the thin client with the thinnest possible footprint, the following steps are needed:
 * Eliminate the loading of the restricted modules. The nVidia drivers usually aren't needed on a thin client anyway.

 * Blacklist modules if a "nolocaldevices" (name arguable) option is set in lts.conf, avoid loading of ide, floppy and other modules local device related modules through the new modutils/blacklist.d mechanism the new modutils will introduce in kernel 2.6.14/15. All modules like pcmcia support, parport bluetooth and drivers that are not essentially needed at all for running and using a thin client will be blacklisted by default.

 * Reduce the amount of video ram needed by the client. We should calculate how much is needed to do 1024x768 in 16 bit colour (reasonable for most older machines) and set the VideoRam parameter appropriately in xorg.conf. The administrator should have the ability to manually set this value up or down, depending on if his local clients have more or less memory.
 * On the server, provide some kind of nbd swap daemon so that when a thin client '''does''' run out of ram, it will simply get a bit slower, as opposed to hard failing because ram's been exhausted.
Line 32: Line 38:
 * Remove as much stuff as possible in the boot up.
 * Remove the restricted modules. Who puts an nVidia card in a thin client?
 * Find a way to limit the X.org video memory. By default, it's trying to grab 64 meg. 4 or 8's a lot more reasonable.
 * Use swap over nbd. The LTSP project has modified the nbd-swap server to automatically create the swap file on connect if it hasn't been created already.
 * Removing unnecessary modules and startup scripts will not only reduce memory, but will speed up the booting. This is being handled by ThinClientFasterStartup.
 * Remove the restricted modules, and the ramdisk that holds them. This will free up to 12 megabytes of ram. this will be achieved by only installing the kernel package instead of the metapackage through the ltsp-build-client script which is required to be fixed for multiarch and support for powerpc anyway see code section for more detail.

 * Limit the X.org video memory to 2048 kilobytes by default. Add the appropriate shell scripting into ltsp-client-setup to read the X_VIDEORAM parameter from the lts.conf file and pre-seed the debconf value for configuring the xorg.conf file. This will allow the administrator to easily set it up or down as needed.
 * Each getty running on a console uses up memory. Reduce the number of gettys being spawned in the inittab to save memory. You should need one or two at the maximum.
 * Use swap over nbd to provide a virtual memory solution. If the terminal runs out of ram, it will begin swapping over the network, and slow down considerably, but this is preferable to having the thin client crash or reboot due to memory starvation. The LTSP project has modified the nbd-swapd server to automatically create the swap file on connect if it hasn't been created already. This saves the Ubuntu server administrator the task of having to do this as a manual process. The source for ltsp-swapd can be found at:
  * {{{cvs -d :pserver:anonymous@cvs.ltsp.org:/usr/local/cvsroot co ltspswapd}}}

'''MattZimmerman: need to go into detail as to how nbd will be implemented on the client and how swap will be configured; it isn't plug-and-play'''
Line 39: Line 50:
== Outstanding issues ==  * Videocard memory problem:
Line 41: Line 52:
== BoF agenda and discussion ==   Preseed the debconf value xserver-xorg/config/device/video_ram to 2048 byte as a default in /etc/init.d/ltsp-client-setup, but make it respect a different value from lts.conf if one was set.
Line 43: Line 54:
Testing where to optimize.  * Inittab change:

  The change to intittab to disable unneeded getty processes should be done from the ltsp-build-client script.

 * Change in ltsp-build-client to avoid the restricted modules package:

  Look up the most actual version for linux-image-X.X.XX-X-${arch} in the archive (by checking the dependencys of the linux metapackage) and install it with ltsp-build-client to avoid installing the metapackage and thus the linux-restricted-modules package.

Summary

In order for Dapper to be considered as a solution for breathing new life into old machines by using them as thin clients, Dapper will have to be able to boot thin clients that have as low as 32 megabytes of memory.

Rationale

There are a lot of older machines out there, and one of the huge selling points of any thin client GNU/Linux solution will be to use existing, older hardware that's unable to be used with other operating systems. Developing countries, schools, non-profits, and cost-conscious companies will all be interested in taking advantage of hardware they already own.

Use cases

Jeff has an old lab with a bunch of old Pentium 120's with 32 megabytes of memory. He's been informed that to upgrade his current operating system that he bought in 1998, to the current one will be both expensive and painful, as it will require him to replace all of his lab machines. However, he hears about Edubuntu on Slashdot, and downloads a Dapper Drake Ubuntu CD, and within a few hours, he's got it installed on a spare file server. He shows his boss the shiny new lab with great educational software without having to upgrade a single workstation, or buy a software license.

Scott is a systems administrator at a government agency that is chronically underfunded. His boss wants email, web browsing, office suite, and other applications on every box, but tells him he must do it without upgrading machines, as, "it isn't in the budget". His friend Oliver meets with him for lunch, and gives him a Dapper Drake CD, and offers to come by and help to get it installed. It fits the bill perfectly, and Scott's boss is impressed with the speed, and ease of administration. She tells him to deploy it in some of their out of town offices as well.

Amina and Tiye are the founders of a small start up company working on an embedded thin client kiosk solution to be used in homeless shelters in a developing country. Money's tight, being a startup, and their kiosk portal's a web based solution, but they need something to power the minimal kiosk machine. Dapper once again to the rescue, and the embedded boards they chose to use (with only 48 megs of ram) work wonderfully.

Design

To provide the thin client with the thinnest possible footprint, the following steps are needed:

  • Eliminate the loading of the restricted modules. The nVidia drivers usually aren't needed on a thin client anyway.
  • Blacklist modules if a "nolocaldevices" (name arguable) option is set in lts.conf, avoid loading of ide, floppy and other modules local device related modules through the new modutils/blacklist.d mechanism the new modutils will introduce in kernel 2.6.14/15. All modules like pcmcia support, parport bluetooth and drivers that are not essentially needed at all for running and using a thin client will be blacklisted by default.
  • Reduce the amount of video ram needed by the client. We should calculate how much is needed to do 1024x768 in 16 bit colour (reasonable for most older machines) and set the VideoRam parameter appropriately in xorg.conf. The administrator should have the ability to manually set this value up or down, depending on if his local clients have more or less memory.

  • On the server, provide some kind of nbd swap daemon so that when a thin client does run out of ram, it will simply get a bit slower, as opposed to hard failing because ram's been exhausted.

Implementation

  • Removing unnecessary modules and startup scripts will not only reduce memory, but will speed up the booting. This is being handled by ThinClientFasterStartup.

  • Remove the restricted modules, and the ramdisk that holds them. This will free up to 12 megabytes of ram. this will be achieved by only installing the kernel package instead of the metapackage through the ltsp-build-client script which is required to be fixed for multiarch and support for powerpc anyway see code section for more detail.
  • Limit the X.org video memory to 2048 kilobytes by default. Add the appropriate shell scripting into ltsp-client-setup to read the X_VIDEORAM parameter from the lts.conf file and pre-seed the debconf value for configuring the xorg.conf file. This will allow the administrator to easily set it up or down as needed.
  • Each getty running on a console uses up memory. Reduce the number of gettys being spawned in the inittab to save memory. You should need one or two at the maximum.
  • Use swap over nbd to provide a virtual memory solution. If the terminal runs out of ram, it will begin swapping over the network, and slow down considerably, but this is preferable to having the thin client crash or reboot due to memory starvation. The LTSP project has modified the nbd-swapd server to automatically create the swap file on connect if it hasn't been created already. This saves the Ubuntu server administrator the task of having to do this as a manual process. The source for ltsp-swapd can be found at:
    • cvs -d :pserver:anonymous@cvs.ltsp.org:/usr/local/cvsroot co ltspswapd

MattZimmerman: need to go into detail as to how nbd will be implemented on the client and how swap will be configured; it isn't plug-and-play

Code

  • Videocard memory problem:
    • Preseed the debconf value xserver-xorg/config/device/video_ram to 2048 byte as a default in /etc/init.d/ltsp-client-setup, but make it respect a different value from lts.conf if one was set.
  • Inittab change:
    • The change to intittab to disable unneeded getty processes should be done from the ltsp-build-client script.
  • Change in ltsp-build-client to avoid the restricted modules package:
    • Look up the most actual version for linux-image-X.X.XX-X-${arch} in the archive (by checking the dependencys of the linux metapackage) and install it with ltsp-build-client to avoid installing the metapackage and thus the linux-restricted-modules package.

ThinClientMemoryUsage (last edited 2009-07-24 03:12:16 by 201)