- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]

From: M. Warner Losh <imp_at_BSDIMP.COM>

Date: Sat, 06 Jan 2007 12:37:01 -0700 (MST)

In message: <CCCCEA4B-3E55-444D-8B0A-A7CDA0D67687_at_noao.edu>

Rob Seaman <seaman_at_NOAO.EDU> writes:

: Warner Losh wrote:

:

: > leap seconds break that rule if one does things in UTC such that

: > the naive math just works

:

: All civil timekeeping, and most precision timekeeping, requires only

: pretty naive math. Whatever the problem is - or is not - with leap

: seconds, it isn't the arithmetic involved. Take a look a SETI_at_Home

: and other BOINC projects. Modern computers have firepower to burn in

: fluff like live 3-D screensavers. POSIX time handling just sucks for

: no good reason. Other system interfaces successfully implement

: significantly more stringent facilities.

But modern servers and routers don't. Anything that makes the math

harder (more computationally expensive) can have huge effects on

performance in these areas. That's because the math is done so often

that any little change causes big headaches.

: Expecting to be able to "naively" subtract timestamps to compute an

: accurate interval reminds me of expecting to be able to naively stuff

: pointers into integer datatypes and have nothing ever go wrong.

Well, the kernel doesn't expect to be able to do that. Internally,

all the FreeBSD kernel does is time based on a monotonically

increasing second count since boot. When time is returned, it is

adjusted to the right wall time. The kernel only worries about leap

seconds when time is incremented, since the ntpd portion in the kernel

needs to return special things during the leap second. If there were

no leapseconds, then even that computation could be eliminated. One

might think that one could 'defer' this work to gettimeofday and

friends, but that turns out to not be possible (or at least it is much

more inefficient to do it there).

Since the interface to the kernel is time_t, there's really no chance

for the kernel to do anything smarter with leapseconds. gettimeofday,

time and clock_gettime all return a time_t in different flavors.

In short, you are taking things out of context and drawing the wrong

conclusion about what is done. It is these complications, which I've

had to deal with over the past 7 years, that have lead me to the

understanding of the complications. Espeically the 'non-uniform radix

crap' that's in UTC. It really does complicate things in a number of

places that you wouldn't think. To dimissively suggest it is only a

problem when subtracting two numbers to get an interval time is to

completely misunderstand the complications that leapseconds introduce

into systems and the unexpected places where they pop up. Really, it

is a lot more complicated than just the 'simple' case you've latched

onto.

: A

: strongly typed language might even overload the subtraction of UTC

: typed variables with the correct time-of-day to interval

: calculations.

Kernels aren't written in these languages. To base one's arugments

about what the right type for time is that is predicated on these

langauges is a non-starter.

: But then, what should one expect the subtraction of

: Earth orientation values to return but some sort of angle, not an

: interval?

These are a specialized thing that kernels don't care about.

Warner

Received on Sat Jan 06 2007 - 11:38:56 PST

Date: Sat, 06 Jan 2007 12:37:01 -0700 (MST)

In message: <CCCCEA4B-3E55-444D-8B0A-A7CDA0D67687_at_noao.edu>

Rob Seaman <seaman_at_NOAO.EDU> writes:

: Warner Losh wrote:

:

: > leap seconds break that rule if one does things in UTC such that

: > the naive math just works

:

: All civil timekeeping, and most precision timekeeping, requires only

: pretty naive math. Whatever the problem is - or is not - with leap

: seconds, it isn't the arithmetic involved. Take a look a SETI_at_Home

: and other BOINC projects. Modern computers have firepower to burn in

: fluff like live 3-D screensavers. POSIX time handling just sucks for

: no good reason. Other system interfaces successfully implement

: significantly more stringent facilities.

But modern servers and routers don't. Anything that makes the math

harder (more computationally expensive) can have huge effects on

performance in these areas. That's because the math is done so often

that any little change causes big headaches.

: Expecting to be able to "naively" subtract timestamps to compute an

: accurate interval reminds me of expecting to be able to naively stuff

: pointers into integer datatypes and have nothing ever go wrong.

Well, the kernel doesn't expect to be able to do that. Internally,

all the FreeBSD kernel does is time based on a monotonically

increasing second count since boot. When time is returned, it is

adjusted to the right wall time. The kernel only worries about leap

seconds when time is incremented, since the ntpd portion in the kernel

needs to return special things during the leap second. If there were

no leapseconds, then even that computation could be eliminated. One

might think that one could 'defer' this work to gettimeofday and

friends, but that turns out to not be possible (or at least it is much

more inefficient to do it there).

Since the interface to the kernel is time_t, there's really no chance

for the kernel to do anything smarter with leapseconds. gettimeofday,

time and clock_gettime all return a time_t in different flavors.

In short, you are taking things out of context and drawing the wrong

conclusion about what is done. It is these complications, which I've

had to deal with over the past 7 years, that have lead me to the

understanding of the complications. Espeically the 'non-uniform radix

crap' that's in UTC. It really does complicate things in a number of

places that you wouldn't think. To dimissively suggest it is only a

problem when subtracting two numbers to get an interval time is to

completely misunderstand the complications that leapseconds introduce

into systems and the unexpected places where they pop up. Really, it

is a lot more complicated than just the 'simple' case you've latched

onto.

: A

: strongly typed language might even overload the subtraction of UTC

: typed variables with the correct time-of-day to interval

: calculations.

Kernels aren't written in these languages. To base one's arugments

about what the right type for time is that is predicated on these

langauges is a non-starter.

: But then, what should one expect the subtraction of

: Earth orientation values to return but some sort of angle, not an

: interval?

These are a specialized thing that kernels don't care about.

Warner

Received on Sat Jan 06 2007 - 11:38:56 PST

*
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT
*