Re: GPS Leap Second Scheduled!

Re: GPS Leap Second Scheduled!

[Colin Plumb]

Ulrich Windl wrote:
> The time in the kernel is seconds since the epoch. To insert a second 
> means that we'll have to delay the next second for another second. 
> The other solution seems to be a clib -> kernel interface that knows 
> that a leap second is active now. Then the clib could possibly 
> convert the seconds to xx:yy:60. (I hope I did not overlook something 
> obvious).

And Andrej Presern replied:
>> Have you considered simply not scheduling any processes for one second and
>> adjusting the time accordingly? (if one second chunk is too big, you can do
>> it in several steps)

The problem is that POSIX is schizophrenic on the subject of leap seconds.
On the one hand, time() returns UTC time.  On the other,

	t = time();
	sec = t % 60;
	t /= 60;
	min = t % 60;
	t /= 60;
	hr = t % 24;
	t /= 24;
	printf("UTC time is %lu days, %02u:%02u:%02u\n", (unsigned long)t, gr, min, sec);

is required to work (since so much code does it.)

Actually, I think Ulrich was present when I proposed a similar solution:
gettimeofday() will not return during 23:59:60.  If a process calls
gettimeofday() during a leap second, then the call will sleep until 0:00:00
when it can return the correct result.

This horrified the real-time people.  It is, however, strictly speaking,
completely correct.

The real-world solution (a.k.a kludge), is to stretch some number of
seconds to cover the n+1 seconds including the leap second.  During
those seconds, gettimeofday() is incorrect, but the error is
well-defined, so two "good" implementations will return "close" values
and you can undo the fudging afterwards if desired.

The only trick is to define the number of seconds n, their position
relative to the leap second, and they type of stretching.  Linear is
obvious, making the 60 seconds leading up to a leap second take 61/60
of the usual time, but you could define a polynomial with higher-order
continuity.
-- 
	-Colin

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

Re: GPS Leap Second Scheduled!

[Theodore Y. Ts'o]

   Date: 	Tue, 8 Sep 1998 22:46:25 -0600 (MDT)
   From: Colin Plumb <colin@nyx.net>

   The problem is that POSIX is schizophrenic on the subject of leap seconds.
   On the one hand, time() returns UTC time.  

Yep.  See POSIX 4.5.1.2, 2.2.2.77, 2.2.2.24, and the rationale for
Epoch, found in B.2.2.2).

    On the other,

	   t = time();
	   sec = t % 60;
	   t /= 60;
	   min = t % 60;
	   t /= 60;
	   hr = t % 24;
	   t /= 24;
	   printf("UTC time is %lu days, %02u:%02u:%02u\n", (unsigned long)t, gr, min, sec);

   is required to work (since so much code does it.)

In fact, POSIX requires this (see 2.2.2.77).

   Actually, I think Ulrich was present when I proposed a similar solution:
   gettimeofday() will not return during 23:59:60.  If a process calls
   gettimeofday() during a leap second, then the call will sleep until 0:00:00
   when it can return the correct result.

The other possibility is for gettimeofday() to return the same value for
23:59:60 and 00:00:00.  This would also strictly speaking be correct.
time() is specified as returning "seconds since the Epoch", which is
defined as:

	tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
		(tm_year-70)*31536000 + ((tm_year-64)/4*86400)

where tm_sec, tm_min, tm_hour, etc. together form a Curridnated
Universal Time name.

Hence, the above equation would have the same value for 23:59:60 and
00:00:00 on the next day.  Hence, time() should return the same value.

						- Ted

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

Re: GPS Leap Second Scheduled!

[Jan Echternach]

On Tue, Sep 15, 1998 at 09:45:28PM -0400, David Feuer wrote:
> In my opinion, the thing to do is make the POSIX time function do
> something fairly reasonable, but come up with something better (e.g. UTC
> and TAI in 64 or 128-bit fixed-point format) for newer programs.

There is a similar discussion going on in comp.std.c (Subject: C9X FCD -
7.23.2.6 Normalization of broken-down times).

