Le 05/01/2012 06:36, Harlan Stenn a écrit :
ntpd can easily track SI seconds or "angle time" seconds. The
differences are small enough over a day to be easily amortized.
It would not be all that difficult to create an NTPv5 protocol (for
example) that would include "timescale" as a parameter. There may be a
way to do this using the v4 protocol, but I haven't thought about it at
all.
But that's pretty easy - there are other issues afoot here, like
regardless of how one syncs time between machines, if one collects a
timestamp on a box, what timescale is that timestamp in?
NTP4 already has extension field capability which could be used to
identify and define the alternate scale data.
I was thinking along the lines that the reference, originate, receive
and transmit timestamps be kept as now ( UTC in whatever form) so that
if no extension in the packet, nothing to do. The transmitted scale(s)
would be piggybacked in extensions as an offset / frequency change to
get to next alternate timescale tick, and on a per client basis. Up to
the admin via ntp.conf to say what he wants to use . All managed scales
would be transmitted. As there is usually only one hardware TSC/timer
and RTC pair in a machine , those would need to be occupied by the
chosen scale and served packets have their UTC fields reverse mapped
from the TSC/timer data and managed alternate scale parameters. I guess,
multiple alternate scales could be managed if the UDP packet space allows.
What about storing these timestamps? Displaying their values?
Comparing them with other timestamps from possibly different timescales?
ntp management utilities would need new options to list display and
compare alternate timescale data.
H
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
