Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-06 Thread Rob Seaman
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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.

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-06 Thread Steve Allen
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

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Ashley Yakeley [EMAIL PROTECTED] writes: : On Jan 6, 2007, at 08:35, M. Warner Losh wrote: : : So for the foreseeable future, : timestamps in OSes will be a count of seconds and a fractional second : part. That's not going to change anytime soon even

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-06 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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