[linux-mm-cc] compcache on LTSP

[Nai Xia]

On Mon, May 5, 2008 at 4:27 PM,  <nai.xia at gmail.com> wrote:
>
>                 Compcache on The Linux Terminal Server Project
>
>                           Nai Xia (nai.xia at gmail.com)
>
>  1. Introduction of LTSP (from www.ltsp.org)
>
>  The Linux Terminal Server Project adds thin-client support to Linux servers.
>  LTSP is a flexible, cost effective solution that is empowering schools,
>  businesses, and organizations all over the world to easily install and deploy
>  desktop workstations. A growing number of Linux distributions include LTSP
>  out-of-the-box.
>
>  Shiny new thin-clients and legacy PCs alike can be used to browse the Web, send
>  e-mail, create documents, and run other desktop applications. LTSP not only
>  improves Total Cost of Ownership (TCO), but more importantly, provides
>  increased value over traditional computing solutions.
>
>  Many of the success stories of LTSP(*) are solutions deployed at schools,
>  institutes, libraries, etc. One of the mostly required features in these
>  environments, is the reading of the Adobe Portable Document Format. So our
>  experiment is based on a very popular .pdf reading software --- kpdf in a
>  typical LTSP setup. The results show compcache can bring significant improvements
>  to this kind of application.
>
>  (*)http://wiki.ltsp.org/twiki/bin/view/Ltsp/SuccessStories
>
>
>  2. Environment
>
>  Hardware:
>         Server: Pentium 4 2.0GHZ, IDE disk 7200rpm, 1G RAM
>         ThinClient: Old T42 IBM thinkpad, Pentium M 1.6GHZ,
>                 124M RAM(limited with kernel cmdline, to emulate a legacy PC)
>         network:  1Gigabit network
>
>  Software:
>         Server host: Debian sid,updated at April,23th
>                      LTSP(ltsp-server-standalone) + DHCP + NFS rootfs
>         Thin client: Debian etch with KDE, diskless( without swap )
>
>
>
>  3. Experiments
>
>  A group of pdf files were randomly selected, each of them is a technical paper and of
>  similar size (1.1M~1.2M). The experiments are to evaluate the user experience
>  reading these papers with V.S. without compcache loaded. We symbolically named
>  them as A.pdf,B.pdf....Z.pdf for ease of presentation.
>
>  a) Pdf reading responsiveness
>
>  When reading a pdf file with kpdf, if the system is under pressure (CPU or
>  memory), a user can feel obvious slowdown in paging down and paging up in a
>  document. Thus we define the pdf reading responsiveness as the time(seconds) for paging from
>  the 1st page to the 50th page (go back and forth to take the mean value) in the same
>  pdf file.
>
>  After the thin client booted up, the KDE was started and two pdf files(A.pdf,
>  B.pdf) were loaded, which ate most of the 124M RAM. We tested the value and closed
>  these two pdf files. Then we loaded the compcache with swapsize of 64M and did
>  the same test again. The results are as follows:
>  ------------------------------------------------------------------
>                 original          with compcache(64M)
>
>  A.pdf           10s                     2.5s
>
>  B.pdf           412s                    4s
>  ------------------------------------------------------------------
>
>  Just as we can expect, without compcache, the system slowed down significantly when
>  approaching the memory up limit, which actually makes the system unusable if one wants
>  to read the two pdf files side by side. While with the help of compcache, it
>  quite smooth to read these two pdf file concurrently.
>
>
>
>  b) Desktop responsiveness
>
>  Similar slowdown can be observed in upper case if one wants to switch between
>  the two kpdf programs from time to time. We believe it is related to the X
>  window system and the window manager.We call the average swith time between two
>  programs "the desktop responsiveness". It's also important, for if someone is
>  reading one book and take another as a reference, low desktop responsiveness
>  will soon bored him out.
>
>  In the same experiment as in a), we observed the desktop responsiveness in the original
>  ltsp client was 10 seconds,while after the compcache was loaded, the swith time was
>  hardly observable!
>
>
>  c) Load capacity
>
>  Man is a lazy animal, if one opens a pdf file and feel he MAY take a look at it later
>  on, he trends to keep it open for hours :). So the number of pdf files we can
>  keep open in our system is never large enough. We here show how compcache can
>  improve on this situation.
>
>  As we have seen, the original system can successfully load two pdf files, but
>  not more, further loading triggered the OOM killer. That means the loading
>  capacity of the original is 2. The compcache can be installed as different swap
>  size, so we ranged the swap size from 32768kbytes to 196608kbytes to see the
>  relation between swap size and load capacity.
>
>  --------------------------------------------------------------------------
>  swap size(kbytes)               load capacity(num. of pdf files)
>  (none)                                  2
>  32768                                   4
>  65536                                   6
>  98304                                   9
>  131072                                  11
>  163840                                  11
>  196608                                  11
>  --------------------------------------------------------------------------
>
>  We can see that in the best case, compcache increased the load capacity by 450%.


I think I can improve here, by logging the memory
behavior(/proc/meminfo) opening each new pdf file.
And then gnuplot the result.  How do you think ? :)


>
>
>
>
>  5. Conclusion
>
>  LTSP is a great invention for large number of legacy or resource-limited PCs,
>  however, users may suffer from the limited memory using these systems when
>  the up limit is approached. More money can be spent adding on more RAM to
>  improve the user experience, the feature-rich KDE desktop can be cutted off to
>  lend more memory to other programs. But, with compcache, who bothers ! :)
>
>