> 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
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
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
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 |[email protected]
| 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
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.."
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 [email protected]