On Sat, 6 Jan 2007, M. Warner Losh wrote:
OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance.
That's why leap second handling should be done in
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: OSes usually deal with timestamps all the time for various things. To
: find out how much CPU to bill a process, to more mondane things.
: Having to do all these
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.
In message [EMAIL PROTECTED], Tony Fin
ch writes:
On Sat, 6 Jan 2007, M. Warner Losh wrote:
OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance.
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] 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.
In message [EMAIL PROTECTED], Rob Seaman writes:
Warner Losh wrote:
leap seconds break that rule if one does things in UTC such that
the naive math just works
POSIX time handling just sucks for no good reason.
I've said it before, and I'll say it again:
There are two problems:
1. We
On Sat 2007-01-06T19:36:19 +, Poul-Henning Kamp hath writ:
There are two problems:
1. We get too short notice about leap-seconds.
2. POSIX and other standards cannot invent their UTC timescales.
This is not fair, for there is a more fundamental problem:
No two clocks can
In message [EMAIL PROTECTED], Steve Allen writes:
On Sat 2007-01-06T19:36:19 +, Poul-Henning Kamp hath writ:
There are two problems:
1. We get too short notice about leap-seconds.
2. POSIX and other standards cannot invent their UTC timescales.
This is not fair, for there
On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:
B. i) Issue leapseconds with at least twenty times longer
notice.
This plan might not be so good from a software engineering point of
view. Inevitably software authors would hard-code the known table,
and then the software would fail
On Sat, 6 Jan 2007, Steve Allen wrote:
No two clocks can ever stay in agreement.
I don't think that statement is useful. Most people have a concept of
accuracy within certain tolerances, dependent on the quality of the clock
and its discipline mechanisms. For most purposes a computer's clock
On Jan 6, 2007, at 13:47, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED],
Ashley Yakeley
writes:
On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:
B. i) Issue leapseconds with at least twenty times longer
notice.
This plan might not be so good from a software engineering
In message [EMAIL PROTECTED], Ashley Yakeley
writes:
Not necessarily. After seven months, or even after two years, there's
a better chance that the product is still in active maintenance.
Better to find that particular bug early, if someone's been so
foolish as to hard-code a leap-second table.
On Jan 6, 2007, at 14:43, Poul-Henning Kamp wrote:
So you think it is appropriate to demand that ever computer with a
clock should suffer biannual software upgrades if it is not connected
to a network where it can get NTP or similar service ?
Since that's the consequence of hard-coding a
On Jan 6, 2007, at 16:18, M. Warner Losh wrote:
Unfortunately, the kernel has to have a notion of time stepping around
a leap-second if it implements ntp. There's no way around that that
isn't horribly expensive or difficult to code. The reasons for the
kernel's need to know have been
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: On Jan 6, 2007, at 16:18, M. Warner Losh wrote:
:
: Unfortunately, the kernel has to have a notion of time stepping around
: a leap-second if it implements ntp. There's no way around that that
: isn't horribly
Warner Losh wrote:
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.
Every IP packet has a 1's complement checksum. (That not all
On Sat, 6 Jan 2007, Ashley Yakeley wrote:
Presumably it only needs to know the next leap-second to do this, not
the whole known table?
Kernels sometimes need to deal with historical timestamps (principally
from the filesystem) so it'll need a full table to be able to convert
between POSIX time
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh wrote:
: 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
18 matches
Mail list logo
