Re: [PATCH RFC V2 3/6] time: keep track of the pending utc/tai threshold

[John Stultz]

On 05/22/2012 10:39 AM, Richard Cochran wrote:
> On Mon, May 21, 2012 at 09:08:15PM +0200, Richard Cochran wrote:
> > On Mon, May 21, 2012 at 11:09:51AM -0700, John Stultz wrote:
> > > On 05/18/2012 07:09 AM, Richard Cochran wrote:
> > > > +	/* Tracks where we stand with regard to leap the second epoch. */
> > > > +	enum {
> > > > +		LEAP_IDLE,
> > > > +		LEAP_INS_PENDING,
> > > > +		LEAP_INS_DONE,
> > > > +		LEAP_DEL_PENDING,
> > > > +		LEAP_DEL_DONE,
> > > > +	} leap_state;
> ...
>
> > I don't think I am explaining this very well. I will try again to make
> > it clear using a table or something later on.
> The following table illustrates what happens around a (fictitious)
> leap second. Imagine a new epoch will occur at UTC time value 10 and
> the new TAI - UTC offset will be 2 seconds. The columns of the table
> show the values of the relevant time variables.
>
> U:     UTC time
> CODE:  NTP time code
> T:     TAI - UTC offset
> P:     pending (explained below)
>
>     U   CODE    T   P
>   --------------------
>     1   INS     1   1  leap second sheduled
>   --------------------
>     2   INS     1   1
>   --------------------
>         ...
>   --------------------
>     8   INS     1   1
>   --------------------
>     9   INS     1   1
>   --------------------
> | 10   OOP     1   1  leap second, 1st tick
> |~~~~~~~~~~~~~~~~~~~
> |  9           2   0  leap second, 2nd and subsequent ticks
>   --------------------
>    10   WAIT    2   0  new epoch
>   --------------------
>    11   WAIT    2   0

Not sure I'm still following.

It seems currently we have:

   U   CODE    T
 ----------------
   9   INS     1
 ----------------
  10   INS     1     pre tick, post leap second edge (this is the technically incorrect interval)
 ~~~~~~~~~~~~~~~~
   9   OOP     2     post tick, post leap second edge
 ----------------
  10   WAIT    2     new epoch


If you're trying to correct the pre-tick, post leap second edge, the above provides all you need.

In the adjtimex code, all you have to do is:


if (unlikely(CODE == INS&&  U == 10))

	/*note, we're not modifying state here, just returning corrected local values*/

	return (U-1, OOP, T+1);

return (U,CODE, T);


Since when the tick triggers, we'll move the CODE state appropriately.

Or am I still missing something?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/