ntpq peers formatting needs floating point for time slots.

[Eric S. Raymond]

Achim Gratz <Stromeko at nexgo.de>:
> Eric S. Raymond writes:
> > You can't know enough to be "intelligent" before the per-host data
> > arrives.
> 
> Well, If I know that I'm going to display ten characters wider than
> usual, I can add teo digits of extra precision before I widen the space
> for the hostname by four digits.  That sort of intelligence.

The problem is that you don't get to know that you'll need ten digits wider
for later entries at the display time of earlier ones.

> > And if you wait for all data, the tool can become painful to use due to DNS
> > stalls.
> 
> Yeah, and if you send those off asynchronously you can just display the
> IP address if you don't get an answer in whatever the standard or user
> defined timeout is set to.

You don't have the asynchronous option either.  The protocol is lockstep and
reverse-lookup on an address can cause long client-side stalls. 

> > Basically there are no happy answers here.
> 
> I was only shooting for "better than status quo".

There are no answers better than the status quo without a major
complexity explosion.  I'm pretty sure of this because when I was
moving the C code to Python I explored the design space around this
problem extensively.

In theory it would be possible to write a front end that (a) paints
a first-pass display with IP addresses only, then (b) spawns multiple
threads doing reverse-DNS on each entry, updating the display with
a hostname as each thread returns. (c) exits when all of those updates
have landed.  Good luck with that; it would, at a bare minimum, quadruple
the complexity and be quite bug-prone.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.