Re: [LEAPSECS] Leap Sec vs Y2K
Then you must also pity 99.999% of the software users on the planet all of which are not affected by missing NTP configurations. Really? OSX ships with a functional NTP configuration, enabled by default, as do most Apple odds and ends (Airports, particularly). In order to have an OSX machine that is _not_ synch'd to UTC you'd need to take special action (and outbound firewalls that drop specific protocols are rare). Windows Time Service isn't as good by default, but it maintains resolution of a few seconds over a network (and has to, because otherwise AD/Kerberos) will hit trouble.Windows ships with the ability to synch the clock coarsely to the outside world (http://www.microsoft.com/windowsxp/using/setup/maintain/setclock.mspx) and it's usually turned on as part of group policy unless the AD server is acting as a clock reference. Even if home environments, it's routinely turned on. As a simple check, today it's very rare indeed to sort messages by the header Date: field and find that it yields an orders that scrambles a conversation, which imples that globally clocks are synch'd to at least the turnaround time in an email conversation, and that wasn't true in the past (yes, I realise the rise of WebMail services is a factor in this as well). There have been several incidents of consumer CPE automatically synching via NTP to unsuspecting public-access server including, oh, look, our very own Paul-Henning Kamp to whom you are responding (http://www.engadget.com/2006/04/09/danish-server-admin-exposes-d-links-ntp-vandalism/). Indeed, today, I'd be surprised if there were many homes that didn't have a stratum-three ntp server, such is its prevalence in CPE. I'm surprised by your claim that Telcos don't do NTP, because my first dealings with NTP twenty-odd years ago were related to a major European telco who insisted that all management systems by synchronised, partly because of the legal implications of getting billing time-periods wrong and partly because of the need to do log correlation for event handling, and every telco project I've been involved in since has had sub-1s resolution and precision timestamping in the specification. ian ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Sat 2010-12-11T08:18:54 +, Poul-Henning Kamp hath writ: I have a script that dumps the timestamps of each of a number of servers where I work; this is a recent result: Those clocks span about 10 seconds. Why are you not running NTP properly ? That question is not fair without further investigation. If those are Windows boxes then even wikipedia says that's normal. http://en.wikipedia.org/wiki/Network_Time_Protocol#Microsoft_Windows (Note that this is not a deficiency of Windows per se, but rather an indication that Windows runs on almost anything, including some motherboards with piece-of-crap designs for the system clock.) I have a Windows XP box which drifts by about 3000 ppm, but only when the guide camera application is running. W32Time is utterly incapable of keeping this system on time, so I tried one of the implementations of the current NTP code. Given that the maximum drift allowed by NTP is 500 ppm it is also not capable of keeping the system clock any closer than a nasty sawtooth waveform with an amplitude of around a second. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
I'm surprised by your claim that Telcos don't do NTP, [...] I'm sure many do. My point is that, if one's starting premise is that most systems in the world *require* second-accurate syncronization, this is simply untrue. In fact most work perfectly well even when they drift by minutes, and a significant portion of critical systems do drift by minutes in practice. This is orders of magnitude more error than any leap second. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
This is orders of magnitude more error than any leap second. One problem with the kinda works attitude is that is a barrier to entry for people whose systems need to work correctly to a much higher I agree: the kinda works attitude is indeed such a barrier. However the kinda works attitude is not like a bug in a piece of software that you can fix in the next version. Attitudes are entrenched into culture and changing culture is the MOST difficult thing to change. Premising ANY solution on a change in culture is really silly. Computer scientists everywhere need to accept that they are the elite, that everyone else is stupid, and that this is the way it is going to stay, FOREVER. Apply this principle as follows: ACCEPT that there are servers and desktops all over the world are MISCONFIGURED and do NOT have second-accurate syncronization, and are NEVER going to have second-accurate syncronization. Most of the software industry accepted this fact decades ago along with hundreds of other limitations that software everywhere is written to work around. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] Appropriate technology
On Dec 11, 2010, at 1:32 PM, Warner Losh wrote: That's one reason why you're seeing the push back from people on this list: many have tried to deploy systems where sub-second synchronization was required by the application and have run into many problems... May I point out that the current squabble has nothing to do with the astronomers in the room? (And precious little to do with leap seconds.) Astronomers (or at least astronomical software engineers) tend to love NTP - to the extent that we're willing to put up with some poor implementations on bizarre legacy equipment. (The algorithms may drive some to distraction, however - strongly recommend Dave Mills' book.) This rather terse conference paper: http://www.adass.org/adass/proceedings/adass96/reprints/seamanr2.ps.gz describes a project from the mid-1990's that relied on NTP (not described since I only had 4 pages), to provide a timescale precise to 0.01s (SunOS Sparc). I didn't run into any significant problems that I recall. This was an appropriate technology project on both the computer science and astronomy sides. Pragmatic choices (eg, using a heliocentric correction instead of barycentric - Earth's motion was transverse and Jupiter's lever arm was minimal) made the implementation simpler and more robust. NTP served extremely well - and that host is still in service and has been running NTP with zero headaches (from NTP) for 15 years since. (The particular camera relies on an S-bus interface card that emulates an even older DEC standard.) In the mean time the observatory's NTP stratum architecture has been rearranged any number of times, for instance to relayer on GPS receivers. Our telescopes support quite a few cameras built by outside groups. One of the several requirements is that the data acquisition host run NTP. I'm responsible for the initial archival data capture. NTP provides a reliable timestamp from a clock synchronized mountain-wide and across continents. The host computers are a wide range of vintages and operating systems (though I admit I only see the data from the PC-driven cameras after it crosses to the inevitable Linux box). NTP runs fine on various MacOS servers, too. This debate about the necessary requirements for civil timekeeping has been artificially cast as a disagreement between astronomers and computer scientists. Rather, timekeeping is a complex issue for all communities. The question is how to make the appropriate pragmatic choices. Pretending there's only one kind of time is not pragmatic. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
In message 1292102703.24926.29.ca...@localhost, Paul Sheer writes: Apply this principle as follows: ACCEPT that there are servers and desktops all over the world are MISCONFIGURED and do NOT have second-accurate syncronization, and are NEVER going to have second-accurate syncronization. Ohh we do, we most certainly do. But that does not allow us to ignore the servers which are synchronized and which need to be synchronized to work. Poul-Henning PS: Your caps-lock seems to be flakey. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Dec 11, 2010, at 1:32 PM, Warner Losh wrote: So the magnitude of this kinda works degrades as the time synchronization between systems gets worse. Kinda works - you could be describing UTC redefined without leap seconds :-) Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
This is because by-and-large software is written for the lowest common denominator. I am reminded of Spinal Tap's We're cancelled in Boston, but don't worry, it's not a big college town. Examples of protocols that get distinctly tetchy in the face of poor clock synch are, as has already been mentioned without seeming to upset your certainty, NFS (the computing glue of the nineties) and Kerberos/AD (the computing glue of the noughties). The fomer needs clock synch except the documentation doesn't tell you (until you find make misbehaving because mtimes are being set by the client, not the server), and the latter documents it and drove the adoption of better time synch. How you can use phrase like by and large when you're having to ignore two of the most significant distributed protocols of the past twenty years is something of a mystery. ian ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On 12/11/2010 17:18, Poul-Henning Kamp wrote: In message1292109115.24926.42.ca...@localhost, Paul Sheer writes: On Sat, 2010-12-11 at 22:35 +, Poul-Henning Kamp wrote: But that does not allow us to ignore the servers which are synchronized and which need to be synchronized to work. I disagree. It very much allows us to ignore those servers from a standards point of view. Which bit of need don't you understand ? Are you happy with the ATC servers used to land your plane being within some minutes of each other ? Yes. We sometimes can ignore those machines that don't care. However, if those machines drive the time-keeping software on the machines we use, then we do care about them. Some machines can tolerate minutes of difference, but some machines cannot tolerate even millisecond skew. The former can't be used to justify it being impossible to build the latter. ATC systems being unsynchronized means that planes crash; clearly a situation we want to avoid. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
Which bit of need don't you understand ? Are you happy with the ATC servers used to land your plane being within some minutes of each other ? There are two choices: A. the software was written to be safe assuming precise time syncronization AND the time was reliably and precisely syncronized. B. the software was written to be safe regardless of poor time syncronization. I choose the solution that makes my flight the cheepest. -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Dec 11, 2010, at 6:36 PM, Warner Losh wrote: ATC systems being unsynchronized means that planes crash; clearly a situation we want to avoid. Presumably they do have layers on layers of error handling built in, as well as contingent procedures - perhaps even traditional sextant navigation relying on access to a timescale that approximates Greenwich Mean Time :-) It is possible for brittle system design as well as sloppy timekeeping to both be undesirable... Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap Sec vs Y2K
On Sun, 2010-12-12 at 01:20 +, Ian Batten wrote: This is because by-and-large software is written for the lowest common denominator. NFS (the computing glue of the nineties) and Kerberos/AD (the computing glue of the noughties). [...] please understand that I am only trying to break up the illusion that all the worlds computer clocks tick over in unison. indeed with these protocols, can I guess that, 1. syncronization is only required to within a couple of seconds 2. syncronization is only required between client and server within the local LAN. 3. syncronization does not need to absolutely represent real time. 4. leap seconds, or the absence thereof, make no difference -paul ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
