Hello Steve;
Your computer must have a clock time error or teh network is extremely,
extremely slow.
The message timestamped 2017-01-04 20:39 was received at about
2017-01-05 16:57-05:00
-Stephen
On 2017-01-04 20:39, Steve Summit wrote:
Martin Burnicki wrote:
If we don't look only at the kernel and ntpd, but also consider PTP,
then there's still the question if if wouldn't be better to let the
kernel time run on TAI, and derive true and/or smeared UTC from it.
Right. At first when I was trying to implement CLOCK_UTC, I
lumped it in with the problem of reworking the kernel's internal
clock, but actually, they're separate problems. Although I
*have* reworked the kernel's internal clock (Linux calls it
'xtime'), it's expensive, and I'm now considering it among other
options, of which there are at least three:
1. Have xtime keep true UTC, as I've been doing so far. This was
always my first choice, but it ends up being majorly invasive,
and I fear the Linux kernel developers will lynch me if I so
much as mention it.
2. Have xtime keep TAI. This has the advantage that it's not at
all wrong or kludgey to represent TAI as a simple count of
seconds since the epoch, which of course xtime already is.
The objection, as mentioned here pretty regularly, is that if
you want to be able to set the clock from UTC, and deliver
UTC, you always need to know TAI-UTC, so if you don't have it
(if you're not on the net, or if you don't faithfully receive
it early enough during boot) you're sunk. But I'm now
thinking that the work involved in assuming TAI-UTC=0 in that
case (and remembering that we can't, for example, return
success if someone asks for clock_gettime(CLOCK_TAI), and
remembering to fiddle things if we learn TAI-UTC later) may
end up being less than the work involved in #1.
3. Keep xtime just about the way it is, augmented with a
well-defined leap-second flag (along the lines of the TIME_OOP
flag returned by adjtimex) so that CLOCK_UTC can still be
derived from it with full accuracy.
Number 1 was my strong preference at first, because I very much
wanted a kernel that kept "true UTC" internally, with no kludges
or circumlocutions, and derived everything else from it as
necessary. But the implementation cost to achieve that wish is
turning out to be very high, so #2 (and even the philosophically
ghastly but nicely expedient #3) are starting to look more
attractive.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
