[759] in Athena Bugs
RT 6.0C+: /usr/athena/top -- various problems
daemon@ATHENA.MIT.EDU (probe@ATHENA.MIT.EDU)
Fri Sep 2 07:54:29 1988
From: <probe@ATHENA.MIT.EDU>
Date: Fri, 2 Sep 88 07:53:39 EDT
To: rt-testers@ATHENA.MIT.EDU, bugs@ATHENA.MIT.EDU
Reply-To: Richard Basch <probe@ATHENA.MIT.EDU>
Consider this a bug report in advance, or rather a warning from the
person who made /usr/athena/top work on the RT.
The following is a list of known problems with /usr/athena/top on the
next RT release. These problems are difficult to solve and since I am
currently engaged in too many other projects with higher priority, I
will just mention that they will probably not be fixed by the time the
next srvd release comes out. None of the problems seem to be a
show-stopper in preventing its release to the world, as it does the
right general thing -- it gives users a general idea of what processes
are eating up the system resources.
- The command line is not always returned correctly... it sometimes will
report a command line with the first letter of the command in
parentheses. This is due to the fact that the argument space of the
process was unreachable at the time of the query (swapped out).
Basically ()'s indicate that it took the command from u.u_comm rather
than from the argument space of the process.
- Occassionally, the WCPU (weighted CPU usage) reading supplies a bogus
result (> 100%). This corrects itself within one or two tries.
- when paging heavily, some of the other statistics of the processes may
occassionally show a strange value (ie. time), but again, this is
self-correcting in one or two tries.
- there will be no man page for 'top' on the next RT release because we
cannot modify the urvd.
Since we are on the subject, I might as well point out the good side of
the things that had to be fixed (printed in the order that they were fixed)
- top would not compile because FSCALE was not defined.
- load averages were incorrectly reported
- CPU usages were absurd
- command line was NEVER correct
-Richard
