[PATCH] add nmeter applet
Rob Landley
rob at landley.net
Mon Feb 13 18:06:34 UTC 2006
On Saturday 11 February 2006 05:53, Denis Vlasenko wrote:
> > > Usage: nmeter c[N] nIFACE m[f/t] s f i[NN] x p[f/n] b t[N] d[N] h[N]
> > > lLABEL LLABEL r
> >
> > Um, ick.
>
> Actually, it's more like
>
> nmeter [c[N]] [nIFACE] [m[f/t]] [s] [f] [i[NN]] [x] [p[f/n]] [b] [t[N]]
> [d[N]] [h[N]] [r]
>
> and after any option you may have [l<LABEL>|L<LABEL>]
> but such help line would be far too ugly. Your suggestion?
From a user interface perspective, the whole thing is kind of ugly.
> > > Nmeter allows you to monitor your system in real time
> >
> > So does top.
>
> But in completely different way. top scans entire process tree
> in /proc, nmeter just reads a few /proc files. I specifically
> avoided stats which are expensive to collect. Even on very
> old machines nmeter's own CPU usage is tiny.
Ok, looking slightly more closely at it, you have a point. I was misled by
the "based on nanotop.c" comment, and thought it was collecting what I always
consider the most useful statistic: percentage CPU usage in user, system,
iowait, and idle (which requires iterating through processes because loadavg
just doesn't cut it).
> > > Options:
> > > c[N] monitor CPU. N - bar size, default 10
> > > (legend: S:system U:user N:niced D:iowait I:irq i:softirq)
> > > nIFACE monitor network interface IFACE
> > > m[f/t] monitor allocated/free/total memory
> > > s monitor allocated swap
> > > f monitor number of used filedescriptors
> > > i[NN] monitor total/specific IRQ rate
> > > x monitor context switch rate
> > > p[f/n] monitor forks/# of processes
> > > b monitor block io
> > > t[N] show time (with N decimal points)
> > > d[N] milliseconds between updates. Default 1000
> > > h[N] print headers above numbers (each N lines, default once)
> >
> > That's kinda silly.
>
> What exactly is silly?
I meant that's a very complicated command line interface.
> > > lLABEL specify label for previous item
> > > LLABEL same, but label will be printed without surrounding blanks
> > > r print <cr> instead of <lf> at EOL
> >
> > That's extremely silly. You might want to look at the man page for
> > strptime.
>
> I do not understand your comment about strptime.
I meant that strptime has a syntax similar to printf, for printing out date
formats. There are a dozen or so time fields, and strptime inserts into a
string from a time structure the same way printf inserts arguments into a
string from its argument list.
If you're actually sticking arbitrary labels on fields, you might want to
think about going all the way to a format string for your output, which has
%escapes where you want it to insert data. (That's not the world's greatest
interface either, but at least it's familiar and flexible.)
And the implementation doesn't have to be that big either, iterate through the
string to find unescaped % signs, and after each one call a case statement on
the command letter (possibly after a call to strtol() if you want to be able
to use "%5s" syntax).
Just a suggestion.
> I have nmeter output running on my servers on one of their
> virtual terminals, helps to quickly guess what kind of load
> makes them slow (network? disk? CPU bound process(es)? runaway forking?).
I can see the potential usefulness of the applet. I find the user interface
cryptic and intimidating, and googling for "nmeter" doesn't bring up a hit on
the first page for any existing app that would already make lots of people
familiar with this specific user interface.
> > > # ./busybox.nmeter nmeter
> > > 12:46:13 cpu [U.........] mem 153M swp 24M proc 183 fork 1 bio 0
> > > 0 12:46:14 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio
> > > 0 0 12:46:15 cpu [..........] mem 153M swp 24M proc 183 fork 0 bio
> > > 0 148k 12:46:16 cpu [..........] mem 153M swp 24M proc 183 fork 0
> > > bio 0 0 12:46:17 cpu [..........] mem 153M swp 24M proc 183 fork
> > > 1 bio 0 0 12:46:18 cpu [..........] mem 153M swp 24M proc 183 fork
> > > 0 bio 0 0 ...
> >
> > That's an abbreviated top, yet this shares no code with our current top
> > implementation.
>
> Because as I explained above, there is not much to share.
>
> top does not measure fork rate, network i/o rate or block i/o rate.
> nmeter does not scan /proc/NN directories.
I want to look at this more closely, which means after 1.1.1 ships. (It's
close, I just got sidetracked _again_...)
> > More to the point, from a command line perspective this should just be
> > some kind of "terse" option to top.
> >
> > > Please comment.
> >
> > Neat idea, but this implementation should not be merged.
> >
> > Random example: read_decimal sample() is a one line function that's used
> > in exactly one place. Why the heck is it a function at all? That
> > function is a call to STR2SAMPLE() which is literally just a #define for
> > strtoull... That's just wrong, if you want strtoull() then just use
> > strotoull(). The
>
> I can't drop read_decimal_sample(). I need to pass a pointer to function
> with correct prototype.
Passing a function pointer from a wrapper isn't the way I'd have gone about
it, but I haven't looked closely at all the call sites. Stylistic
difference, perhaps...
Rob
--
Steve Ballmer: Innovation! Inigo Montoya: You keep using that word.
I do not think it means what you think it means.
More information about the busybox
mailing list