As with any project, people frequently have questions regarding the software, it's design, and why certain choices were made in the implementation. The common ones are addressed here and are updated as new ones come along.

Why s-expressions instead of XML or binary?

This one comes up rather frequently. Other systems out there are based on a wide variety of data transport and representation formats, most commonly XML and binary. The original version of supermon was based on Sun RPC, which is a binary format. Though Sun RPC interfaces provide a somewhat portable means for transmitting binary, binary has two main limitations:

  • If not using a portable binary library, binary is, well, not portable.
  • Extensions to the protocol, new data structures, and new data types are very difficult to add. Binary is not extensible or composable, as defined on the DataProtocol page.

Binary can be very fast, but the speed is not so drastically better than a good ASCII format to justify the above limitations.

XML on the other hand provides an extensible, composable format that conforms to a standard, portable specification. Unfortunately, XML is a heavyweight option for achieving this. The main drawbacks are:

  • Parsers are very computationally intensive, especially with validation enabled.
  • XML suffers from bloat. Expressing simple structures requires large ASCII data relative to the data size itself.
  • Although libraries such as libxml2 and Xerces are available on systemssuch as Linux, they are not necessarily available elsewhere. We recognize the fact that not everyone uses, or wants to be forced to use, Linux. We don't like the idea of requiring users to install additional software to support Supermon.

S-expressions are capable of expressing the same tree structures as XML, without cross-referencing as achieved with XLinks, XPointers, and other XML linking methods. We don't believe these are necessary. What s-expressions lack is a method for inlining metadata with data itself to aid in interpreting it. Supermon provides a way to deal with this. The # command provides a description of the structure of a sample. A client is free to read this and initialize it's internal structures and then sample. A valid sample will obey the constraints described by the # command, and an invalid sample will generally not. With reliable transport protocols like TCP/IP, we can assume data received is exactly what was sent by a source to clients. Given sources that have been verified to send correct data, validation is not necessary outside the development cycle of supermon itself.

In short, although XML can achieve the end goal, it is not necessarily a wise choice from a software engineering perspective considering the performance constraints imposed by requiring LowPerturbation of the monitoring system. In this sense, it's like going deer hunting with a bazooka - although it may achieve the end goal (killing the deer), it may not be the most elegant choice considering the desired result (an intact carcass fit for dinner).

Is Supermon only usable on Linux?

Referring to the SupermonArchitecture explanation, one can see that a clientmust connect to some data source on TCP port 2709. How data reaches this port is not important, as long as it is in a format compatible with the DataProtocol. Supermon provides Linux kernel modules that make entries in /proc that mon picks up and provides over the socket. This does not prohibit users of other operating systems from creating similar kernel modules to provide data in a similar manner, given that mon can find them. Furthermore, if a user wishes to not go through the trouble (or simply does not have permissions) to create kernel-level data sources, the MonHole provides a simple, although lower performance and more restrictive, option for pushing data through the Supermon data stream. The clusters at LANL are Linux, and so Supermon has been primarily developed there.

The supermon server, clients, and even mon have been at one time oranother run on other systems. Older versions of Supermon demonstrated it's usability on FreeBSD and SGI Irix for providing data to mon (this code is unfortunately outdated and incompatible with current supermon versions due to those platforms no longer being used). The supermon server and clients have been run on MacOSX/Darwin based systems, while one client was even run on a Windows based machine!


Figure 1. A supermon client running on a Windows-based powerwall.

Symbols are missing when I try to load the supermon kernel modules!

The Linux SymbolDemoronifier (symdm) will fix this!


Updated 08-13-2008