To understand the usability of the prototype, the modified kernel was installed on the authors' personal computers, configured to monitor every process on the system. As indicated above, such a configuration has a minimal performance impact in practice; however, enabling delays in this situation can cause certain problems. Privileged programs, such as login, sendmail, and cron, have a highly constrained behavior profile; thus, after a day or two of sampling, these programs tend to settle into a stable normal, and exhibit few anomalies. Large non-privileged programs, such as netscape and emacs, have more complicated behaviors, and thus tend not to shift into a normal monitoring mode, and so are never delayed.
Some of the more interesting programs are ones which perform simple
system monitoring, such as asclock (a NeXTStep-style clock) and
wmapm (a battery monitoring program). These programs execute a
large number of system calls, and most of the time they have
repetitious behavior. However, when a user perturbs the system by
changing desktops or by moving windows, the behaviors of these
programs can change. In the current prototype, these programs tend to
be the first to obtain normals, and the first to be slowed down. Over
a few days they tend to settle down and operate normally; this
transition, however, can require a number of user-supplied
tolerization events. This suggests that the heuristics described in
Section 3 may need to be refined. However, by temporarily setting
to a low value (such as 5), the number of reported
anomalies can be kept to a minimum.
As monitoring programs are generally not critical applications, problems involving them can be seen as minor nuisances. A more significant set of issues arises with the behavior of one large, privileged program: the X server. The X server is responsible for initializing and controlling access to the video display, on behalf of X clients such as xterm and netscape. X servers are similar to monitoring programs, in that they make a large number of mostly-repetitive system calls, and so tend to acquire a normal profile quickly. User actions can also perturb the X server's behavior, causing it to be delayed. In this case, the delays can have dramatic effects, such as causing a user's entire session to be frozen or leaving the video hardware in a confused state when they occur during server initialization or shutdown. Fortunately, most of these problems can be avoided by initially starting up and shutting down the X server a few times, allowing pH to learn the critical initialization and shutdown system call patterns.
These two classes of problems suggest a weakness in our current approach. Programs which make large numbers of system calls in a short period of time tend to acquire normal profiles, even when a true sampling of behavior has not yet occurred. A natural solution is to take time into account during the normal profile decision process. Such a strategy might require a significant amount of computation, and so is probably better implemented in a userspace control daemon. It would also allow additional factors to be considered, such as size of executable, number of invocations, and perhaps program-specific heuristics. Such a daemon is planned for the future.