ntpq peers formatting needs floating point for time slots.
Stromeko at nexgo.de
Sun Feb 5 13:47:33 UTC 2017
Eric S. Raymond writes:
> 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.
No, but I know my display is 110 characters wide for example instead of
just 80 and can adjust the field width based on that. Hal has found a
way to squeeze another digit of precision on three numbers sticking to
the 80-character limit. It should be possible to get down to nanosecond
precision if the display is wider than that and I don't think that any
rocket science is involved.
> You don't have the asynchronous option either. The protocol is lockstep and
> reverse-lookup on an address can cause long client-side stalls.
I can already say I just want the IP addresses. I can get those from
the (possibly remote) ntpd very fast and send off the reverse DNS lookup
asynchronously from ntpq. If I don't get the result fast enough, I just
leave the IP in the output. And yes, that means the actual querying of
ntpd, the processing of the answers and the combination of the output is
going to happen asynchronously (not necessarily in parallel, but not
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
More information about the devel