The fourth edition of the Italian Conference on Free Software (confSL) took place in Cagliari (Sardinia) this year. Bringing together University and LUGs, from one side, and Public Administration and young and dynamic small enterprises, from another, confSL is always an important appointment for Free Software movement, useful for understanding how market, law and economy evolve, making the point about work in progress and sharing information and news.

Rich, as usual, the program of workshops and seminars, ranging over technical and cultural aspects and including law, case studies, research and development projects. Among the technical seminars, we mention the one by FlossLab, presenting its application suite for Public Administration, the portal platform JAPS, Drush, a software for creating Drupal-based distributions, Notredam, a platform for Digital Asset Management and KLone, a framework for developing super fast and scalable web applications in C/C++. An article on VDD in conference proceedings has been presented by Binario Etico. It received very good feedback, especially from a technical point of view, and useful suggestions for making VDD an actually productive system. It seems this is the hot issue now!

It is now possible to visualize and use VDD desktops directly inside your browser. We have tested a number of methods and protocols to enable this feature. We evaluated VNC, RDesktop and X. VNC proved the best in terms of compression and performance. At first we chose to provide a VNC client to VDD users. We then prefered to directly resort to a web browser. So we used a VNC plugin for firefox, mozilla-gtk-vnc. We developed a simple Web GUI (see figure) and deply it on a web server on the VDD server. So just by clicking on your favourite desktop, you can see it projected directly into your browser. It is possibile to open multiple browser tabs, thus making switching among desktops confortable. We also produced a short video that shows all this.

Of course, in order to use this feature with a decent or at least acceptable performance, VDD server should be located in a network provided with a quite high upload bandwidth (which is not the case of VDD development  network, at the moment). ADSL connection services are not suitable for delivering this service on the Internet. At this page of the documentation, technical information on how to set up dispatching on the internet can be found.

Performance is a key issue when desktops are concerned, but system tuning is pointless, if users do not perceive any significant improvement. Common benchmarks do not give a direct indication of performance that is relevant for interactive applications, where the most important parameter is responsiveness perceived by users. We then developed a method for observing low-level system parameters while desktop operations take place, in order to describe correlations and hence trace a mapping. By analyzing such benchmarks, we can achieve an understanding of the low-level behavior of the system related to them.

So whenever a specific deployment of VDD is needed, such studies can assist system admins to put final users in a confortable environment. In the report Mapping system level to desktop level performance, we introduce this method and present some results obtained in applying it into our environment.

The report is primarily meant to describe a methodology to be used for understanding system behaviour from a user point of view and hence dimensioning VDD components and resources accordingly. But there are also some practical lessons learned during the experience. For example, some distros performed better than others. In particular we were impressed by GNU/Linux CentOS, whereas Debian Lenny and Gentoo 10 were just a confirmation of the excellent systems they are. Also Fedora and Windows (especially XP) did quite well during tests. But in general every dispatched desktop, when tested one by one, made it impossible to understand that they were not physical and local. Individual utilization performs very well, and so does group utilization when users are well distributed on different virtual machines. We discovered, though, that the number of concurrent users using the same virtual machine is critical and we learned how to dimension system in order to have up to 5 concurrent users working fine on the same dispatched machine. More details can be found in the report. Enjoy the reading!

Attachments:

report_on_performance_mapping.pdf

[Report Mapping system level to desktop level performance]

792 Kb

VDD project is currently working on performance analysis. The whole system, including every single feature, is put under the test, both on an individual base (one user at a time) and on a collective base (several users at a time). Contrary to what happens with servers, the main requirement for interactive desktop-based applications is to respond to user-generated events with a delay that is acceptable to their perception. Refering solely to throughput, bandwidth, end-to-end latency does not provide performance indications that are relevant for the desktop.

For this reason, our benchmark set is organized into three categories:

• Microbenchmarks: useful for understanding system behavior for simple interactive operations. Eg: GUI elements behaviour.
• Task-oriented benchmark: to understand the real impact of latency on the perceived interactive responsiveness of an application. Eg: office-suite tasks.
• Application microbenchmark, to evaluate isolated interactive events from the realistic workloads. Eg: page-down on Impress.

For widening the theme, see here

In order to obtain a mapping of system performance to desktop performance, we costantly measure values of parameters such as CPU, memory, disk and network, while operations, belonging to the aforementioned benchmark categories, are performed. Those values are stored on files with time stamps and eventually analysed and commented. Whenever a threshold is overpassed, an anomaly is reported and analysed apart.

Moreover, a questionnarie is given to people doing tests in order to determine satisfaction of users during the utilization experiences, useful for evaluating the system also in a qualitative way and possibly improve it.

The results and a final report will be published soon!