public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: GPS Leap Second Scheduled!
@ 1998-09-09 20:13 Colin Plumb
  1998-09-09 23:45 ` Chris Wedgwood
  0 siblings, 1 reply; 18+ messages in thread
From: Colin Plumb @ 1998-09-09 20:13 UTC (permalink / raw)
  To: tytso; +Cc: andrejp, linux-kernel

> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread
[parent not found: <19980914165757.A17479@tantalophile.demon.co.uk>]
* Re: GPS Leap Second Scheduled!
@ 1998-09-11 22:49 Ethan O'Connor
  0 siblings, 0 replies; 18+ messages in thread
From: Ethan O'Connor @ 1998-09-11 22:49 UTC (permalink / raw)
  To: R.E.Wolff; +Cc: linux-kernel, chris

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
[parent not found: <no.id>]
[parent not found: <299BBE59294E@rkdvmks1.ngate.uni-regensburg.de>]
* Re: GPS Leap Second Scheduled!
@ 1998-09-09  4:46 Colin Plumb
  1998-09-09 19:08 ` Theodore Y. Ts'o
  0 siblings, 1 reply; 18+ messages in thread
From: Colin Plumb @ 1998-09-09  4:46 UTC (permalink / raw)
  To: andrejp; +Cc: linux-kernel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~1998-09-17  8:43 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
1998-09-09 20:13 GPS Leap Second Scheduled! Colin Plumb
1998-09-09 23:45 ` Chris Wedgwood
1998-09-09 23:55   ` Chris Wedgwood
1998-09-10  8:36   ` Rogier Wolff
1998-09-10 17:05     ` Oliver Xymoron
1998-09-10 22:02       ` Ryan Moore
     [not found] <19980914165757.A17479@tantalophile.demon.co.uk>
     [not found] ` <199809150603.XAA29073@cesium.transmeta.com>
     [not found]   ` <19980915100729.02790@albireo.ucw.cz>
     [not found]     ` <35FF1838.6E247F0C@his.com>
1998-09-17 11:51       ` Jan Echternach
  -- strict thread matches above, loose matches on Subject: below --
1998-09-11 22:49 Ethan O'Connor
     [not found] <no.id>
1998-09-10  6:34 ` Jamie Lokier
1998-09-11  6:18   ` Michael Shields
     [not found] <299BBE59294E@rkdvmks1.ngate.uni-regensburg.de>
     [not found] ` <98090822315400.00819@soda>
1998-09-09  0:59   ` H. Peter Anvin
1998-09-09  8:00     ` Chris Wedgwood
     [not found]       ` <199809092149.RAA06993@hilfy.ece.cmu.edu>
1998-09-10  1:37         ` H. Peter Anvin
1998-09-10 15:05           ` Theodore Y. Ts'o
1998-09-12 19:57           ` Feuer
1998-09-09 16:35   ` David Lang
1998-09-09  4:46 Colin Plumb
1998-09-09 19:08 ` Theodore Y. Ts'o

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox