ntpmon now has some keystroke commands

[Gary E. Miller]

Yo Eric!

On Tue, 13 Dec 2016 20:41:18 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller <gem at rellim.com>:
> > > You can already do 'ntpq -c cv [associd]' with...ntpq.  Why do you
> > > consider it's desirable to duplicate that function in ntpmon?  
> > 
> > I don't dedire to duplicate.  I want to not break a long standing
> > tool (ntpq) and help create a much improved new tool (ntpmon).
> > 
> > The ntpq way to dig out data is pain to use and painful to
> > understand. Putting ALL the data related to an associd in one
> > place, and formatting it in a pleasing manner will make the data
> > much easier to use and understand.  
> 
> That is true.  I don't think ntpmon is the right place for this
> improved report, though.  One good reason is that it's not
> practically possible to *pipeline* a TUI.  In order to preserve
> forward options, Unix principles say you should put this kind of
> report generation in a CLI program that can be scripted.  Recent
> practice would prefer reporting in JSON.

But the data I want to see is dynamic.  This is why I run 'watch ntpq -p'
and 'watch ntpq -c rl [associd]'.  ntpq is just not up to the task.

If you do not think ntpmon is the place, then we will need another
new dynamic tool to look at these rapidly changing values.


> Notice carefully the distinction between a TUI (or GUI) optimized for
> reactive use by a human being and a CLI designed partly for eyeball
> use and partly to be scripted. That is central here.  One needs to
> think about how those design patterns fit (or don't fit) with
> *particular* use cases.

I'm not suggesting how to do it, just that the need exists, and not
satisfied by existing tools.

> > Well, you did ask.  
> 
> I did ask. And I've extracted something useful from your response: we
> need a better detail-reporting mechanism for peers and clocks. The
> assumption you made and failed to question was about where this
> mechanism should live.  But we'll figure out something useful to
> do about it.

We are 100% in agreement here.

> I'm explaining my thought processes in detail because I think it is
> never a bad idea for (a) programmers to get more clued in about the
> system-architect perspective in general, and (b) developers on *this*
> project to understand how tech lead thinks and where he might zig or
> zag next.

We are 100% in agreement here.

> > > Well, "should" in an ideal world, anyway.  In the real world, you
> > > have some excuse because defending the cleanliness of the
> > > architecture against featuritis is my job.  
> > 
> > OTOH, things like the sync distance can be broken for so long
> > because of a lack of data transparency.  
> 
> In theory you're absolutely right and I support your point.
> 
> In practice, the actual culprit in this particular (sync-distance)
> case happened to be elsewhere.  Buttonhole me if you care; unlike the
> data-model problem I just hinted at, it's a minor enough issue that
> I'm not motivated to write about it.

My point was not the error itself, but the lack of data transparency and
data visualization tools allows such errors to persist over long periods
of time.

One way or another we've got to get sunshiine on this dynamic data in
a way easy to grok.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20161214/c113fa86/attachment.bin>