[ntp:questions] Any chance of getting bugs 2164 and 1577 moving?
hart at ntp.org
Tue Mar 20 17:20:23 UTC 2012
On Tue, Mar 20, 2012 at 15:59, David Malone wrote:
> "David J Taylor" writes:
>>Thanks, David. Those don't seem to be in ntpq.c (at least 4.2.7p134), so
>>no wonder I couldn't find them.
> Ah - I'm looking at a slightly older verion (4.2.4p8), but I'd guess
> there is similar code lurking.
No, there's not. I removed a bunch of needless insider knowledge and
ASCII->internal->ASCII translations from ntpq.
>>But if the control messages are limited
>>to microseconds, this problem is deeper than I first thought. I suppose
>>that's saving on bandwidth by a few bytes?
> I think the sending code might be in ntp_control.c - there seem to
> be a bunch of variables that are sent with a fixed precision (search
> for 1e3 or 1e6). My guess is that because a bunch of variables are
> often packed into a UDP packet, a decision to keep them a modest
> size was probably taken.
As you can see with ntpq's raw mode and readvar, ntpd sends both
system offset and peer offsets to ntpq as ASCII text with three digits
beyond the millisecond decimal point. Increasing the representation
is possible and shouldn't break old or new ntpq (though old would
suppress the extra digits in rv output). It would increase the
response size, and particularly for plain "readvar 0" or "readvar
<assoc>" returning a list of default variables, risk splitting the
response into multiple 500-ish byte UDP packets.
More information about the questions