See also http://www.cl.cam.ac.uk/~mgk25/c-time/ for a proposal for a
new time API.

-- 
Jan

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

Re: GPS Leap Second Scheduled!

[Ethan O'Connor]

Roger Wolff wrote:

>Chris Wedgwood wrote:
>> On Wed, Sep 09, 1998 at 02:13:42PM -0600, Colin Plumb wrote:
>> 
>> > - gettimeofday() never returns the same value twice (documented BSD
>> >   behaviour)
>> 
>> Ouch... gettimeofday(2) only presently has usec resolution. I suspect
>> we can make this report the same value twice on really high end boxes
>> (667MHz Alpha maybe, 400Mhz Sparcs?), if not now, in a year or so.
>> Even a P.ii 600 or so can probably manage it.

>This is defined behaviour. On processors where gettimeofday can be
>called more than once in a microsecond (SMP systems, and fast
>systems), the kernel is required to keep a last-time-returned, and
>increment it and return that if the value calculated is below the
>stored value.

>If you have the results from two gettimeofday calls, you can always
>subtract them and divide by the result without checking for zero.
>That's what the spec says.

>A kernel will get into trouble if you keep on calling gettimeofday
>more than a million times a second..... 


Modifying Chris's code to call gettimeofday() 4 times
the second time around and to print the usec values 
for the four successive calls yields the following on
this system (SunOS 5.6, Ultra-IIi/333Mhz):

athena% a.out
213426
213426
213426
213427
athena% a.out
499126
499126
499127
499127

and even:

athena% a.out
947875
947875
947875
947875

Etc... 

FWIW.

-Ethan O'Connor
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

Re: GPS Leap Second Scheduled!

[Jamie Lokier]

On Wed, Sep 09, 1998 at 09:35:59AM -0700, David Lang wrote:
> I am probably missing something, but can't you just ignore the leap second
> until you discover that the time is 1 sec off and then use the normal NTP
> procedure to get back to the exact time

Until the NTP procedure discovers and corrects this (a few minutes, plus
correction time), anything that expects synchronised time between
machines can go wrong.

Admittedly synchronisation isn't perfect anyway.

-- Jamie

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

Re: GPS Leap Second Scheduled!

[Michael Shields]

In article <19980910073422.A13283@tantalophile.demon.co.uk>,
Jamie Lokier <lkd@tantalophile.demon.co.uk> wrote:
> On Wed, Sep 09, 1998 at 09:35:59AM -0700, David Lang wrote:
> > I am probably missing something, but can't you just ignore the leap second
> > until you discover that the time is 1 sec off and then use the normal NTP
> > procedure to get back to the exact time
> 
> Until the NTP procedure discovers and corrects this (a few minutes, plus
> correction time), anything that expects synchronised time between
> machines can go wrong.

NTP has the capability to know in advance that a leap second is
scheduled and act upon that at the correct time.

Check your logs the next time a leap second happens; xntpd does it.
-- 
Shields, CrossLink.

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

Re: GPS Leap Second Scheduled!

[Colin Plumb]

> Hence, the above equation would have the same value for 23:59:60 and
> 00:00:00 on the next day.  Hence, time() should return the same value.

The problem becomes more acute for gettimeofday() and the POSIX
ns-resolution equivalent, clock_gettime(CLOCK_REALTIME).

There are a few axioms that you'd like to have hold:

- time() and gettimeofday() return the same time as
  clock_gettime(CLOCK_REALTIME), as far as precision permits.
- gettimeofday() never returns the same value twice (documented BSD behaviour)
- no clock ever runs backwards

This makes the handling of the tv_usec or tv_nsec parts of the time during
a leap second a bit problematic.

One option is to count twice.
One option is to count at half speed during 23:59:60 and 0:00:00.
One option is to use the curve y = 1/4*x^3 - 3/4*x^2 + x to interpolate
y smoothly from 0 to 1 as x goes from 0 to 2.
One option is to freeze the fractional part fr one of the two seconds.
One (pretty rude) option is to count tv_usec from -1000000 to -1
during 23:59:60.  (tv_usec is a *signed* long.)

I don't know of a pretty way.  What I'd like, as I said, is a defined kludge,
so that there is a defined mapping between struct timeval and struct timespec
and UTC in the vicinity of a leap second.  This ensures that timestamps
collected on different machines can at least be compared, even if the
time intervals reported are incorrect.  ("Why were my ping times
half of usual at midnight last night?")
-- 
	-Colin

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

Re: GPS Leap Second Scheduled!

[Chris Wedgwood]

On Wed, Sep 09, 1998 at 02:13:42PM -0600, Colin Plumb wrote:

> - gettimeofday() never returns the same value twice (documented BSD
>   behaviour)

Ouch... gettimeofday(2) only presently has usec resolution. I suspect
we can make this report the same value twice on really high end boxes
(667MHz Alpha maybe, 400Mhz Sparcs?), if not now, in a year or so.
Even a P.ii 600 or so can probably manage it.

Sure... this is fixable and not hard to fix, but it requires breaking
binary compatibility.

The attached code on a PPro 200 gives me results of 2 usecs, using a
P.II 300 and SYSENTER semantics, you can probably get this to less
that 1usec.

> I don't know of a pretty way.  What I'd like, as I said, is a
> defined kludge, so that there is a defined mapping between struct
> timeval and struct timespec and UTC in the vicinity of a leap
> second.

I'm not sure about a sane kludge for mapping to/from the semantics we
already have, but how about we just declare the existing API buggy
under some (rare circumstances) and create a new one with flags to
show whether or not a leap second is currently under way, much the
same as is done for daylight savings time with time zones. (You can
have two 2:30ams, only one of which tough is DST, the other is
non-DST).



-Chris

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

Re: GPS Leap Second Scheduled!

[Chris Wedgwood]

[-- Attachment #1: Type: text/plain, Size: 247 bytes --]

On Thu, Sep 10, 1998 at 11:45:15AM +1200, Chris Wedgwood wrote:

> The attached code on a PPro 200 gives me results of 2 usecs, using a
> P.II 300 and SYSENTER semantics, you can probably get this to less
> that 1usec.

Crap... here it is.



-cw

[-- Attachment #2: tv-test.c --]
[-- Type: text/plain, Size: 438 bytes --]

#include <sys/time.h>
#include <unistd.h>
#include <stdio.h>

int	main()
{
	struct timeval	t1,t2,t3,t4;
	
	do{
		/* warm caches */
		gettimeofday(&t1,NULL);
		gettimeofday(&t2,NULL);
		gettimeofday(&t3,NULL);
		gettimeofday(&t4,NULL);

		gettimeofday(&t3,NULL);
		gettimeofday(&t4,NULL);
	}while(t3.tv_sec != t4.tv_sec); /* yuk */

	printf("%d usecs difference!\n",(int)(t4.tv_usec - t3.tv_usec));
	
	
	return	0;
}
                       

Re: GPS Leap Second Scheduled!

[Rogier Wolff]

Chris Wedgwood wrote:
> On Wed, Sep 09, 1998 at 02:13:42PM -0600, Colin Plumb wrote:
> 
> > - gettimeofday() never returns the same value twice (documented BSD
> >   behaviour)
> 
> Ouch... gettimeofday(2) only presently has usec resolution. I suspect
> we can make this report the same value twice on really high end boxes
> (667MHz Alpha maybe, 400Mhz Sparcs?), if not now, in a year or so.
> Even a P.ii 600 or so can probably manage it.

This is defined behaviour. On processors where gettimeofday can be
called more than once in a microsecond (SMP systems, and fast
systems), the kernel is required to keep a last-time-returned, and
increment it and return that if the value calculated is below the
stored value.

If you have the results from two gettimeofday calls, you can always
subtract them and divide by the result without checking for zero.
That's what the spec says.

A kernel will get into trouble if you keep on calling gettimeofday
more than a million times a second..... 

					Roger. 

-- 
| The secret of success is sincerity. Once you can |R.E.Wolff@BitWizard.nl 
| fake that, you've got it made. -- Jean Giraudoux | phone: +31-15-2137555 
We write Linux device drivers for any device you may have! fax: ..-2138217

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

Re: GPS Leap Second Scheduled!

[Oliver Xymoron]

On Thu, 10 Sep 1998, Rogier Wolff wrote:

> Chris Wedgwood wrote:
> > On Wed, Sep 09, 1998 at 02:13:42PM -0600, Colin Plumb wrote:
> > 
> > > - gettimeofday() never returns the same value twice (documented BSD
> > >   behaviour)
> > 
> > Ouch... gettimeofday(2) only presently has usec resolution. I suspect
> > we can make this report the same value twice on really high end boxes
> > (667MHz Alpha maybe, 400Mhz Sparcs?), if not now, in a year or so.
> > Even a P.ii 600 or so can probably manage it.
> 
> This is defined behaviour. On processors where gettimeofday can be
> called more than once in a microsecond (SMP systems, and fast
> systems), the kernel is required to keep a last-time-returned, and
> increment it and return that if the value calculated is below the
> stored value.

Seems wrong to bother the kernel with this at all. Any complexity here
should be put in libc. After all, the problem is largely with the ANSI C
spec.

Also, putting any of this 'hide the leap second' logic in the kernel makes
it more difficult to later add a consistent interface to libc as the
information is now hidden in the kernel. 

Finally, telling the kernel to schedule a leap second seems pretty ugly as
well.

--
 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 


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

Re: GPS Leap Second Scheduled!

[Ryan Moore]

On Thu, 10 Sep 1998, Oliver Xymoron wrote:
> Finally, telling the kernel to schedule a leap second seems pretty ugly as
> well.

Except that it's already doing it.  At least it is if you're running ntpd
or xntpd.  I've seen the Linux kernel do leap seconds on my machine
before.

In 2.0.35 at least, the code is in /usr/src/linux/kernel/sched.c
In function second_overflow().

The kernel even prints a log message:

printk(KERN_NOTICE "Clock: inserting leap second 23:59:60 UTC\n");

in one case and...

printk(KERN_NOTICE "Clock: deleting leap second 23:59:59 UTC\n");

in another.

--------------------------------
Ryan Moore    rmoore@rmoore.i.seawood.org



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

Re: GPS Leap Second Scheduled!

[H. Peter Anvin]

Followup to:  <98090822315400.00819@soda>
By author:    Andrej Presern <andrejp@luz.fe.uni-lj.si>
In newsgroup: linux.dev.kernel
> 
> Have you considered simply not scheduling any processes for one second and
> adjusting the time accordingly? (if one second chunk is too big, you can do it
> in several steps)
> 
> Andrej
> 

The way xntp deals with leap seconds is it lets the epoch
float... i.e. it holds time_t to the same value for two seconds.  One
proposal (which I like) was to compensate for this by allowing the
microsecond or nanosecond fields or struct timeval & co to advance to
1,999,999 µs or 1,999,999,999 ns in the case of such events.  The neat
thing is that the latter number fits very nicely in a 32-bit integer
even if someone (mis-) interprets it as signed.

	-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bahá'í -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misérables

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

Re: GPS Leap Second Scheduled!

[Chris Wedgwood]

On Wed, Sep 09, 1998 at 12:59:47AM +0000, H. Peter Anvin wrote:

> The way xntp deals with leap seconds is it lets the epoch float...
> i.e. it holds time_t to the same value for two seconds.

Cool... so 1970 becomes even longer ago that I would have assumed
then?



-cw



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

Re: GPS Leap Second Scheduled!

[H. Peter Anvin]

Followup to:  <199809092149.RAA06993@hilfy.ece.cmu.edu>
By author:    "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
In newsgroup: linux.dev.kernel
>
> In message <19980909200032.B13292@caffeine.ix.net.nz>, Chris Wedgwood writes:
> +-----
> | On Wed, Sep 09, 1998 at 12:59:47AM +0000, H. Peter Anvin wrote:
> | > The way xntp deals with leap seconds is it lets the epoch float...
> | > i.e. it holds time_t to the same value for two seconds.
> | Cool... so 1970 becomes even longer ago that I would have assumed
> | then?
> +--->8
> 
> That's the only semi-reasonable (I stress *semi-*) interpretation one can 
> give to the current standard.  The other possibilities are worse.
> 

Right.  I think the right solution is one I suggested on c.o.l.d.s
recently:

- time_t being a 64-bit signed integer linked to UTC
- struct timespec (and struct timeval, presumably) having an extra
  field added:

	64-bit seconds field (same as time_t) linked to UTC
	32-bit nanosecond field (microsecond for timeval) linked to TAI
	32-bit integral TAI-UTC difference

That way any moment in time will be uniquely derivable at least, at a
positive leap second, you will see the progression (where T means a
time_t value divisible by 86400):

	tv_sec		tv_delta	UTC

	T-3		N		23:59:57
	T-2		N		23:59:58
	T-1		N		23:59:59
	T-1		N+1		23:59:60
	T		N+1		00:00:00
	T+1		N+1		00:00:01
	T+2		N+1		00:00:02

... and for a negative leap second ...

	tv_sec		tv_delta

	T-3		N		23:59:57
	T-2		N		23:59:58
	T		N-1		00:00:00
	T+1		N-1		00:00:01
	T+2		N-1		00:00:02

We may want to have a testable bit that we're "in" a leap second for
the 23:59:60 case...

	-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
        I am Bahá'í -- ask me about it or see http://www.bahai.org/
   "To love another person is to see the face of God." -- Les Misérables

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

Re: GPS Leap Second Scheduled!

[Theodore Y. Ts'o]

   From: hpa@transmeta.com (H. Peter Anvin)
   Date: 	10 Sep 1998 01:37:05 GMT
   Right.  I think the right solution is one I suggested on c.o.l.d.s
   recently:

   - time_t being a 64-bit signed integer linked to UTC
   - struct timespec (and struct timeval, presumably) having an extra
     field added:

	   64-bit seconds field (same as time_t) linked to UTC
	   32-bit nanosecond field (microsecond for timeval) linked to TAI
	   32-bit integral TAI-UTC difference

This works, although it would require making a glibc interface change.
But if the ELF symbol versioning works out, perhaps this won't be as big
of an issue.

However, in order to in sync with POSIX.1's definition of how time_t relates to
UTC time, I'd suggest that we make the progression go as follows:

... making the progress go as follows:

	tv_sec		tv_delta	UTC
	   T-1		N		23:59:59
	   T		N		23:59:60
	   T		N+1		00:00:00
	   T+1		N+1		00:00:01

(that is, repeat tv_sec == T instead of tv_sec == T-1).

						- Ted

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

Re: GPS Leap Second Scheduled!

[Feuer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-user-defined, Size: 3000 bytes --]

 
H. Peter Anvin wrote:

> Followup to:  <199809092149.RAA06993@hilfy.ece.cmu.edu>
> By author:    "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
> In newsgroup: linux.dev.kernel
> >
> > In message <19980909200032.B13292@caffeine.ix.net.nz>, Chris Wedgwood writes:
> > +-----
> > | On Wed, Sep 09, 1998 at 12:59:47AM +0000, H. Peter Anvin wrote:
> > | > The way xntp deals with leap seconds is it lets the epoch float...
> > | > i.e. it holds time_t to the same value for two seconds.
> > | Cool... so 1970 becomes even longer ago that I would have assumed
> > | then?
> > +--->8
> >
> > That's the only semi-reasonable (I stress *semi-*) interpretation one can
> > give to the current standard.  The other possibilities are worse.
> >
>
> Right.  I think the right solution is one I suggested on c.o.l.d.s
> recently:
>
> - time_t being a 64-bit signed integer linked to UTC
> - struct timespec (and struct timeval, presumably) having an extra
>   field added:
>
>         64-bit seconds field (same as time_t) linked to UTC
>         32-bit nanosecond field (microsecond for timeval) linked to TAI
>         32-bit integral TAI-UTC difference
>
> That way any moment in time will be uniquely derivable at least, at a
> positive leap second, you will see the progression (where T means a
> time_t value divisible by 86400):
>  

Why would you have the TAI-UTC difference instead of just TAI?
The part of your message below was very confusing to me.
 
 

>  
>         tv_sec          tv_delta        UTC
>
>         T-3             N               23:59:57
>         T-2             N               23:59:58
>         T-1             N               23:59:59
>         T-1             N+1             23:59:60
>         T               N+1             00:00:00
>         T+1             N+1             00:00:01
>         T+2             N+1             00:00:02
>
> ... and for a negative leap second ...
>
>         tv_sec          tv_delta
>
>         T-3             N               23:59:57
>         T-2             N               23:59:58
>         T               N-1             00:00:00
>         T+1             N-1             00:00:01
>         T+2             N-1             00:00:02
>
> We may want to have a testable bit that we're "in" a leap second for
> the 23:59:60 case...
>
>         -hpa
>
> --
>     PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
>     See http://www.zytor.com/~hpa/ for web page and full PGP public key
>         I am Bahá'í -- ask me about it or see http://www.bahai.org/
>    "To love another person is to see the face of God." -- Les Misérables
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/faq.html


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

Re: GPS Leap Second Scheduled!

[David Lang]

-----BEGIN PGP SIGNED MESSAGE-----

I am probably missing something, but can't you just ignore the leap second
until you discover that the time is 1 sec off and then use the normal NTP
procedure to get back to the exact time

David Lang

On Tue, 8 Sep 1998, Andrej Presern wrote:

> Date: Tue, 8 Sep 1998 22:27:28 +0200
> From: Andrej Presern <andrejp@luz.fe.uni-lj.si>
> To: majordomo@vger.rutgers.edu,
     Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
> Cc: linux-kernel@vger.rutgers.edu
> Subject: Re: GPS Leap Second Scheduled!
> 
> On Mon, 07 Sep 1998, Ulrich Windl wrote:
> >(...About leap second handling in the Linux kernel...)
> >On 1 Sep 98, at 11:16, Sven Dietrich wrote:
> >> The GPS control segment has posted a leap second warning for week number
> >> 990, Day number 5, and thus it's official in GPS world,
> >> that the leap second will take place 12/31/98... 
> >> 
> >> I am going to run simulations on NTP 3 & 4 and Linux with that GPS almanac. 
> >> Will send bug fixes and patches as needed for the Trimble refclocks and
> >> NTP...
> >> 
> >> Linux currently inserts a 2nd 59th second, instead of the UTC model of ...
> >> 58, 59, 60...
> >
> >The time in the kernel is seconds since the epoch. To insert a second 
> >means that we'll have to delay the next second for another second. 
> >The other solution seems to be a clib -> kernel interface that knows 
> >that a leap second is active now. Then the clib could possibly 
> >convert the seconds to xx:yy:60. (I hope I did not overlook something 
> >obvious).
> 
> Have you considered simply not scheduling any processes for one second and
> adjusting the time accordingly? (if one second chunk is too big, you can do it
> in several steps)
> 
> Andrej
> 
> --
> Andrej Presern, andrejp@luz.fe.uni-lj.si
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/faq.html
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQEVAwUBNfaucj7msCGEppcbAQGFkQf/WSuUbkLPd2sfQ99FgjoOcRox47ZUV6rr
c6Yj6rfIhMXpCqzRcqyNa7JS3mTK+8Z3/9Pu1WbEU/MdZrgvvorCyq9k795V8tr6
GX2EqEoVt87uhAiBRdzMi9XREsWi8hTK/yr0RRAQKhP/bLcGvjcrmDvlUR6fEBic
jo026QXPYN4mIhyf6kIyXBmrh9dOr9EFvYYz7Lr13nwa9NjA5tlOOoSDDmG8tobz
hmgRcSE93OJgoVDwOwUcgC2thH6x0MBMYCfp/c2TWQ9cYaI4dVTlEeJWKjQTTp2I
hDsW/RjLWycR5k7PnRV002Lm6+Dxxl/ajwINgpm0S52qDJleAo+eUw==
=pxxv
-----END PGP SIGNATURE-----


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