Re: [time-nuts] Time security musing - attacking the clock itself
On Dec 3, 2012, at 11:27 PM, Hal Murray wrote: li...@lazygranch.com said: Now a phone has accurate network time, so they could get really tricky with the time as part of the code. Are you sure? I don't have a smart phone, but I've heard various war stories of crappy time keeping. I assume the time was coming from an ap rather than the local cell tower. Yes. Cell phone networks that use CDMA require sub-millisecond synchronization between the handset and the tower to work. The sub-millisecond metric is for 2G generation, I don't know if that's gotten tighter or not. The cell chips don't necessarily publish the time to the SoC that's inside the cell phone, so they are left to synchronize sometimes via ntp or catch as catch can. There's also other time protocols layered over the CDMA network, but those can require operator intervention (== crap). I don't know if those are still in use, since my last professional brush with the CDMA network was in the 2G time frame. I don't know anything about GSM from direct experience, but I've been told similar things hold in the GSM network... Cell signal jamming could be an attack vector though. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Magnus at NIST
On Jul 3, 2012, at 12:39 AM, Magnus Danielson wrote: On 07/03/2012 04:03 AM, Tom Knox wrote: Magnus seen here in his recent trip to NIST is an obvious giant in the field of Time and Freq Metrology. Shown here in Peak Search mode. Despite the name, Flatirons has a peak, and I found it. Are they letting people in now, or is the fire still smoldering so access is restricted :( Boulder is a fun place regardless... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Method for comparing oscillators
In message: ece7a93bd093e1439c20020fbe87c47feb74c94...@altphyembevsp20.res.ad.jpl Lux, Jim (337C) james.p@jpl.nasa.gov writes: : : Bruce, : : Thanks, that looks interesting. I found the manual here... : http://www.symmetricom.com/media/files/support/ttm/product- : manual/5120A-MAN.pdf : : But I haven't figured out where to get a list of related patents. Can : anyone provide key number(s) or point me to a list? : : : http://www.uspto.gov/ : : patent search : quick : symmetricom in Assignee Name : : : 47 patents assigned to symmetricom. : : To be honest, though, none of the titles look relevant. : : You might need to search on the name of someone who worked on it, or the company that originally developed it. : : For instance, S.R. Stein signed the DoC, and is also a co-author of the paper they cite. Sam Stein works for Symmetricom these days. Many of the patents might be under Timing Solutions, the name of his old company. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Motorola M12+ or M12M questions
In message: 4a533c36.1030...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : There are (at least) three interpretations of when leap-seconds may be : inserted: : 1) At the end of every month. This is the ITU standard. It says that leap seconds can be inserted at the end of each month. Almost no gear allows this, and the gear that does doesn't always do it in a sane way. : 2) At the end of every quarter. This is also ITU standard. These are the secondary times. They have never been used. : 3) At the end of every half-year. These are the primary times. : GPS is operated under the assumption that case 3 holds. Why is this the case? The GPS data just tells you which week the next leap second will happen, as well as the last time a leap second happened. How is it the case that you can say that 3 holds? : There exist equipment assuming that case 2 holds. : The actual definition allows for case 1, making case 3 the primary : preference and case 2 the secondary preference. Yes. : Lovely mess, isn't it? Leap seconds are evil and must die. For such a simple thing, there's so much complication that getting leap seconds right can be rather hard. At least there's no leap second this December... : Anyway, if I don't recall it incorrectly (OK lazy to check), the GPS : signal actually indicate WHEN then upcomming leap second will occur. : This reduces to a up-comming leap second flag out of the GPS OEM board : which can trigger pre-maturely execution of leap-second algorithm on the : timing receiver, as we have seen in the Z3801A for instance. You are correct. There's an indication when the next leap second will happen. The Z3801A uses this to turn on a simple 'leap second pending' which causes a leap second to happen at the next leap second opportunity rather than at the week published. The GPS operators turn on next leap second about 4 or 5 months early, which triggers the bug. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS Week 1536 causing problems?
In message: 4a52bd4f.5020...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : Hal Murray wrote: : Anyone else lose an 18x? : : I lost one a while ago. Similar. It just stopped doing anything : useful. : : Battery failure? : : I don't think it has a battery inside. That seems like a poor design. Too : many reasonable use cases would include sitting in a drawer for extended : periods of time. : : Providing an RTC has benefits, especially when considering week-rollover : issues, since when the receiver wakes up it has no idea of date at all, : pulling in the RTC time and date is a sufficient hint, and adjusting : with detailed info from the GPS is a trivial extention. Then adjusting : the RTC is not a hard thing to do every once in a while. The same : problem could also be solved using EEPROM space. A byte would suffice. Usually, you're right. There's one case that might make it not suitable. Many contracts require spares for all the important gear. Long storage times makes storing the last known date ineffective. Of course in this case long is on the order of 9-odd years. This may be good for many applications, but not necessarily ones that have 10 or 15 year deep spares requirements... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] [Fwd: GPS 256 week rollover may be causing problems for some GPS receivers]
In message: 4a3bf553.20...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : Have any of you seen the reported problems? These counts started at 0 roughly at midnight UTC 6 Jan 1980 What does roughly mean here in this context? Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] [Fwd: GPS 256 week rollover may be causing problems for some GPS receivers]
In message: 4813.1245444...@critter.freebsd.dk Poul-Henning Kamp p...@phk.freebsd.dk writes: : In message 20090619.143448.2102305600@bsdimp.com, M. Warner Losh writes : : : In message: 4a3bf553.20...@rubidium.dyndns.org : Magnus Danielson mag...@rubidium.dyndns.org writes: : : Have any of you seen the reported problems? : : These counts started at 0 roughly at midnight UTC 6 Jan 1980 : : What does roughly mean here in this context? : : That the we have leap seconds. But midnight UTC time on 6 Jan 1980 was exactly the same thing as second 0 in GPS time. Leap seconds, while an evil complication to UTC, don't enter the synchronization point issue at all. It wasn't even Jan 1 when the leap second might have happened... Hence my confusion... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Z3805 initial behaviour after power up revised
In message: paejknppigmndlmjlenmgefjhnaa.frle...@verizon.net Francesco Ledda frle...@verizon.net writes: : Aging cannot be predicted! If it could be predicetd, there would be no : aging. Actually, if aging could be predicted perfectly, there'd be perfect holdover (which I think is saying the same thing). Aging can be predicted imperfectly in the short term, but the amount of imperfect grows with the time you're without data... Warner : : -Original Message- : From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com]on : Behalf Of Ulrich Bangert : Sent: Thursday, June 18, 2009 3:04 AM : To: 'Discussion of precise time and frequency measurement' : Subject: [time-nuts] Z3805 initial behaviour after power up revised : : : Gents, : : one of the papers suggested by Brian says: : --- : SmartClock monitors the frequency control variable of the internal : oscillator while it is locked to the external reference. This gives a : measure of the frequency difference between the internal oscillator, if it : is free-running, and the external reference over time. The resulting : measurements include the effects of random noise in the oscillator, the : measurement circuitry, and any noise in the external reference as well as : any aging and environmental effects in the oscillator. From this : information, SmartClock makes a continuous prediction of clock error over : time. : --- : : The big question is: If the EFC signal includes this all information, how : does the algo manage to extract the individual informations? After having a : look at the PPS TI and the EFC of my Z3805 I am beginning to get a clue of : it (the quirks on the EFC signal heve been removed): : : The SmartClock algo seems to set the loop time constants to a large value in : the beginning. In other words: It measures the overall oscillator frequency : influencing effects with a lowpass filter applied that has a very low cutoff : frequency. Only effects which's frequency are sufficient lower then the : cutoff pass the filter. Seems as if the SmartClock uses this filter setting : to exclude any noise related effect and any environmental effect and make : the measurement see ONLY the oscillator's aging. : : Once it has learned enough about the aging process it will be able to : predict aging. Having reached this state it will be able to apply his : knowledge about aging to further TI measurements and subtract the aging : part of it, leaving mostly the environmental (which is mostly temperature) : part. : : Having a model for the aging the Algo can now model the temperature : dependence. However, a precondition for this were that the measurement sees : the temperature effects and that the ambient temperature is measured : independently. For that reason I expect the Algo will reduce its loop time : constant within the next time to make the temperature effect get through the : lowpass. Any bets on that? : : Best regards : Ulrich Bangert : : -Ursprungliche Nachricht- : Von: time-nuts-boun...@febo.com : [mailto:time-nuts-boun...@febo.com] Im Auftrag von Ulrich Bangert : Gesendet: Donnerstag, 18. Juni 2009 08:29 : An: 'Discussion of precise time and frequency measurement' : Betreff: Re: [time-nuts] Z3805 initial behaviour after power up : : : Brian, : : You may also want to search for HP An1279, it also goes over HP : smartclock operation, and look for a paper titled the Global : Positioning System and HP SmartClock by John A. Kusters. : : In the meantime I have not only found these but also Smart : Clock: A New Time by David Allan et al which shows that : Smart Clock is originally a NIST invention patent and : explains very well how it works. Perhaps what I and You have : seen is a direct consequence of applying the Smart Clock algorithm. : : Best regards : Ulrich : : : -Ursprungliche Nachricht- : Von: time-nuts-boun...@febo.com : [mailto:time-nuts-boun...@febo.com] Im Auftrag von Brian Kirby : Gesendet: Donnerstag, 18. Juni 2009 01:51 : An: Discussion of precise time and frequency measurement : Betreff: Re: [time-nuts] Z3805 initial behaviour after power up : : : They do not talk about driving the frequency off, but they : warn to keep : the receiver locked the first 24 hours, so it can determine how the : oscillator ages. Its in the section on holdover (page 52 : of the PDF , : page 3-8 of the user guide). : : You may also want to search for HP An1279, it also goes over HP : smartclock operation, and look for a paper titled the Global : Positioning System and HP SmartClock by John A. Kusters. : : If you have a broadband connection, I can email you each : one, if that : will help. : : Brian : : Ulrich Bangert wrote: :Brian, : :thanks for your information! : : :algorithm. From what I read about the smart clock, it : takes 5
Re: [time-nuts] FE-5680A heat sink
In message: 4a2d60a2.3030...@erols.com Chuck Harris cfhar...@erols.com writes: : I'm pretty sure that mornings should be banned. Perty much... Nobody has a breathalizer to ensure that you are sufficiently caffeinated to give a good chance of a coherent reply :) Lord know that would have saved me much embarrassment over the years... However, since this is time-nuts, and we do deal with things on the hairy edge of what is possible, I'm sure someone will point to a side project that they've done that does just this, with schematics available for download form their web site :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
In message: c63ec123.7f8b%james.p@jpl.nasa.gov
Lux, James P james.p@jpl.nasa.gov writes:
:
:
:
: On 5/24/09 8:32 AM, Bob Paddock bob.padd...@gmail.com wrote:
:
: A 33.31 format would buy us a century, still allow us to get
: nanoseconds right, but it be computationally inconvenient and
: looks messy, so people balk at it.
:
: Anything wrong with TAI64NA?
:
: http://cr.yp.to/libtai.html
:
: libtai is a library for storing and manipulating dates and times.
:
: libtai supports two time scales: (1) TAI64, covering a few hundred
: billion years with 1-second precision; (2) TAI64NA, covering the same
: period with 1-attosecond precision. Both scales are defined in terms
: of TAI, the current international real time standard.
:
: TAI64NA in FPGA?
:
:
: Of course...buried in the install notes
:
: But keep in mind that this is a very early release. Some of
: the code hasn't been tested at all!
:
: As of 1998...
:
: It also breaks the time up into seconds, nanoseconds, and attoseconds, as
: separate chunks, so math isn't trivial
:
: struct taia {
: struct tai sec;
: unsigned long nano; /* 0...9 */
: unsigned long atto; /* 0...9 */
: } ;
:
:
: I don't think this library buys you a whole lot (other than useful routines
: to do things like calculate easter or leap days/seconds), but at the basic
: how does one keep time level, not particularly an improvement.
:
:
: Also, someone I was discussing this with at work reminded me of a common
: problem. We often run tests in a testbed where we need to have the entire
: testbed running at some time *not the actual time*.. E.g. If you're
: simulating a Mars entry,descent,landing scenario, you want the spacecraft
: running with time at the expected EDL time. But, you want to have
: everybody sync'd to a common source.
:
: So, it's easy to get all the computers controlling the test gear sync'd to
: UTC or TAI using something like NTP, but you need a way to have precision
: simulated time as well.
We did something akin to this at a previous employer. On the whole,
we found that math was more compute intensive than the fractional
method that phk recommends, but that the presentation to the user was
easier with this break down. We opted to stick with this breakdown.
The other problem you run into is that you're often given a time in
UTC time, but need to operate on TAI time so that you kick something
every second and aren't affected by leap seconds. There are many
other time scales that are in use that you can get data from as well.
Plus many different conventions for dealing with things (like an
fractional MJD: is that always computed with / 86400 or do you use
/86401 on positive leap days?) All these details can be a pita to get
right and belong in a base library.
So libtai can work in theory, but we found we had to add a lot to it.
Warner
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
In message: 20090519095316.1e1f4b46.att...@kinali.ch Attila Kinali att...@kinali.ch writes: : On Sat, 16 May 2009 15:09:07 + : Poul-Henning Kamp p...@phk.freebsd.dk wrote: : : In message 4a0ebdee.2020...@erols.com, Chuck Harris writes: : : A watch isn't exactly a challenge to an operating system. : : Well, no. : : But figuring out correct handling of time is a challenge for operating : system programmers. : : Out of pure interest: what makes handling of time difficult? : From an uneducated point of view it's just updating a counter : From an uneducated point of view it's just updating a counter : in software from a time source in hardware. Simple, naive time keeping is easy. Look at all the folks that make wrist watches. However, when you are trying to get higher and higher accuracy for the time, you have to talk to external folks. Doing this introduces latency. There's variation in this latency, and that limits the synchronization of the times. Also, there are a number of environmental factors that affect the quality of the underlying time keeping hardware since most crystals are sensitive to temperature. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Msg to N.Z. time nuts
In message: c6389103.7e0f%james.p@jpl.nasa.gov Lux, James P james.p@jpl.nasa.gov writes: : : : : On 5/19/09 1:15 PM, Russell Rezaian rreza...@motorola.com wrote: : : At 12:58 PM -0700 2009/05/19, Hal Murray wrote: : USB has a bad reputation, but I think it's way way overblown. Yes, it's : polled, but that polling is done in hardware and the time scale is 1 ms. If : you are satisfied with an accuracy of a few 10s of ms, USB works fine. The : problem is the GPS unit. : : And I can confirm that for my very un-scientific experiments I do get : a pretty consistent time sync around 1 MS plus or minus mark from a : USB serial port adapter in best case conditions. That's with no : special work on a pretty stock consumer grade computer with an off : the shelf USB to serial port. : : : I would expect that the basic frame timing on USB (without actually : digging out my USB documents, because I'm lazy) is on the order of 125 : microseconds (e.g. 8kHz, to support a 8ksps audio stream, just like IEEE1394 : does), but that might just be a latency jitter bound. Well, Yes and No. Yes, you can get frames that fast in isochronous mode, but most host adapters have buffering and queue things up to be dealt with on ~1ms boundaries. And serial port modem control pin status change messages aren't isochronous transfers. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
In message: c636b079.7d49%james.p@jpl.nasa.gov Lux, James P james.p@jpl.nasa.gov writes: : I also wouldn't have the low order counter count nanoseconds, or even set it : up as seconds/subseconds. I'd echo this, since you are artificially limiting the clocks that are input to having a period of an exact number of nanoseconds. This rounding could lead to systematic errors that would lead to a higher noise in the measurements. A simple counter is more flexible. It allows for a number of additional algorithms to be applied to the raw time measurements to account for drift in the underlying oscillator. Phk's timecounters allow for this. They assume a time source that is free-running. It can be measured against a known better source to improve its accuracy (which is what ntpd does). This allows one to correct over time for, say, the relatively crappy internal oscillator found in most PCs. The nice thing about timecounters is they allow hardware as described in this thread to replace the underlying system hardware. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
In message: 20090517233218.01d11b...@ip-64-139-1-69.sjc.megapath.net Hal Murray hmur...@megapathdsl.net writes: : : If a carry occurs between the two high readings, then we can expect : the low reading to be close to 0 on either side of the wrapping. : Which side determines which holds the right value. If the wrapping of : counter happend before reading the low part, then the low part will : be just above 0 where as if it happends just after the low read but : before the high read, the low read will be just below the maximum : counter value. : : I'm interested in the case where interrupts and scheduling are enabled so : there may be arbitrary gaps inserted into the simple code. Interrupts enabled means that you can't make it reliable. : I think this case doesn't work right: : read high : overflow : long gap : read low : read high : : Suppose the low half overflows once a second so I can use handy numbers. : : If the long gap is 0.6 second, the MSB of the low half will be on so we use : the first high sample. That corresponds to a time 0.4 seconds before the : overflow. That's outside the first-last window. (I'm assuming all the reads : and checking take negligible time which seems reasonable if we are talking : about 0.6 seconds of gap.) : : I think there is a mirror image case: : read high : read low : long gap : overflow : read high : : Suppose the long gap is 0,6 seconds so the low half will read 0.4. The MSB : will be off so we use the second high sample. That will produce an answer : 0.4 seconds into the future. Yes, this is why you must disable interrupts. You aren't racing other parts of software, but rather you are racing the wrapping of the counter in hardware. To reliably cope, you have to make sure that a third-party can't interrupt you producing the cases you describe... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD, NetBSD, or Minix-III?
In message: bf689bbe0905160731he199751t1b9212a526ea2...@mail.gmail.com Bob Paddock bob.padd...@gmail.com writes: : On Sat, May 16, 2009 at 9:21 AM, Chuck Harris cfhar...@erols.com wrote: : Bob Paddock wrote: : : Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)? : Seems like it would be easy to make a decent time server, on : embedded hardware with it. Past iterations of the Minix-III website : gave a watch as an example small embedded system it was meant to : power. : : Why do you think Minix-III would be a good candidate for a time server? : : Minix-III is based on the microkernel approach of keeping things small and fast. : Take a look at the web site. http://www.minix3.org/ Right. But microkernels add latency to the dispatching of events. And the latency tends to be variable in a typical microkernel. Variable latency degrades performance. I've not measured minix3, so I don't know if it suffers from this problem or not. Even in a monolithic kernel you have issues with as well, since interrupts can be masked from time to time... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 4a0d0fa0.3020...@tiscali.co.uk Dave Ackrill dave.g0...@tiscali.co.uk writes: : M. Warner Losh wrote: : : I'd try the FreeBSD distribution of Linux. : : Thanks for the suggestions to use something else, but not an option. : : Like I say, I *have* fedora, I'm not planning to uninstall it as it was : installed for me and I don't want the hassle. HI Then just install ntpd and be done with it. If you want sub-microsecond sync to a PPS, you'll be disappointed. If you want about 10ms over a LAN, then you'll be happy. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 20090515142600.gg2...@vanheusden.com Folkert van Heusden folk...@vanheusden.com writes: : You might consider switching to FreeBSD for more reasons than just : timing, It's much faster than Fedora and I found the new 7.1 version easy : : much faster in what respect? tested how? The usual benchmark that's cited here is the mysql tps scaling better than Linux. See for example http://people.freebsd.org/~kris/scaling/mysql.html. The numbers in this paper are a little dated (being for 7.0 and a little over a year old), they show good scaling. Of course, this isn't the place to debate that in extreme detail (for example, there are other pages I can't find right now that show newer versions of Linux, some better, some worse as changes to the scheduler help or hurt performance). It is no longer the case that you can automatically assume Linux performs better. You have to measure things and make sure you use the system that best matches your performance requirements. Also, on a 7.1R system, you need to make sure that you enable tagged queueing. A last minute change botched it. 7.2R is out now too. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 20090515152610.gi2...@vanheusden.com Folkert van Heusden folk...@vanheusden.com writes: : : You might consider switching to FreeBSD for more reasons than just : : timing, It's much faster than Fedora and I found the new 7.1 version easy : : : : much faster in what respect? tested how? : : The usual benchmark that's cited here is the mysql tps scaling better : than Linux. See for example : http://people.freebsd.org/~kris/scaling/mysql.html. The numbers in : this paper are a little dated (being for 7.0 and a little over a : year old), they show good scaling. Of course, this isn't the place to : debate that in extreme detail (for example, there are other pages I : can't find right now that show newer versions of Linux, some better, : some worse as changes to the scheduler help or hurt performance). It : is no longer the case that you can automatically assume Linux performs : better. You have to measure things and make sure you use the system : that best matches your performance requirements. : Also, on a 7.1R system, you need to make sure that you enable tagged : queueing. A last minute change botched it. 7.2R is out now too. : : You can't say that freebsd is faster than linux; you specifically need : to specify what version of freebsd and what version of linux you're : using. Also the hardware platform matters as well as the compiler (and : version) used to compile mysql and numerous other parameters. I didn't say FreeBSD was faster than Linux. Please read what I said carefully (note, the quotes stuff at the top isn't me). I said for some work loads, it is faster. : What would be interesting is how a specific linux-kernel with the pps : patches by rodolpho compare to a specific freebsd version with the same : ntpd compiled using the same gcc and such. Yes. All my evaluations of Linux pre-date this patch. However, even with the patch, I can still say that Linux performs worse than FreeBSD on NTP because the patch hasn't been committed to the kernel.org tree. I guess this is the difference between Linux can be made to perform better with this out-of-tree patch and Out of the box, Linux performs well. When FreeBSD switched from gcc 3.x to gcc 4.x, I did measurements of the ability of the kernel to track a PPS (also changes with the major revision of the kernel). I found that there was no measurable difference between the different FreeBSD kernels I tested despite being built with a number of different compilers (3.4.5, 4.2.0 and 4.1). It turns out that the algorithms for steering the time aren't dependent on how fast the results are computed, but rather dependent on the results being computed correctly. I will admit that my testing of Linux was been rather cursory over the years compared to the attention I've given to FreeBSD. Of course, we're mixing up problems a little bit here. The ntpd with pps performance issue is somewhat different than the claims another writer was making about FreeBSD being faster for his servers... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 4a0c7a74.50...@tiscali.co.uk Dave Ackrill dave.g0...@tiscali.co.uk writes: : Anyone got any good Linux time systems for PCs ? : : I now have a PC on my home system that has Linux fedora on it and I'm : keen to learn how to make it a useful new member of my network. : : I did dabble with Redhat Linux once before in the 1990s, and still have : the scars to show for it, so please don't assume that I know what I'm : doing... I'd try the FreeBSD distribution of Linux. :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 20090514220030.68e47b...@ip-64-139-1-69.sjc.megapath.net Hal Murray hmur...@megapathdsl.net writes: : : Is there any consensus for the reasons why Linux performs poorly? I : was thinking about setting up a server as well (possibly using a : little ARM-based single-board computer that runs Linux). : : Consensus? I doubt it. : : My reading. Lots of cooks. None of them are time geeks. Many of these cooks have firmly held, strong views on how things should be done, which also gets in the way of having a reasonable discussion about why those views hurt time performance. At least that's been my experience. On FreeBSD you have phk@ and I which works better... : There are a lot of people working on Linux. A lot of them are smart. A lot : of them are not plugged into the culture of key chunks of technology so they : fix or clean up some code in ways that actually breaks things. Many times the fixes neglect edge cases, or dismiss the need to get them right at all (like: who cares if the system time is off by a second, ntpd will steer that out). : There are only a few big screwups that are on my list these days. : No PPS support. : The TSC calibration code is broken. (and it's the default mode) : The in-kernel NTP support code is broken. : : The last two work, just not quite correctly. They are close enough so that : you probably won't notice any problems unless you are a geek. True enough... If you are, you are way too much about it, but if you don't it doesn't bother you at all... : One of the things that is driving some of the changes is making : things work better for low power applications. The old scheduler : used to do a bit of work every clock tick (100 HZ to 1000 HZ). That : chews up a lot of power if your battery powered system goes to sleep : when there is nothing to do. So it seems reasonable to look ahead : in the scheduler queue and figure out how long until the next time : there is work to do and sleep until then. The problem is that these can't easily be turned off... The other problem that the tickless stuff starts to expose is that many of these platforms have counters that can be used for time keeping, but they wrap too quickly to sleep for long... Anyway, I'm totally biased on this stuff, so you should take me with a grain of salt. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Linux time servers
In message: 20090514223310.0d552b...@ip-64-139-1-69.sjc.megapath.net Hal Murray hmur...@megapathdsl.net writes: : I'd try the FreeBSD distribution of Linux. : Ouch. In some circles, those are fightin' words. : : I interpreted it as a joke, like telling a Windows user to install Service : Pack Linux. Yes. It is a joke. One of the market share firms (netcraft?) had this as one of the choices for a questions in ~1998 that went something like: Which distribution of Linux do you run redhat suse debian freebsd : If all you want is to run a time server, FreeBSD will do a better job than : Linux. In particular, the Soekris boxes are polular. : : If you have a Linux box that you need/use for other stuff, it can also run : ntpd. That may or may not be good enough at timekeeping for a time-nut. ntpd works on Linux, it just doesn't perform as well as FreeBSD. But the difference in performance typically is in the millisecond range or 10ms range (depending on the kernel version). For most people, this is more than good enough. For subscribers to time-nuts... :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Certichron
In message: 4fdb424f0904281038n7ef92dc1j117ab1eca8735...@mail.gmail.com Gretchen Baxter gretchendenisebax...@gmail.com writes: : They seem to be positioning themselves as *THE *trusted source for time : synchronization. If you were in the time business, would you say you weren't the trusted source of time? Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Loran-C French Clocks
And when people are asking about UTC vs GMT, it should be noted the real question is Is legal time defined to be UTC, or is it defined to be mean solar time? GMT is mean solar time, except for all the silly confusion caused by folks who think it is the same as UTC. See recent threads on LEAPSECONDS for perfectly reasonable people that still get this distinction wrong... Warner In message: e1ljior-0007z8...@meow.febo.com Arnold Tibus arnold.ti...@gmx.de writes: : Magnus and all, : : interestlingly the discussion about GMT seem to be a never ending : story, all over the world. As I know GMT was already renamed in : the year 1925 ( or 1928 acc. other source ) to UT and : universal time coordinated (U T C) (that) is standard since : January 1, 1972. acc. About the Time : : : http://www.fai.org/astronautics/time.asp , : look into the short overview to this history. : : Does anyone know the exact difference between GMT and UTC? : - this question seem to be already very old, Magnus. : : Richard B. Langley wrote a summary trying to give the right : answer with A Few Facts Concerning GMT, UT, and the RGO . : : His article can be found here: : http://www.apparent-wind.com/gmt-explained.html : : It summarizes: : The Greenwich mean time, GMT, has today only an historical : interest. It has been abandoned since the thirties for successively : the T U 1, the T U 2 and finally, in 1972, for the much more regular : universal time coordinated, U T C, that must be used : for all present use. ! : : That is what I thought as well quite a while. : But I had to change ever so often all kind of scientific and : technical units, and I see the need to adopt it, I am sure we have : to be open for more steps into the future. Learning will never end...! : : Arnold : : : : : : On Tue, 17 Mar 2009 21:12:18 -, Jean-Louis Oneto wrote: : : Hello, : The French Legal Time Reference is defined since a 1978 decree by the : UTC(OP) realisation of UTC, as stated here: : http://syrte.obspm.fr/index.php?prefix=tempslang=en : : Furthermore, the International Earth Rotation Service at Paris Observatory : is responsible for the leapseconds insertion in UTC... : Have a nice day, : Jean-Louis Oneto : Grasse - France : : - Original Message - : From: Magnus Danielson mag...@rubidium.dyndns.org : To: Discussion of precise time and frequency measurement : time-nuts@febo.com : Sent: Tuesday, March 17, 2009 7:27 PM : Subject: Re: [time-nuts] Loran-C French Clocks : : : Arnold, : : I therefore cannot see any problem is with France, : but we have the need to define more precise and stable : reference time from where we can then measure and add : the Earth and Solar instabilities for our daily used standard : watches, in order to be enabled still to continue living and : travelling sun synchronously : : I hope not having been informed wrong so far, : kind regards and always precise time : : Please recall that just because the TAI and UTC clocks is being : maintained by BIPM just outside of Paris does not mean the same as being : legally accepted basis of time within France. : : Citing relevant law stating that the time of France shall be UTC + 1h : for normal time and UTC + 2h for summer time is providing the piece of : the puzzle that I was asking for. : : I have read Swedish and Danish law in this respect, as well as most : translations of the EC directive on summertime. : : It should be noted that I do not assume UTC = GMT. : : Cheers, : Magnus : : : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Loran-C French Clocks
In message: 49c033e3.2010...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : So far: : : UTC based: France, Sweden : GMT based (UT1?): Great Brittian, Denmark US: UTC It was Mean Solar Time for a long time, and then it was changed to Mean Solar Time as interpreted by the secretary of commerce which gave enough wiggle room to move to UTC. The recent DST changes also contained a rider that changed this to UTC, as implemented by USNO. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Loran-C French Clocks
In message: 000501c9a7b1$ef689bb0$a101a...@officemail phil fort...@bellsouth.net writes: : This will answers all the questions. : http://en.wikipedia.org/wiki/GMT Except that it doesn't answer much of anything for Magnus' questions. There's only 4 countries listed. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] French Time offset
In message: ece7a93bd093e1439c20020fbe87c47feb5f69c...@altphyembevsp20.res.ad.jpl Lux, James P james.p@jpl.nasa.gov writes: : -Original Message- : From: time-nuts-boun...@febo.com : [mailto:time-nuts-boun...@febo.com] On Behalf Of Jean-Louis Oneto : Sent: Wednesday, March 18, 2009 10:14 AM : To: Discussion of precise time and frequency measurement : Subject: Re: [time-nuts] French Time offset : : BIPM is an _international_ organisation, and apart to be in : France, has nothing to do (and never had as far as I know) : with the definition of French legal time. At least no more : than for any other country UTC (or TAI) based. : Jean-Louis : : Paris is at 2degrees 20 min longitude, which isn't enough : to account : for : 12.5 minutes. Sevres (where BIPM is) is actually a bit to : the west, : so even less solar time difference. : : : Just casting about for potential meridian locations that might : explain the 12.5 minute difference. Maybe the central longitude of : France is 12.5 minutes(of time, 3 1/8th degrees of longitude) from : Greenwich? (like India's time zone being on the half hour). Things : get done for funny reasons: After all, the physical size of France : is why ATM cells (packets) are 53 bytes (48 byte payload) instead : of either 32 byte or 64 byte payloads. Actually, there this paper: http://www.ucolick.org/~sla/leapsecs/seago.pdf says that the delta was 9 minutes and 20 seconds (see page 10) Historic Universal Time (GMT) in France. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] French Time offset
In message: ece7a93bd093e1439c20020fbe87c47feb5f69c...@altphyembevsp20.res.ad.jpl Lux, James P james.p@jpl.nasa.gov writes: : : : Actually, there this paper: : : http://www.ucolick.org/~sla/leapsecs/seago.pdf : : says that the delta was 9 minutes and 20 seconds (see page : 10) Historic Universal Time (GMT) in France. : : Warner : : : 9 min 20 sec = 9.333 mins = 0.155 hours = 2.33 degrees of longitude = 2 deg 20 min longitude = longitude of Paris : : Which makes sense.. The article actually talks about France defining GMT in terms of PMT. Yes. I think that the 12.5 minute shift never really happened and all that happened was that was that France went from defining GMT in terms of PMT to a direct definition... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Time offset
In message: 001c01c9a82e$4014b270$a101a...@officemail phil fort...@bellsouth.net writes: : Magnus, : On that same page was a link to an older archive, tzarchive.gz : ftp://elsie.nci.nih.gov/pub/tzarchive.gz : : You will find references to actual laws and links imbedded in that for : various countries. Your assumption that that GMT = UTC I would say is true : from 1970 on. Except that it really isn't. This is the whole point of Magnus' request. The national laws are written to specify Mean solar time at a given meridian. One realization of mean solar time is UT1, while another is UTC. Often things aren't specified exactly in the laws. These two are almost interchangeable, but not quite. For example, if UTC were redefined to omit leap seconds, the issue could become a real one again. The US is now on UTC time, where until recently it was a Mean Solar Time, as defined by the Department of Commerce, which was some variation of UT2 for a while, but quickly became the same as UTC when the official time keeping responsibilities transitioned to NIST. NIST determined that UTC was a mean solar time, and published that as the official time of the US. With the old definition, a change to the underlying UTC might mean the US would have had to deviate from UTC. With the current law, it is clear that UTC, whatever it is, is the official time. : GMT was the first internationally accepted international/global standard : with various legally defined offsets. It was only after the advent of the : cesium and the gps system that UTC became the standard, again with the legal : offsets. Most older law, pre 1970 I've seen references to gmt, but when laws : are appended for example saving time, reference is often or sometimes made : to utc, though the old legal definition may still reference gmt. Right. However, these old legal definitions that specify mean solar time may be OK with the UTC approximation, with others may not. : Perhaps most lawmakers accept them (gmt, utc) to be the same with their : local/regional offsets now that you can get standardized utc off satellites : world wide. Right, but this is speculation. Magnus is looking for the law on the topic. I presume both the actual law as written, but also the regulation laws used to implement the legislative intent. : Other than the flying clock how else can all countries of the world : synchronize their time? I think a lot of small countries have a single : cesium, if that, tied to gps and vend their countries official time based : on that. In that case they are based on UTC regardless of the wording of : their prior law. : : I know in North Carolina, USA a law was still on the books a few years ago : that it was illegal to look at your wife naked. Law is often slow to catch : up with society and technology. The various countries definitions of time : referencing GMT may too be laws that have not come into the twentieth : century though utc (with offsets) is now the accepted standard. This is true. I think Magnus is looking for the details... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] pi Day
In message: 49ae3360.4000...@tiscali.co.uk Dave Ackrill dave.g0...@tiscali.co.uk writes: : Steve Rooke wrote: : 2009/3/4 Dave Ackrill dave.g0...@tiscali.co.uk: : : When do we get to the 14th month? ;-) : : Don't have to, we can get to the 1st month, January. : : : OK, that gets us to 3/1 but where does the '4' come from? If you want : to count 4am, then you have to ignore the leading zero, even allowing : for not using leading zeros in the day and month that doesn't feel quite : right. : : At least with the American version you can have 3/14 15:00 before the : sequence breaks down... Or, 3/14 20:00 if you decide to round up the : third decimal place. : : I guess you could go to 3/1/4159 but that's a bit of a wait to have a pie. Clearly people aren't seeing the on universal pi day of the year. That would be DOY 314... :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS antenna installation problem
In message: 49ac1f99.7010...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : Steve Rooke skrev: : 2009/3/2 Magnus Danielson mag...@rubidium.dyndns.org: : Steve Rooke skrev: : Gaffa tape the cable to the supporting pipe with a small drip loop : into the connector. : No. The glue of Gaffa tape ages. Also, it is not very nice to the cable. : : Buy decent gaffa tape, not the duct tape variant :) : : Even with really good stuff, it is not the long term solution you would : like. : : Sorry, I agree with you really Magnus. I was more indicating that the : cable does need to be supported by being attached to the mast : structure than have all that weight on the poor connector. Gaffa is : great for temporary work where is is tough and sticks well, and is : easy to tear-down an installation. : : Indeed. Temporary 1 week : : Using black wide cable ties for the antenna cable would be an idea and : be easy to take down too. : : Indeed. I've used both Velcro scraps, plastic cable ties and electrical tape for strain relief on my wireless connection. Velcro straps seem to work the best, but need to be replaced every 8-10 years or so. The rest is crap. Since I was reconfiguring the setup every few years, I could easily replace the worn/weathered straps when I did the reconfiguration. I don't know what I'd use for a more permanent installation. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] (OT) Frequency and duration of roll out
In message: 11721.1235293...@critter.freebsd.dk Poul-Henning Kamp p...@phk.freebsd.dk writes: : In message 49a11470.6060...@tiscali.co.uk, Dave Ackrill writes: : : If you wanted to cheese off the instructor, you went to the roll of thin : cotton tape, hanging on a roll on the wall, and pulled hard. The weight : of the tape coming off the roll was enough to spin the disk, thus : bringing more tape off, which was heavy enough to spin the roll some : more, so more tape came off, and so on. : : This was a well know issue when manipulating the roll while splicing : audiotapes. : : The funny thing was, 2 tapes are really strong. : : We tied an old studio worktape to the trailer-hook of a friends car : when he got married. The tape unrolled flawlessly, the roll : clattered wonderfully on the cobbles, and when they turned out of : the drive-way it snagged a lamppost and brought the car to a halt : until the groom went out and cut the tape :-) Try doing that with CDs :-) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Canada's 5,000 year old calendar
In message: 25630a120901291622l5cc165ecna06e01cc3de52...@mail.gmail.com michael taylor mct...@gmail.com writes: : An academic maverick is challenging conventional wisdom on Canada's : prehistory by claiming an archeological site in southern Alberta is : really a vast, open-air sun temple with a precise 5,000-year-old : calendar predating England's Stonehenge and Egypt's pyramids. ... : Since we had some discussion about historic calendars earlier this : year, I thought it might of interest here. I wonder if he has accounted for the progression in the earth's wobble over the past 5k years to make his claims... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Canada's 5,000 year old calendar
In message: 49825436.5090...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : M. Warner Losh skrev: : In message: 25630a120901291622l5cc165ecna06e01cc3de52...@mail.gmail.com : michael taylor mct...@gmail.com writes: : : An academic maverick is challenging conventional wisdom on Canada's : : prehistory by claiming an archeological site in southern Alberta is : : really a vast, open-air sun temple with a precise 5,000-year-old : : calendar predating England's Stonehenge and Egypt's pyramids. : ... : : Since we had some discussion about historic calendars earlier this : : year, I thought it might of interest here. : : I wonder if he has accounted for the progression in the earth's wobble : over the past 5k years to make his claims... : : Hmm... never check a story too closely... :) : : I think to recall that that kind of people use software that can fairly : accurately re-play sky-events back in time... considering various of : long-term drift effects. Would love to fool around with that kind of : stuff... but it is probably unobtainables for mere mortals like me. But I though that unobtainium was easily procured by the time-nuts :) I've seen such software on several shows on TV about paleo-astronomy. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] GPS Time to Year?
In message: c3cd6f936e3e4ee99880b074162ab...@pc52 Tom Van Baak t...@leapsecond.com writes: : Hi: : : It's my understanding that the slowest time data from GPS is the 10 bit week : number. : How does a GPS receiver come up with the current Year? : : -- : Have Fun, : : Brooke Clarke : : Hi Brooke, : : Good question. You are correct that this 10-bit week number : wraps once every 2^10=1024 weeks which is once about every : 20 years. It's not the slowest GPS data, see below *. : : Other GPS fields also wrap (more quickly) in a binary way. : Most wrist watches, for that matter, wrap 60 seconds, or 60 : minutes, or 12 hours. : : Note: : GPS week 0 started MJD 44244 = 1980-01-06 : GPS week 0 (1024) started MJD 51412 = 1999-08-22 : GPS week 0 (2048) starts MJD 58580 = 2019-04-07 : GPS week 0 (3072) starts MJD 65748 = 2038-11-21 : : The ways GPS receivers come up with the current year are: : : 1) Since time moves forward only, the real year can't less than : what the year was yesterday. So when a GPS receiver on, say, : Sunday morning April 4, 2019 sees that the GPS week is now 0 : while last night the week was 1023, the GPS receiver can be very : sure that the year is still 2019 and not 1980 or 1999 or 2019. As : long as a GPS receiver has NVRAM you're all set. That works. Even in the coldest of spares will have been on sometime in the last 20 years, which is all that's needed to make this work... : 2) The real year can't be less than the year the GPS receiver was : manufactured. If the firmware sees GPS week 491, is has the : option to decide if that week means 0+491 (June 1989) or 1024+491 : (January 2009) or 2048+491 (September 2028). With a +/- 10 year : margin the GPS receiver can pick the correct one. : : On the other hand, those of us with boat anchor GPS receivers from : August 1999 know that firmware isn't always perfect.' :) : 3) The real year can be obtained from external sources. Many GPS : receivers are now embedded into cell phone or internet-enabled : devices so obtaining a hint at the current date is easy. One may : even know the datetime well before the first GPS signal lock. That's cheating... : 4) The real year can't have fewer leap seconds than the previous : year. So if you see that the GPS week number is 0 and the UTC : vs. TAI leap second count is around 20 seconds you know it's : GPS week 0 and year 1980. If the leap second count is closer to : 32 seconds you know it's GPS week 0(1024) and so year 1999. : If the count is closer to, say, 44 seconds, then you can be safe : that it's GPS week 0(2048), or year 2019. Not perfect, but it will : work fine for our lifetimes and more. Yes. Assuming there's no huge acceleration of the earth... Possible, but very unlikely... And assuming that leap seconds continue... If they stop, it will be hard to know... But if they stop, I can imagine that we could use DUT1 that would have to be published... : *) The 8-bit leap second number is slower, wrapping once every : couple of hundred years. Note also that the new GPS data format : allows for wider bit fields for this and other parameters. See also: : http://leapsecond.com/notes/gpswnro.htm True... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Off Topic question...
In message: 8cb492c1a47292d-1178-...@mblk-m35.sysops.aol.com n3...@aol.com writes: : In all of this Anglo American battering there is one thing we can agree on. : : Jason Bourne can kick James Bond's butt (or arse). Jason Bourne can kick James Bond's butt but James Bond can kick Jason Bourne's arse. might be a better way to say it :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Free programs to read NEMA data.
In message: ca1.4beaaa2e.36a3c...@aol.com n3...@aol.com writes: : : OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm : giving it a work out by running as many applications as I can. I have NMEAT : running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. : They are 16 seconds off from each other? I see on Tboltmon there is a field : for UTC offset and 15 seconds is entered there. Any ideas? The current UTC GPS offset is 16, and has been for the last 17 days or so :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Free programs to read NEMA data.
In message: 1232236533.26603.8.ca...@bg-desktop Björn Gabrielsson b...@lysator.liu.se writes: : Hi Warner, : : On Sat, 2009-01-17 at 16:30 -0700, M. Warner Losh wrote: : In message: ca1.4beaaa2e.36a3c...@aol.com : n3...@aol.com writes: : : : : OK I found my registration for NMEAT. Now that I upgraded my hobby PC I'm : : giving it a work out by running as many applications as I can. I have NMEAT : : running from a Jupiter GPS engine and I have T-Bolt mon going at the same time. : : They are 16 seconds off from each other? I see on Tboltmon there is a field : : for UTC offset and 15 seconds is entered there. Any ideas? : : The current UTC GPS offset is 16, and has been for the last 17 days or : so :) : : That is not the view of USNO... : :ftp://tycho.usno.navy.mil/pub/gps/leapsecnanu.txt : : nor the Meinberg receiver I take care of. : : $ ntpq -c cv timehost.lysator.liu.se | grep gps_utc : : gps_utc_correction=current correction 15 sec, last correction on : cd068600. Thu, Jan 1 2009 0:00:00.000, : : However I once had a Jupiter receiver where the NMEA output came 1.0xx : seconds late or 2.0xx seconds late. Btw, the Jupiter/Zodiac binary was : much better timed. Doh! I added two seconds to my internal leap second delta counter. My bad. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NTP API on Linux 2.6.26
In message: 4964340d.8030...@rubidium.dyndns.org
Magnus Danielson mag...@rubidium.dyndns.org writes:
: Hi!
:
: As I have been investigating the ways of NTPD to fiddle with time in the
: LINUX kernel I discovered that /usr/include/linux/timex.h (as supplied
: by the kernel) is not in sync with /usr/include/sys/timex.h (as supplied
: by glibc 2.7). Since it is the sys/timex.h which is the interface to
: NTPD and anyone else (it is actually a neat little interface if
: correctly supported).
:
: The fluke is that glibc duplicates the timex.h but has not been updated
: since oh... Linux 2.2.0. The linux/timex.h is up to date with the NTP
: API as far as I can see (have not checked the details).
:
: There are some links that may be handy:
: http://bugs.gentoo.org/attachment.cgi?id=165913action=view
: http://sources.redhat.com/bugzilla/show_bug.cgi?id=9690
: http://sourceware.org/ml/libc-alpha/2008-03/msg00076.html
:
: However a small test-program:
: #include stdio.h
: //#include sys/timex.h
: #include timex.h
:
: int main()
: {
: struct timex foo;
: adjtimex(foo);
: printf(TAI Offset %i\n, foo.tai);
: return 0;
: }
:
: (Notice my quick and dirty hack to use a hacked variant of timex.h as if
: the patch was being applied, also notice that the .c part does not apply
: to the adjtimex() call but to the ntp_gettime() call which I am not
: using, so I do not require that patch for this purpose.)
:
: This should be the kernels feeling of the TAI-UTC difference. I do not
: think it reflects that:
: mag...@heaven:~/gcc/ntptest$ ./tai
: TAI Offset -1553771440
: mag...@heaven:~/gcc/ntptest$ ./tai
: TAI Offset -263060400
: mag...@heaven:~/gcc/ntptest$ ./tai
: TAI Offset 238212176
: mag...@heaven:~/gcc/ntptest$ ./tai
: TAI Offset 658158672
: mag...@heaven:~/gcc/ntptest$ ./tai
: TAI Offset 1551639632
:
: So I guess there is more to it than that patch alone.
:
: If someone could run the above test-program on some *BSD box or whatever
: implementing the NTP API version 4 I would be interested in seeing what
: the result would be. It surely isn't the definitive test on the API, but
: seems to detect one (of possible several) flaws.
That didn't work.
% cc -o y y.c -Wall
y.c: In function 'main':
y.c:9: warning: implicit declaration of function 'adjtimex'
y.c:10: error: 'struct timex' has no member named 'tai'
But this does:
#include stdio.h
#include sys/time.h
#include sys/timex.h
int
main(int argc, char **argv)
{
int rv;
struct ntptimeval ntv;
struct timeval tv1;
struct timeval tv2;
gettimeofday(tv1, NULL);
rv = ntp_gettime(ntv);
gettimeofday(tv2, NULL);
printf(System: %ld.%06ld\nntp:%ld.%09ld (err %ld)\nntp*:
%ld.%09ld\nsystem: %ld.%06ld\n,
(long)tv1.tv_sec, (long)tv1.tv_usec,
(long)ntv.time.tv_sec, (long)ntv.time.tv_nsec, ntv.esterror * 1000,
(long)ntv.time.tv_sec, (long)ntv.time.tv_nsec + ntv.esterror * 1000,
(long)tv2.tv_sec, (long)tv2.tv_usec);
printf(TAI Offset is %ld\n, ntv.tai);
}
Warner
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: m3hc4gqdjb@lugabout.jhcloos.org James Cloos cl...@jhcloos.com writes: : Warner == M Warner Losh i...@bsdimp.com writes: : : Warner So what you've done is created a new time scale that is a UTC : Warner from 1972 forward, but a simplified form of UTC prior to 1972 : Warner that didn't match what UTC was doing then. : : Grrr! Except s/you/they/; I didn't invent. Yea, I was speaking a bit rhetorically :-) : So right isn't quite, err, right. I wonder whether the Olsen db can : be fixed to account for that? right/UTC and posix/UTC currently are : identical for all (time_t)LONG_MIN = time_t 78796800. Yes. I'd forgotten that the Olsen db doesn't deal with rubber seconds at all. It is a pain in the *** to try to do that, and of dubious value. I tried once to create a library that coped with them, but gave up when I realized it wasn't a useful problem to solve. : Thanks for the reminder. I had forgotten that entirely. (And am : only just vaguely remembering that I used to know that fact. [SIGH]) It is certainly underdocumented... : Warner Yet another hazard of high precision time keeping that few : Warner people get right : : Part of what makes this list's name so appropriate is just how hard : it is, all things considered. That is also what makes it enjoyable. Yes. Very enjoyable. Of course, I could live without all this complexity, frankly, and be happier. : Warner An understandable simplification, to be true, and one that's : Warner often made... : : Often, I'm sure, because not all sources document/remember that fact. Yea. In another life, I defined a datum as 'number of SI seconds since 01-01-1972 00:00:00 UTC + 63072000'. Which is what we're talking about here, no? This is number of seconds since 1970, with the 'oddball' rubber seconds counting as SI seconds. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: 495f7285.3040...@erols.com Chuck Harris cfhar...@erols.com writes: : christopher hoover wrote: : Hal Murray wrote: : Two of my Linux systems hung. One was running a 2.6.25 kernel and one : 2.6.26. A system running 2.6.23 worked fine. I saw a couple of notes : on : comp.protocols.time.ntp about Linux systems locking up. One said that : it was : a kernel bug in ntp.c but I haven't seen any details. : : None of mine (many dozens) hung.This is typical: : : c...@snaggle:~$ uname -a : Linux snaggle.murgatroid.com 2.6.26-1-amd64 #1 SMP Mon Dec 15 19:40:58 UTC : 2008 x86_64 GNU/Linux : c...@snaggle:~$ dmesg | grep leap : [844362.415072] Clock: inserting leap second 23:59:60 UTC : c...@snaggle:~$ : : : -ch : : None of my linux systems hung either! My typical message was: : : $ dmesg | grep leap : [6181904.453104] Clock: inserting leap second 23:59:60 UTC : : The message implies that linux clocks counted: : : 58..59..60..00..01 : : Which would not be the POSIX way. That message doesn't imply that at all... Well, maybe it is the implication, but POSIX *CANNOT* count that way. It is number where 23:59:60 maps to, through normalization and *mktime, 00:00:00 (or maps to 23:59:59 if you are ticking time, which isn't required to do the mktime stuff). Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: m31vvks3e9@lugabout.jhcloos.org James Cloos cl...@jhcloos.com writes: : Chuck == Chuck Harris cfhar...@erols.com writes: : : Chuck The message implies that linux clocks counted: : : Chuck 58..59..60..00..01 : : Chuck Which would not be the POSIX way. : : No, the linux clocks counted: : : 1230768021..1230768022..1230768023..1230768024..1230768025 : : where 1230768024 is 2009-01-01 00:00:00 UTC. : : What gets output by any given userland apps depends on those apps. : : If one uses the Olsen tz database, the right zonefiles rather than the : posix zonefiles, and a libc such as glibc, then one will have seen the : seconds tick off 58..59..60..00..01. : : But that is purely a userland issue. : : If one uses the (lobotomized) posix zonefiles, one will have seen the : seconds tick off 21..22..23..24..25. : : (Interesting coincidence there, that 1970 through 2008 (inclusive) has a : number of days divisible by 5. Which makes for a nice, even 1230768000 : seconds, were there no leap seconds.) That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 at midnight is an invariant that's violated by the above sequence. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: m3vdswqmb5@lugabout.jhcloos.org James Cloos cl...@jhcloos.com writes: : Warner == M Warner Losh i...@bsdimp.com writes: : : Warner That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 : Warner at midnight is an invariant that's violated by the above sequence. : : By which sequence? The sequence where midnight % 86400 isn't 0. : At every point in time where time_t % 86400 == 0 is true gmtime(2), when : using no zoneinfo file or when using a posix zoneinfo file, will return : a struct tm where the time of day is 00:00:00. : : (time_t)1230768024 was 2009-01-01 00:00:00 right/UTC : (time_t)1230768000 was 2009-01-01 00:00:00 posix/UTC : : and the real 2009-01-01 00:00:00 UTC was exacly 1230768024 si seconds : after 1970-01-01 00:00:00 UTC. Correct. The 'right' way here isn't POSIX compliant. POSIX has no leap seconds at all. They don't exist. : That this leap second was (time_t)1230768023 is is a simple fact of how : long it has been since the start of 1970. : : That POSIX pretends that 2009 UTC started 24 seconds earlier than it : did is a bug. It is the standard. It isn't desirable behavior, but it is what is mandated by the standard. You can argue it is a bug, and I might agree with you, but that won't make it any less the standard. And explicitly part of the standard after much arguments in committee. It is one of the things horribly broken by POSIX. Also, you need to run a hacked ntpd, because the ntp time stamps follow the posix mandate, not the TAI-like second count... : Anyone who has some requirement to exactly match POSIX as published can : use the posix zoneinfo files and have time_t % 86400 == 0 as midnight : “UTC” every day. Their idea of time will be off, but they get to keep : their fixed-sized intervals. The trouble is that there's a lot of code that depends on this behavior... : Anyone who wants to track the real UTC can do so using the right : zoneinfo files. By doing so they explicitly choose to ignore : that particular bit of nonsense in POSIX, but that is OK since it : is their choice. : : Everyone gets to choose which they prefer. Correct. Of course, how do programs that run for years get updated leap second information so they continue to produce the correct times? I've never understood how that part of the 'right' files works... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
This is a minor little pedantic followup from an answer I gave before to correct a minor little quibble about the historic UTC. If you are uninterested, hit 'd' now :) In message: m3vdswqmb5@lugabout.jhcloos.org James Cloos cl...@jhcloos.com writes: : Warner == M Warner Losh i...@bsdimp.com writes: : : Warner That doesn't match POSIX's mandated behavior... time_t % 86400 == 0 : Warner at midnight is an invariant that's violated by the above sequence. : : By which sequence? : : At every point in time where time_t % 86400 == 0 is true gmtime(2), when : using no zoneinfo file or when using a posix zoneinfo file, will return : a struct tm where the time of day is 00:00:00. : : (time_t)1230768024 was 2009-01-01 00:00:00 right/UTC : (time_t)1230768000 was 2009-01-01 00:00:00 posix/UTC : : and the real 2009-01-01 00:00:00 UTC was exacly 1230768024 si seconds : after 1970-01-01 00:00:00 UTC. Except I don't think that 1970-01-01 00:00:00 UTC isn't what you think it is. While there have been 24 leap seconds since 1972-01-01 when the practice started, the divergence between TAI and UTC at 1970-01-01 00:00:00 was more like 8.1s[*] (it was fixed at 10.0 exactly in 1972). So there really have been an additional 1.9s since then. So the number is closer to 1230768025.9s since 1970-01-01 00:00:00 UTC for the second after the last leap second. The time before 1972 was when the atomic clocks were run a little slow to account for the variations in the earth's orbit. See for example the table from: http://maia.usno.navy.mil/ser7/tai-utc.dat So what you've done is created a new time scale that is a UTC from 1972 forward, but a simplified form of UTC prior to 1972 that didn't match what UTC was doing then. Yet another hazard of high precision time keeping that few people get right (to pound on my leap seconds are hard drum again). An understandable simplification, to be true, and one that's often made... Warner [*] I didn't do the math today, and the 8.1s figure is from my memory only. Someone with more time on their hands than I can compute the exact offset... ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: 26842.1231015...@critter.freebsd.dk Poul-Henning Kamp p...@phk.freebsd.dk writes: : In message 495fb615.9080...@rubidium.dyndns.org, Magnus Danielson writes: : : Having a message from ntp.c that says there was a leap : to HH:MM:60 implies that HH:MM:60 is a valid time as far : as ntp.c's author is concerned. : : It is valid UTC time, not valid POSIX time, which are two different things. : : Well, it is a valid POSIX time, but it means a second later than : desired in this case, because the 60 is taken as 60 seconds, and : folded into a minute-roll-over. It is a valid POSIX struct tm time. But it doesn't represent a leap second. Instead, like you say, it wraps to the next minute. There are not POSIXly compliant time_t values that will map to the leap second value (23:59:60). It is not possible to represent the leap second in a time_t. : Having used unix since edition V, I am also aware of how unix : systems count off seconds since the epoch 1/1/1970. But that : really is immaterial to the discussion. : : No, that is actually the crux of the matter... Yes. Such a simple definition gives so many possible ways to interpret it. The POSIX there are no leap seconds way. The prior + accumulated leap seconds. And also the prior, plus the extra time that accumulated between 1970 and 1972 in the UTC time scale... But that last one is kinda hard since it isn't an whole number of seconds. I've seen timescales try to use all of these definitions at one point in my career or another (plus a boatload of others that seemed like a good idea at the time to the inventors). Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: m3mye8qen3@lugabout.jhcloos.org James Cloos cl...@jhcloos.com writes: : Warner == M Warner Losh i...@bsdimp.com writes: : : Jim By which sequence? : : Warner The sequence where midnight % 86400 isn't 0. : : MY appologies, but that isn't narrowing it for me. POSIX only cares : about POSIX midnight, not UTC midnight, so the fact that it was already : past PODIX midnight when the leap second and UTC midnight happened is : irrelevant to POSIX. posix midnight and utc midnight are the same things. You had said that the system time was returned as 24 at UTC 2009-01-01 00:00:00, which isn't posixly correct. : Warner Also, you need to run a hacked ntpd, because the ntp time stamps : Warner follow the posix mandate, not the TAI-like second count... : : Huh? rfc1305 says 32.32 bit fixed point seconds since 1900-01-01 : 00:00:00, and of course there is the newer 64.64 bit fixed point. : : The only question, then, is whether ntp and UTC agree on just when : 1900-01-01T00:00:00 was. ;^) ntpd needs to convert the time from the kernel to the 32.32 number. To do that, by default it assumes a POSIXly correct time_t. That's the only point I was making. If a different number is returned (one with leap seconds added in), then ntpd has to cope. : Warner how do programs that run for years get updated leap second : Warner information so they continue to produce the correct times? I've : Warner never understood how that part of the 'right' files works... : : That is libc-dependent. I've not looked at the src in a while (many : months), but IIRC glibc opens the file every time it needs it, so it : will see a new zoneinfo database as soon as they are written to the : filesystem. : : Other libcs might do things differently. As an example, I don't think : klibc uses the zoneinfo files at all; dietlibc and uclibc may not : either. And obviously the BSDs' libcs handle things quite differently : than glibc. (GNU on BSD kernels is not uncommon; I'm sure I've read : about people doing one of the BSD userlands on a linux kernel, too.) : But at least for glibc it just works. : : And, of course, said zoneinfo updates are needed anyway every time the : politicians muck with the timezones. Libc also has to deal with changes : to the TZ environmental variable. Another reason to re-read the : zoneinfo files as necessary. (It is possible that glibc only reopens if : the stat(2) data changes; again, it has been a *long* time since I last : read that part of the glibc src.) Yea, I was wondering if it did a stat on every time conversion, or if it batched them somehow. Doing one on every conversion seems very heavy-weight to me... Hence my question of how do the updated zoneinfo files happen, and how does the application get notified of the changed of leap info in case they have already computed a time that would be affected by the new leap information. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: 495fd637.5030...@erols.com Chuck Harris cfhar...@erols.com writes: : Poul-Henning Kamp wrote: : In message 495fb615.9080...@rubidium.dyndns.org, Magnus Danielson writes: : : Having a message from ntp.c that says there was a leap : to HH:MM:60 implies that HH:MM:60 is a valid time as far : as ntp.c's author is concerned. : It is valid UTC time, not valid POSIX time, which are two different things. : : Well, it is a valid POSIX time, but it means a second later than : desired in this case, because the 60 is taken as 60 seconds, and : folded into a minute-roll-over. : : Having used unix since edition V, I am also aware of how unix : systems count off seconds since the epoch 1/1/1970. But that : really is immaterial to the discussion. : : No, that is actually the crux of the matter... : : Ok, that is news to me. Are you saying that (pulling a number out of : the air) time_t = 21120123 could be followed by 21120123 on a year where : we added a leap second? Yes. Leap seconds don't exist in POSIX time_t, so the pedantically proper value is undefined. Most implementations repeat a second (either 59 or the 00 second) to cope with this omission. : It is my understanding that it cannot. I believe that time_t must : increment by one as each second passes, and must contain the number of : seconds that have passed since the unix epoch on 1/1/1970... without : regard for leap seconds. That isn't what POSIX says. POSIX is very clear that leap seconds do not exist, and therefore the correct answer for the first second of a year (or of any day) always ends in '00'. : I was of the understanding that the problem was in how the UTC time was : calculated from time_t, and the converse. The problem is that the conversion of time_t to a 'broken down' UTC time isn't 1:1 or onto. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: 495ff91c.60...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : M. Warner Losh skrev: : In message: m3mye8qen3@lugabout.jhcloos.org : James Cloos cl...@jhcloos.com writes: : : Warner == M Warner Losh i...@bsdimp.com writes: : : : : Jim By which sequence? : : : : Warner The sequence where midnight % 86400 isn't 0. : : : : MY appologies, but that isn't narrowing it for me. POSIX only cares : : about POSIX midnight, not UTC midnight, so the fact that it was already : : past PODIX midnight when the leap second and UTC midnight happened is : : irrelevant to POSIX. : : posix midnight and utc midnight are the same things. You had said : that the system time was returned as 24 at UTC 2009-01-01 : 00:00:00, which isn't posixly correct. : : Um... no. That's the hacked POSIX interpretation, not the POSIX standard. : : We have at least three POSIX interpretations here. : : One which has UTC rubber seconds from 1970 to 1972 and from then true SI : seconds from 1972. : One which has true SI seconds from 1970. : One which has UTC tracking in pieces and is slid sideways to make : midnight match UTC midnight. : : The two first ones is interpretations of POSIX over UTC variations. The : third one is a hack of POSIX to make it kind of work anyway with NTP. : Only with the third interpretation POSIX midnight and UTC midnight is : the same. : : Now, which of them is right? Midnight must be 00. POSIX says so explicitly because leap seconds do not exist in POSIX. The committee has issued a very explicit addendum to this effect. Which one is more desirable? Well, that's a matter of debate, but which one is POSIXly correct isn't. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Quirks
In message: 4960027e.1000...@erols.com Chuck Harris cfhar...@erols.com writes: : Poul-Henning Kamp wrote: : In message 495fd637.5030...@erols.com, Chuck Harris writes: : : Ok, that is news to me. Are you saying that (pulling a number out of : the air) time_t = 21120123 could be followed by 21120123 on a year where : we added a leap second? : : Apart from the number, that is exactly what happens: The last : second of the (UTC) day is recycled twice. : : As far as I remember, and as far as I can tell, what you are saying : violates both the unix and POSIX definition of time_t. : : So to check, I pulled out both of my KR editions of The C programming Language : and I did a quick google on time_t, and all of the sources I have found : concur that time_t is the number of seconds since 1/1/1970 UTC without : regard to leap seconds. That's exactly what Poul is saying. Without regard to leap seconds means that they don't exist and do not count in POSIX. A midnight time_t % 86400 must == 0, or it isn't POSIX. : When did this change? It never was clearly defined before POSIX, and POSIX made at least 4 muddled attempts to define it. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap seconds and POSIX
In message: p06240822c582a02c4...@[192.168.1.212] Joe Gwinn joegw...@comcast.net writes: : Having worked in the POSIX committee for many years, I can shed some : light on how POSIX handles leap seconds: : : In short, POSIX adamantly ignores leap seconds. All days in POSIX : have the same length, 86,400 seconds. : : This omission is not by accident, instead having been violently : debated at length, and voted upon. : : The rationale is that one cannot assume that all POSIX systems have : access to leap second information, or even the correct time, and yet : must work in a reasonable manner. In particular, file modification : timestamps must allow one to determine causal order (to within one : second in the old days) by comparison of timestamps. (Yes, people do : realize that timestamps are not the perfect way to establish causal : order, but are nonetheless widely used in non-critical applications. : Critical applications instead use some kind of atomic sequence-number : scheme.) If POSIX had allowed for the system time to be TAI, and have the offset applied for the display of times, then there would be no ambiguity. However, this is not allowed because one must be able to do math on time_t such that time_t % 86400 is midnight. : So, at least in theory, POSIX time is a form of TAI, having a : constant offset from TAI. Except that the offset isn't constant :(. : In practice, in platforms that have access to GPS, NTP is used to : servo the local computer clock into alignment with UTC (or GPS System : Time (UTC without the accumulated leaps) in systems that abhor time : steps), and there is a transient error just after a leap second while : NTP recovers. When the INS bit is set in the NTP packets, NTP tells the kernel about it, which replays the last second of the day to keep in step. I'm not sure this is a transient error or not, since ntp_gettime can be used to determine that this is the leap second for applications that care. However, it does introduce a glitch in the data produced by system interfaces that don't have leap second indicators... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap seconds and POSIX
In message: 20090101.112803.179959520@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : If POSIX had allowed for the system time to be TAI, and have the : offset applied for the display of times, then there would be no : ambiguity. However, this is not allowed because one must be able to : do math on time_t such that time_t % 86400 is midnight. time_t %86400 == 0 is midnight I should have said... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Early leap second data
My server, which is slaved to NIST's stratum 1 server, did the leap correctly: Wed Dec 31 16:59:45 MST 2008 Wed Dec 31 16:59:46 MST 2008 Wed Dec 31 16:59:47 MST 2008 Wed Dec 31 16:59:48 MST 2008 Wed Dec 31 16:59:49 MST 2008 Wed Dec 31 16:59:50 MST 2008 Wed Dec 31 16:59:51 MST 2008 Wed Dec 31 16:59:52 MST 2008 Wed Dec 31 16:59:53 MST 2008 Wed Dec 31 16:59:54 MST 2008 Wed Dec 31 16:59:55 MST 2008 Wed Dec 31 16:59:56 MST 2008 Wed Dec 31 16:59:57 MST 2008 Wed Dec 31 16:59:58 MST 2008 Wed Dec 31 16:59:59 MST 2008 Wed Dec 31 16:59:59 MST 2008 Wed Dec 31 17:00:00 MST 2008 Wed Dec 31 17:00:01 MST 2008 Wed Dec 31 17:00:02 MST 2008 Wed Dec 31 17:00:03 MST 2008 Wed Dec 31 17:00:04 MST 2008 Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Early leap second data
In message: 20090101000621.gd28...@mail.msys.ch Marc Balmer m...@msys.ch writes: : * M. Warner Losh wrote: : My server, which is slaved to NIST's stratum 1 server, did the leap : correctly: : : It did not. There can not be two equal times. Yes, it was correct. : Wed Dec 31 16:59:45 MST 2008 : Wed Dec 31 16:59:46 MST 2008 : Wed Dec 31 16:59:47 MST 2008 : Wed Dec 31 16:59:48 MST 2008 : Wed Dec 31 16:59:49 MST 2008 : Wed Dec 31 16:59:50 MST 2008 : Wed Dec 31 16:59:51 MST 2008 : Wed Dec 31 16:59:52 MST 2008 : Wed Dec 31 16:59:53 MST 2008 : Wed Dec 31 16:59:54 MST 2008 : Wed Dec 31 16:59:55 MST 2008 : Wed Dec 31 16:59:56 MST 2008 : Wed Dec 31 16:59:57 MST 2008 : Wed Dec 31 16:59:58 MST 2008 : Wed Dec 31 16:59:59 MST 2008 : Wed Dec 31 16:59:59 MST 2008 : : this is wrong. No. this is correct. POSIX time_t cannot represent the leap second, since leap seconds aren't in posix time_t's. Therefore, you have to repeat one second, and the typical one to repeat is 59. Warner : Wed Dec 31 17:00:00 MST 2008 : Wed Dec 31 17:00:01 MST 2008 : Wed Dec 31 17:00:02 MST 2008 : Wed Dec 31 17:00:03 MST 2008 : Wed Dec 31 17:00:04 MST 2008 : : Warner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : -- : Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland : http://www.msys.ch/ http://www.vnode.ch/ In God we trust, in C we code. : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD 7 ntp server
In message: b3bd5fcb0812311604q2c8f7129v9b1185457c8a9...@mail.gmail.com Robert Darlington rdarling...@gmail.com writes: : Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : system ticked :59 twice.Here's the output of my not so very : scientific logs (up arrow, enter, over and over): That's the correct output. It isn't possible to tick 60 with a POSIX time_t, so second 59 is replayed so that we don't cross a day boundary. Warner : ntp_gettime() returns code 1 (INS) : time cd0685ff.18496674 Wed, Dec 31 2008 16:59:59.094, (.094870766), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 1 (INS) : time cd0685ff.65479d28 Wed, Dec 31 2008 16:59:59.395, (.395624242), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 1 (INS) : time cd0685ff.b73eee0c Wed, Dec 31 2008 16:59:59.715, (.715804039), : maximum error 4762 us, estimated error 15 us, TAI offset 33 : ntp_adjtime() returns code 1 (INS) : modes 0x0 (), : offset -0.278 us, frequency -0.051 ppm, interval 1 s, : maximum error 4762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.03fb7a60 Wed, Dec 31 2008 16:59:59.015, (.015556955), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.50d0bb50 Wed, Dec 31 2008 16:59:59.315, (.315685712), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.9d5dc3c8 Wed, Dec 31 2008 16:59:59.614, (.614712868), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 3 (OOP) : time cd0685ff.ef985218 Wed, Dec 31 2008 16:59:59.935, (.935918664), : maximum error 5262 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 3 (OOP) : modes 0x0 (), : offset -0.277 us, frequency -0.051 ppm, interval 1 s, : maximum error 5262 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : time# ntptime : ntp_gettime() returns code 4 (WAIT) : time cd068600.4e4a6a6c Wed, Dec 31 2008 17:00:00.305, (.305823220), : maximum error 5762 us, estimated error 15 us, TAI offset 34 : ntp_adjtime() returns code 4 (WAIT) : modes 0x0 (), : offset -0.276 us, frequency -0.051 ppm, interval 1 s, : maximum error 5762 us, estimated error 15 us, : status 0x2011 (PLL,INS,NANO), : time constant 4, precision 0.001 us, tolerance 496 ppm, : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD 7 ntp server
In message: f6bol4dpdl7b5oh32h3mo18pfki549h...@4ax.com Neon John j...@johngsbbq.com writes: : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), M. Warner Losh i...@bsdimp.com : wrote: : : In message: b3bd5fcb0812311604q2c8f7129v9b1185457c8a9...@mail.gmail.com : Robert Darlington rdarling...@gmail.com writes: : : Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : : system ticked :59 twice.Here's the output of my not so very : : scientific logs (up arrow, enter, over and over): : : That's the correct output. It isn't possible to tick 60 with a POSIX : time_t, so second 59 is replayed so that we don't cross a day : boundary. : : Warner : : : I wonder how application software handled that. Say, a transaction processing : machine handling a few thousand transactions a second where the time stamp : matters. What did the high res timer do? Same thing it normally does... : I'm thinking about, for example, stock trading where the first bid wins. : Sub-second resolution is needed there, I think. That's one of many reasons why I think that leap seconds are fundamentally incompatible with POSIX. : I wonder if this was a mini-Y2K and folks haven't realized it yet? :) Warner : John : -- : John De Armond : See my website for my current email address : http://www.neon-john.com : http://www.johndearmond.com -- best little blog on the net! : Tellico Plains, Occupied TN : Alcohol, Tobacco Firearms should be a convenience store, not a government agency. : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] FreeBSD 7 ntp server
In message: 1231b6a80812312047k5d2d702djcdd9610f47bc9...@mail.gmail.com Steve Rooke sar10...@gmail.com writes: : 2009/1/1 M. Warner Losh i...@bsdimp.com: : In message: f6bol4dpdl7b5oh32h3mo18pfki549h...@4ax.com : Neon John j...@johngsbbq.com writes: : : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), M. Warner Losh i...@bsdimp.com : : wrote: : : : : In message: b3bd5fcb0812311604q2c8f7129v9b1185457c8a9...@mail.gmail.com : : Robert Darlington rdarling...@gmail.com writes: : : : Okay, not very fun. I was hoping to see ...58,59,60,00. Instead my : : : system ticked :59 twice.Here's the output of my not so very : : : scientific logs (up arrow, enter, over and over): : : : : That's the correct output. It isn't possible to tick 60 with a POSIX : : time_t, so second 59 is replayed so that we don't cross a day : : boundary. : : : : Warner : : : : : : I wonder how application software handled that. Say, a transaction processing : : machine handling a few thousand transactions a second where the time stamp : : matters. What did the high res timer do? : : Same thing it normally does... : : : I'm thinking about, for example, stock trading where the first bid wins. : : Sub-second resolution is needed there, I think. : : That's one of many reasons why I think that leap seconds are : fundamentally incompatible with POSIX. : : : I wonder if this was a mini-Y2K and folks haven't realized it yet? : : Seems to have worked perfectly under OpenSUSE 11.1, kernel 2.6.27, : with NTP here. It's just the poor Windblows systems that I worry : about. Actually, most of the effects on systems that use an absolute time for timeouts. posix threads can cause a stutter of 1s. This can be quite hard to detect in many systems, but very bad in others... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap-second happens when...??
In message: 4955f456.8000...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : Michael Baker skrev: : Hello, Time-Nutters-- : : I must have missed something... I have known about : the coming leap-second for months, but have not heard : when it was going to be inserted. : : When will the leap-second take place? : : A leap-second can be inserted or removed at the end of the last minute : of a month in UTC. : : Normal transition: : 23:59:58 : 23:59:59 : 00:00:00 : : Adding a leap second: : 23:59:58 : 23:59:59 : 23:59:60 : 00:00:00 : : Removing a leap second: : 23:59:58 : 00:00:00 : : The first preference on which month to insert them is first to the June : and December. : : The second preference is on Mars and September. I assume you mean 'May' here. The standard additionally allows for leap seconds at the end of any month. However, there's a lot of software out there that will be dodgy for the Secondary times, and not work at all for the others. : You naturally need to convert to your local time zone to get a little : more aid on when it happens, but for Florida it will occur at 18:00 : (UTC-6h) on Wednesday where as for me it will occur at 1:00 (UTC+1h) on : Thursday. : : Will it hurt? : : No. : : Am I going to need a band-aid? : : No. : : Or just another rum-laced egg-nog...?? : : Yes. Sounds like a good idea. But don't drink it all during the : leap-second, that would be a waste of perfectly good egg-nog. : : Cheers, : Magnus : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap-second happens when...??
In message: 4956d398.6060...@rubidium.dyndns.org Magnus Danielson mag...@rubidium.dyndns.org writes: : : : The first preference on which month to insert them is first to the June : : and December. : : : : The second preference is on Mars and September. : : I assume you mean 'May' here. : : No. Read on. (spelt March incorrectly. sorry) : : The standard additionally allows for : leap seconds at the end of any month. However, there's a lot of : software out there that will be dodgy for the Secondary times, and not : work at all for the others. : : TF.460-4 says: : : A positive or negative leap-second should be the last second of a UTC : month, but first preference should be given to the end of December and : June, and second preference to the end of March and September. : : There is an incorrect interpretation that only December and June are : allowed. Another incorrect interpretation is that only March, June, : September and December is allowed. Each month is allowed. There is only : a preference towards the others. The flagging of upcoming leap second : occuring in December already in July is ambiguous. Ah well. : : Anyway, the TF.460-4 is very clear on it. May is allowed, but not preferred. Yes. But there's very little software that actually implements the secondary months, let alone the others. There's been cases where the GPS constellation turned on leap indicator before the end of September and the HP Oscilloquartz GPSDO clocks glitched at the end of September due to a bug in the firmware... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Cesium tube ion pumps
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Corby, : : AT what point would be approp to call symmetricom and complain about defective : tube?I still have 2 years on the 5 yr warranty left, but how do u explain this : (defect),,(I assume it will just keep rising and eventually ruin the tube within : a few yrs?)last I checked they wanted about 28k for a new tube. : : the unit with high perf tube has 5 yr warr from date of manuf. and cost 59k new. You should call them and find what their replacement policy for tubes is. They might not define it as defective now, but can tell you when they will define it as such... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Voltage standards
In message: [EMAIL PROTECTED] Bruce Griffiths [EMAIL PROTECTED] writes: : Cryogenic standards arent really feasible for home use as most require : liquid helium coolant. This has got to be one of the best lines in a time-nuts email :) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Voltage standards
The thing that got me was the word 'really' in Bruce's statement. It read like someone who had tried it, had limited success, but in the end wound up believing that while possible, it wasn't really practical. After thinking that, I couldn't imagine that somebody on the list hadn't tried it for some reason or another over the years. After all, as you say, a fine bottle of scotch isn't that expensive when it comes to the pursuit of your obsessions :) Warner In message: [EMAIL PROTECTED] Lux, James P [EMAIL PROTECTED] writes: : Exactly.. I'm sure I'm not the only one on this list that has contemplated home use of liquid helium or even making the stuff. Hey, if Onnes could do it 100 years ago, so can we. : : I assume the cryogen isn't being used for superconductivity in this case, but for just being cold. In which case, perhaps LH2 or LN2 would serve almost as well. The latter, particularly, is pretty manageable (i.e. You don't have to make it yourself). : : Cost wise, I like the snippet I read in Scientific American a decade or so ago.. LN2 is the cost of milk, LHe is the cost of fine scotch whisky : Is a obsessive precision worth a bottle of scotch? : : Jim : : On 11/30/08 2:13 PM, M. Warner Losh [EMAIL PROTECTED] wrote: : : In message: [EMAIL PROTECTED] : Bruce Griffiths [EMAIL PROTECTED] writes: : : Cryogenic standards arent really feasible for home use as most require : : liquid helium coolant. : : This has got to be one of the best lines in a time-nuts email :) : : Warner : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] NIST tours
In message: [EMAIL PROTECTED] Robert Darlington [EMAIL PROTECTED] writes: : I see NIST has no official tours currently, but am wondering if they do this : for weirdos that are into this sort of thing as compared to the general : public. I'm finding myself in Boulder more often due to work and would love : to eyeball the latest and greatest gadgetry. Also, as a ham operator, I : lust after the transmitter equipment up in Fort Collins. If you have the right connections, you can get a tour still... I was there for a time and frequency symposium a year ago and got a tour then... Also, got a briefer tour of the atomic clocks a year or two before that when I went to check up on some gear that my old company had there measuring the atomic clocks... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Fwd: M12+T ASCII interface - I'm confused?
In message: [EMAIL PROTECTED] christopher hoover [EMAIL PROTECTED] writes: : tvb wrote: : I hope you end up liking the binary format; I'm not sure how it could : be improved. : : IIRC, there's no length field in the packet; so you have to know the length : of all the messages you might possibly rx, even if you are interested in : just a few of them. IIRC, you just have to know... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
In message: [EMAIL PROTECTED] Eric Garner [EMAIL PROTECTED] writes: : Ascending from Lurk Mode, I have a (possibly stupid) question: according to : : http://tycho.usno.navy.mil/leapsec.html : : and Tony Jones's book The Story of Atomic Time GPS time does not : account for leap seconds, So why does it alert you to them? GPS's almanac contains the GPS to UTC offset (current, and future). It is repeated every 20 minutes, which means it can take 20 minutes for a cold startup to learn the current number of leapseconds... Warner : -eric : : On Sun, Nov 16, 2008 at 7:21 PM, Hal Murray [EMAIL PROTECTED] wrote: : Is anybody running ntpd with their Z3801A? : : If so, please check your log files and tell me if you see a bogus leap second : at the end of the past several months. I've seen them for Aug, Sep, and Oct. : I think they are coming from my Z3801A, but it might be something else. : : The GPS satellites are now announcing a leap second that will happen at the : end of the year. The refclock driver passes that to ntpd and ntpd passes it : to the kernel and magic happens. : : I think the refclock-ntpd interface assumes the leap second will happen at : the end of the current month. NIST only announces leap seconds a month ahead : on WWVB and ACTS. : : The Oncore refclock driver has a filter to wait until the current month to : pass the info to ntpd. I'm working on something similar for the HP driver. : : -- : These are my opinions, not necessarily my employer's. I hate spam. : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : -- : --Eric : _ : Eric Garner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
In message: [EMAIL PROTECTED] Eric Garner [EMAIL PROTECTED] writes: : Sorry for not forming my question better. I guess what I wanted to : know is that given that the first leap second was in 1972 and that the : first GPS satellite was launched in 1993. why was it decided to not : incorporate leap seconds into how GPS tells time, but still alerts : you to the fact that they are coming up? Or why was the decision made : to have UTC-GPS different than UTC. My understanding is that they : tick simultaneously but tell different times.(sorry for the : overuse of quotes) Is there some navigational reason? Is it actually : intentional? Leap seconds suck. There's no reason to have them unless you need time to sync up with the way that the earth is pointing. GPS doesn't need to synchronize to the earth's directions to solve for location, so it saves a ton of hassles by just counting seconds since an arbitrary epoch. Since UTC is important, GPS's almanac gives the conversion from GPS to UTC. Warner : -eric : : On Sun, Nov 16, 2008 at 8:08 PM, Brooke Clarke [EMAIL PROTECTED] wrote: : Hi Eric: : : So that you can figure out UTC. But there's no DST bit on any of the : satellites so for that you need a local time broadcast. : : : Have Fun, : : Brooke Clarke : http://www.prc68.com : : Eric Garner wrote: : Ascending from Lurk Mode, I have a (possibly stupid) question: according to : : http://tycho.usno.navy.mil/leapsec.html : : and Tony Jones's book The Story of Atomic Time GPS time does not : account for leap seconds, So why does it alert you to them? : : -eric : : On Sun, Nov 16, 2008 at 7:21 PM, Hal Murray [EMAIL PROTECTED] wrote: : Is anybody running ntpd with their Z3801A? : : If so, please check your log files and tell me if you see a bogus leap second : at the end of the past several months. I've seen them for Aug, Sep, and Oct. : I think they are coming from my Z3801A, but it might be something else. : : The GPS satellites are now announcing a leap second that will happen at the : end of the year. The refclock driver passes that to ntpd and ntpd passes it : to the kernel and magic happens. : : I think the refclock-ntpd interface assumes the leap second will happen at : the end of the current month. NIST only announces leap seconds a month ahead : on WWVB and ACTS. : : The Oncore refclock driver has a filter to wait until the current month to : pass the info to ntpd. I'm working on something similar for the HP driver. : : -- : These are my opinions, not necessarily my employer's. I hate spam. : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : -- : --Eric : _ : Eric Garner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Testing frequency using NTP
In message: [EMAIL PROTECTED] David M. Witten II [EMAIL PROTECTED] writes: : Will a usable build of FreeBSD 7.x run in the memory available on the : older Soekris boards? (64 MB RAM) No. My router/dhcp server, mail forwarding anti-spam agent, external DNS server are all on my soekris 4521. I'm running 7.0 on it. It only has 64MB of memory and I've never had memory problems. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Testing frequency using NTP
In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : In message: [EMAIL PROTECTED] : David M. Witten II [EMAIL PROTECTED] writes: : : Will a usable build of FreeBSD 7.x run in the memory available on the : : older Soekris boards? (64 MB RAM) : : No. My router/dhcp server, mail forwarding anti-spam agent, external : DNS server are all on my soekris 4521. I'm running 7.0 on it. It : only has 64MB of memory and I've never had memory problems. Errr, I should have said 'Yes.' My no was answering the question 'Will it run out of memory?' %vmstat procs memory page disk faults cpu r b w avmfre flt re pi po fr sr ad0 in sy cs us sy id 0 0 0 38492 225762 0 0 0 1 0 0 1354 25 488 1 3 96 Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] What's the time Mr Wolf...
In message: [EMAIL PROTECTED] Steve Rooke [EMAIL PROTECTED] writes: : 2008/10/31 Tom Van Baak [EMAIL PROTECTED]: : : 11) Extrapolating this, a point on the Equator would be moving faster : that a point at the poles or even Greenwich, for that matter. So would : a clock at each location move out of synchronisation with each other? : : Yes, and this also is taken into account. When you get down : to measuring absolute frequency at 1e-14 and 1e-15 levels one : always takes the local gravitational field into account, which is : mostly a function of altitude, but also latitude. : : Guess I've been dumb here but this must mean that not only is time : affected by relativistic effects but also oscillators as well then. Yes. Oscillators will still resonate in their frame of reference at their normal rate. If that frame of reference is slightly different than the defined standard frame of reference, then you need to take that into account when you are comparing frequency data with others in a two-way time exchange. The objective is to tick at the same rate as the standard frame, when the standard frame is measured from your frame of reference... : If gravity affects frequency, can this effect be seen as a daily : change in the EFC voltage of a GPS locked standard as caused by the : Moon? Does this also affect the frequency of the atomic standards used : to measure time? All this must make the measuring of absolute : frequency to the high orders of accuracy quite complex. Gravity affects time. The problem devolves into the classic case of trying to keep things in sync between different frames of reference. The tidal effects are much smaller than those from position. I don't think that these effects are visible at the 10-14 or 10-15 level, but since I don't know what level they are visible at, I can't be sure. I'm sure that someone on this list, maybe as part of their PhD thesis, has measured this and can report it :-) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] How can it be :05 in one place and :30 in another
In message: [EMAIL PROTECTED] Gretchen Baxter [EMAIL PROTECTED] writes: : I am confused. : : Why do they do that? what is the benefit? Better correspondence of local time to solar time when the population centers of the time zones are located near the boundary of a time zone... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Exceptions...
In message: [EMAIL PROTECTED] Magnus Danielson [EMAIL PROTECTED] writes: : Lux, James P wrote: : : : On 10/26/08 9:45 AM, Burt I. Weiner [EMAIL PROTECTED] wrote: : : Except for the flat or pointy places. : : Burt, K6OQK : : At 05:00 AM 10/26/2008, [EMAIL PROTECTED] wrote : At 10:44 PM 10/25/2008, Gretchen Baxter wrote... : I went to http://www.timeanddate.com/worldclock/ : : I saw that it was 10:35 in New York but in Adelaide it was 1:05 PM and : in : New Delhi 8:05. : : How can that be? : The world is round. : In the context of time-nuts, where we denigrate mere 1 ppm accuracy and talk : about parts in 1E12 and more.. The Earth, being ellipsoidal by about a part : in 300, is hardly round. : : OK... it's a fairly ellipsoid object... and not flat. And the 1/2 time zones have nothing to do with the shape of the earth in fine detail, but rather the fact that it is somewhat ball-like in a gross, part in 10 sort of way :-)[*] Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] How can it be :05 in one place and :30 in another
From: Gretchen Baxter [EMAIL PROTECTED] Subject: [time-nuts] How can it be :05 in one place and :30 in another Date: Sat, 25 Oct 2008 22:44:54 -0400 Hi, I went to http://www.timeanddate.com/worldclock/ I saw that it was 10:35 in New York but in Adelaide it was 1:05 PM and in New Delhi 8:05. How can that be? 1/2 hour offset timezones are more common than you think. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] How many seconds in a year?
In message: [EMAIL PROTECTED] David Forbes [EMAIL PROTECTED] writes: : So there is no way to build a clock today that is guaranteed to count : seconds correctly in future years, short of having it receive leap : second announcements twice a year and adjust its timekeeping : accordingly. Unless it has a built-in sundial :-) Warner P.S. And even then only if DUT1 is held 1s ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap Second Pending
In message: [EMAIL PROTECTED] randy warner [EMAIL PROTECTED] writes: : This is typical. The Air Force inserts this flag into the almanac well : before the actual event (normally about 6 months) to allow users to prepare : for it. Yes. All the old clocks that stuttered and did the leap second at the 'alternative date' have updated their firmware to not do that anymore... Although the standard says any month, it also says that June/December are primary, with March/September being secondary. I believe it was the Oscilloquartz GPS disciplined clock that did this for sure, and has been reported here. It would be nice if there were more than 6 months of notice for these things, but I don't want to get into that whole debate again here... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Trimble T-Bolt Dumb Question
In message: [EMAIL PROTECTED] Richard W. Solomon [EMAIL PROTECTED] writes: : How does one determine that they are locked to the GPS system ? : If I look at TboltMon I see lots of data, but nowhere do I find a : specific statement that I am locked. : : The output frequency is accurate and stable enough to be locked and : I see I have anywhere from 5 to 8 satellites tracked, but Usually locked to a GPS system just means that the oscillator that's controlled by the GPS is operating within some set of prescribed parameters and that the GPS receiver itself is a 'good enough' source of time. The exact definition of good enough varies quite a bit from system to system. You basically have to look at the numbers from your control loop, as well as self diagnostics from the GPS receiver to know if there's a lock or not. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] New leap second
In message: [EMAIL PROTECTED] Ronald Held [EMAIL PROTECTED] writes: : I just got that bulletin. I will have to adjust all of the programs : using the update data from the Astronautic Almanac when the next one : is issued. Yes, this is one of the problems with leap seconds. Opinions differ here as to their relevance and suitability to solving the clock skew problem. :-) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] cesium clocks..
In message: [EMAIL PROTECTED] John Miles [EMAIL PROTECTED] writes: : Maybe try : : hp (5071a,5061a,5061b) : : ... to start with. : : The 5071as seem more desirable but they're also usually more expensive, and : (the really scary part, true of all of them): how do you tell how much tube : life is left? Beam Tube Voltage? Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] time-nuts Digest, Vol 47, Issue 5
In message: [EMAIL PROTECTED] Bruce Griffiths [EMAIL PROTECTED] writes: : Don Collie jnr wrote: : I`m curious : What is a virgin teflon standoff, and does it have anything : to do with the teflon Don? : ...Don : C. : : : Don : : In this context virgin teflon means machined from solid teflon and not : welded together from grains of teflon. I spent about 10 minutes trying to think of a teflon Don or teflon coated president joke and couldn't work in a virgin teflon standoff. The truth is so, anticlimactic afterwards Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Another query on the 5065A
I would have to look in the manual to be 100%, but for 90%, I think the synchronize button is just to synchronize the 1pps pulse with an external 1pps reference. It is a clock (i.e., time) function NOT a frequency function. The 5071A's are like that. Sync means align the PPSes and the 5MHz phase to be within a few nanos. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Best OS for small time server
In message: [EMAIL PROTECTED] Robert Vassar [EMAIL PROTECTED] writes: : I successfully ran these network services sans network filesystems on : a 1Gb USB memory stick for about 8 months. It was completely silent, : and the total power draw was roughly 5 watts. The problem I ran into : is that Linux implements a POSIX compliant filesystem. Even taking : steps to eliminate swap, the never ending filesystem metadata updates : burned up my little flash drive in less than a year. BSD will not : escape this problem. It will be true on any system that records file : access/modify timestamps. There might be a way to turn them off, or : you might be able to mount certain partitions read-only. mount -o noatime will fix this on BSD. I've deployed 32MB CF with this in the field that have survived for 6 years now. I did have two partitions: the binaries were in a read only file system. The modified data went into a separate partition mounted -o noatime. I thought linux also had a noatime option... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] sync computer clock ticks
In message: [EMAIL PROTECTED] Michael Di Domenico [EMAIL PROTECTED] writes: : I've used NTP for years, but i was under the impression that it is not : able to synchonize the clocks below 1 or 2 seconds. Can you point me : towards a specific article that speaks about the configuration : parameters to get ntp sync'd that low? I don't know about other people, but out of the box I get sub 20ms synchronization. Right now, it is sitting at about 12.5ms: remote refid st t when poll reach delay offset jitter == *x.yy.co 10.7.1.1 2 u 965 1024 377 64.176 -12.570 0.508 My config file is just a simple: server 1.2.3.4 # x.yyy.com driftfile /mod/etc/ntp.drift restrict default notrust nomodify restrict 127.0.0.1 restrict 1.2.3.4 restrict 10.0.0.6 restrict 10.0.0.0 mask 255.255.0.0 notrust ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] sync computer clock ticks
In message: [EMAIL PROTECTED] michael taylor [EMAIL PROTECTED] writes: : On Jan 4, 2008 12:03 PM, M. Warner Losh [EMAIL PROTECTED] wrote: : : I don't know about other people, but out of the box I get sub 20ms : synchronization. Right now, it is sitting at about 12.5ms: : : remote refid st t when poll reach delay offset jitter : == : *x.yy.co 10.7.1.1 2 u 965 1024 377 64.176 -12.570 0.508 : : : That's a 12 ms offset from UTC, as far as I understand the original : poster only needs = 1 microsecond synchronization on his local : network. I have no experience with gige networks, but the best I've been able to do on 100baseT networks is 50us. I'm unsure what 1us synchronization really means, since that's starting to get below the level of system calls on fast machines. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] sync computer clock ticks
In message: [EMAIL PROTECTED] Christian Vogel [EMAIL PROTECTED] writes: : For example, do you want to timestamp interrupts to synchronize : machinery? Or just note down the timestamps of bittorrent downloads very : precisely? Just synchronizing an otherwise idling computer is probably : much easier than a machine that is doing a lot of additional work that : can mess up the timekeeping by clogging the processor or just creating : varying stress on the power-supply lines. That's the real question. Like I said before, when you are down to the microsecond level, what good is that? The jitter from system calls and such is going to be high enough to make that not completely useful. And if you are trying to do things to hardware with software that requires that level of synchronization, you aren't going to get it without timestamping done in hardware of some mutually observable event (pps, packets on the network, etc). Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] sync computer clock ticks
In message: [EMAIL PROTECTED] Bruce Griffiths [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Christian Vogel [EMAIL PROTECTED] writes: : : For example, do you want to timestamp interrupts to synchronize : : machinery? Or just note down the timestamps of bittorrent downloads very : : precisely? Just synchronizing an otherwise idling computer is probably : : much easier than a machine that is doing a lot of additional work that : : can mess up the timekeeping by clogging the processor or just creating : : varying stress on the power-supply lines. : : That's the real question. Like I said before, when you are down to : the microsecond level, what good is that? The jitter from system : calls and such is going to be high enough to make that not completely : useful. And if you are trying to do things to hardware with software : that requires that level of synchronization, you aren't going to get : it without timestamping done in hardware of some mutually observable : event (pps, packets on the network, etc). : : Warner : : PTP achieves submicrosecond synchronisation over small LANs without : network switches. : It uses hardware time stamping of LAN packets. Right. This is hardware time stamping of mutually observable events (the two way time exchange). One can measure down to nanosecond levels with custom hardware with 1588. Sam Stein presented a paper at 2006 PITI that talked about an average of 2.5ns with a standard deviation of 0.9ns in measuring clock differences. : Someone has even implemented it in software (with degraded performance). : See: : http://ieee1588.nist.gov/ Right, and the performance here is not much better than ntp, at least in the tests that I've done. The jitter is slightly better. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Of rubidium life and piggy-bank anemia....
In message: [EMAIL PROTECTED] Bruce Griffiths [EMAIL PROTECTED] writes: : The conventional approach adopted by NIST is to divide each frequency to : be measured down to 1 PPS, then timestamp the PPS transitions for each : channel as well as the PPS transitions from a GPS timing receiver. By : using the same setup at NIST with their frequency standards most of the : noise due to ionospheric delay variations is a common to both systems : and is eliminated on subtraction. NIST has gone to an approach where the signal under test is heterodyned with a signal that's ~10Hz low. Since one cycle in the test frequency is one cycle in the heterdyned frequency, you can get measurements of signal down to the noise floor of your hardware (since even a simple 32MHz counter gives one several order of magnitude better than the noise in the zcds). At 10MHz, the heterodyne factor is 1e9. This means you can measure the phase difference of the signal to 31.5e-18 (assuming a 32MHz clock). Since the noise in the 32MHz oscillator is at 1e-13, we can measure the 10MHz down to a few parts 1e-13 (since the noise dominates over the resolution of the measurement). With a better oscillator, one can hit the noise floor of the ZCDs that we used in the project with a more stable 32MHz oscillator (down to 1e-14 or 5e-15 or so in some of the tests I ran in the lab). The 32MHz oscillator is a relatively cheap OCXO. The design of the system is such that almost all of the 32MHz noise subtracts out... The noise is such that switching to 100Hz gives a factor of 3 better noise floor. But any faster than that doesn't help much. A 2Hz signal is 5x worse noise floor because the 32MHz noise starts to dominate. With a good quality TIC, one is doing good to get PPS measurements in the picosecond level (1e-12). But that's a lot more expensive than the above device. At least that's what NIST is using to measure the cesiums in its clock ensemble. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Chronometer contest sponsored by IEEE Spectrum
In message: [EMAIL PROTECTED] Jeffrey Pawlan [EMAIL PROTECTED] writes: : : : On Thu, 29 Nov 2007, David Forbes wrote: : : It might be more fun to require that an OCXO be designed and built by : the DIY-er out of commercially available crystals and resistors. That : way, it's an engineering challenge instead of a procurement : challenge, since IEEE is about engineering. : -- : : : I second David's suggestion! The only REAL challenge would be to design the : circuitry. Otherwise this is just a rack stack project which is not : engineering. If it wasn't for the $100 price point, I have exactly this in my office right now: Our product displays the time on 7-segment LEDs. However, our cost is somewhat more than $100 since we have an OCXO, a TCXO, a GPS receiver, an ARM and an FPGA plus lots of sheet metal and slots in the back for distribution modules. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] LORAN-C
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : Can someone confirm that the E10 to E13 errors are typical : of the 2100F? And what ultimate long-term stability have others : been able to achieve using LORAN as a reference? : : Long term is perfect because LORAN-C is steered to UTC, at least : here in nothern europe. USA also steers LORAN-C to UTC, less the UTC LORAN-C timescale delta. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Danish Question
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY I must admit that this reminds me of the only Dane I know really well, and who happens to be a frequent contributor to this list. I can just see him saying If you would like a nice new barometer... :-) Warner In message: ![EMAIL PROTECTED] Rob Kimberley [EMAIL PROTECTED] writes: : ); SAEximRunCond expanded to false : Errors-To: [EMAIL PROTECTED] RETRY : : Completely off topic, but thought this might amuse you all. : : Rob K : : : The following concerns a question in a physics degree exam at the University : of Copenhagen: : : : Describe how to determine the height of a skyscraper with a barometer. : : : One student replied: : : : You tie a long piece of string to the neck of the barometer, then lower the : barometer from the roof of the skyscraper to the ground. The length of the : string plus the length of the barometer will equal the height of the : building. : : : This highly original answer so incensed the examiner that the student was : failed immediately. He appealed on the grounds that his answer was : indisputably correct, and the university appointed an independent arbiter to : decide the case. The arbiter judged that the answer was indeed correct, but : did not display any noticeable knowledge of physics. To resolve the problem : it was decided to call the student in and allow him six minutes in which to : provide a verbal answer which showed at least a minimal familiarity with the : basic principles of physics. For five minutes the student sat in silence, : forehead creased in thought. The arbiter reminded him that time was running : out, to which the student replied that he had several extremely relevant : answers, but couldn't make up his mind which to use. On being advised to : hurry up the student replied as follows: : : : Firstly, you could take the barometer up to the roof of the skyscraper, : drop it over the edge, and measure the time it takes to reach the ground. : The height of the building can then be worked out from the formula H = 0.5g : x t squared. But bad luck on the barometer. : : : Or if the sun is shining you could measure the height of the barometer, : then set it on end and measure the length of its shadow. Then you measure : the length of the skyscraper's shadow, and thereafter it is a simple matter : of proportional arithmetic to work uut the height of the skyscraper. : : : But if you wanted to be highly scientific about it, you could tie a short : piece of string to the barometer and swing it like a pendulum, first at : ground level and then on the roof of the skyscraper. The height is worked : out by the difference in the gravitational restoring force T = 2 pi sqrroot : (l/g). : : : Or if the skyscraper has an outside emergency staircase, it would be easier : to walk up it and mark off the height of the skyscraper in barometer : lengths, then add them up. : : : If you merely wanted to be boring and orthodox about it, of course, you : could use the barometer to measure the air pressure on the roof of the : skyscraper and on the ground, and convert the difference in millibars into : feet to give the height of the building. : : : But since we are constantly being exhorted to exercise independence of mind : and apply scientific methods, undoubtedly the best way would be to knock on : the janitor's door and say to him 'If you would like a nice new barometer, I : will give you this one if you tell me the height of this skyscraper'. : : : The student was Nils Bohr, the first Dane to win the Nobel prize for : Physics. : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] OT: You know your getting old when...
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY In message: [EMAIL PROTECTED] Tom Van Baak [EMAIL PROTECTED] writes: : And a time nut if you wonder if that's 80 kHz or 80.000 kHz Or if you invent some ascii way to put a little bar over the last significant digit... 8 vs _ 8 :-) Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Estate Sale find
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY I went to an estate sale today. I discovered a bunch of manuals from some guy that once had an electronics business. I didn't find the items they described, but I thought people here might be interested: (1) Rycom Instruments Model 2174A-610B Selective Voltmeter FSN 6625-062-4228 (2) Instruction Manual, Tektronics Type 503 Oscilloscope (3) 2 envelopes (4 thick total) labeled NBS Time Receiver. Anybody have interest in these. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Estate Sale find
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY In message: [EMAIL PROTECTED] Alan Melia [EMAIL PROTECTED] writes: : ); SAEximRunCond expanded to false : Errors-To: [EMAIL PROTECTED] RETRY : : Hi Warner there have been queries asking for Rycoms on the LWCA message : board and reflector I will risk your wrath and forward a posting there for : you OK. But this manual is the only one I had, and the sale is now over. Warner : Regards : Alan G3NYK : : - Original Message - : From: M. Warner Losh [EMAIL PROTECTED] : To: time-nuts@febo.com : Sent: 04 August 2007 23:23 : Subject: [time-nuts] Estate Sale find : : : I went to an estate sale today. I discovered a bunch of manuals from : some guy that once had an electronics business. I didn't find the : items they described, but I thought people here might be interested: : : (1) Rycom Instruments Model 2174A-610B Selective Voltmeter FSN : 6625-062-4228 : (2) Instruction Manual, Tektronics Type 503 Oscilloscope : (3) 2 envelopes (4 thick total) labeled NBS Time Receiver. : : Anybody have interest in these. : : Warner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to : https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Estate Sale find
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : : (3) 2 envelopes (4 thick total) labeled NBS Time Receiver. These appear to be related to the design of a ATS-3 receiver, plus a lot of NBS technical publications, schematics, parts lists, prices for the parts, some interesting business letters and the like. A very odd collection. Clearly somebody's personal files on a project they wanted to keep mementos of for many years... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Timing on Ethernet
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Looking at the IEEE 1588 while implementing in your own FPGA seems like an odd choice. It is an option, but you could fairly easy cook up something which fits your needs. It is not too hard actually. The main reason that Timing Solutions did its FPGA was to try to get down to sub-nanosecond level. That's very hard to do without hardware assist. And much of the available hardware assist is only good to approximately pci clock or a 25MHz clock, which was far too inaccurate to push the limits. The Timing Solutions experiments were designed to specifically push the limits of the technology as far as possible, to be NIC neutral and to discover the problems in developing the technology. All of this information should be in the Sam Stein, et al, paper, but I was only able to find the slides he talked from at http://ieee1588.nist.gov/2006%20IEEE1588%20Agenda/Stein_Sub-nanosecond%201588%20final.pdf His results showed ~98% of the measurements were in the +-2.5ns timing bin with a sigma of 0.9ns. This was on a cross-over cable, and when a hub was introduced the timing numbers became worse (a nearly uniform distribution over +/- 20ns). Most users of IEEE1588 don't need this level of performance, and can get by with cheaper solutions. Most people don't need a Cs standard either, but some small segment does. Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Basic Stratum 1 question
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY From: Jared Morrisen [EMAIL PROTECTED] Subject: [time-nuts] Basic Stratum 1 question Date: Thu, 2 Aug 2007 11:32:06 -0400 ); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] RETRY Hi, I am having a debate with our CIO. He wrote in a memo about timing: *Local hardware is to be considered Stratum 1, since it get time from its own CMOS.* I told him that absurd and that it can't be considered stratum 1. Please clarify. Stratum 1, in the ntp world, is a source that's connected to an official source of time (the so-called Stratum 0). The CMOS clock isn't connected to NIST, therefore it can't be considered Stratum 1 by any stretch of the imagination. Also, Stratum 1, in telco, has certain performance requirements. These timing requirements are relatively stringent. Even using an insanely generous specification of 1ms and 1ppm, an unsciplined PC clock cannot meet that spec for more than a few seconds given that the typical frequency error is on the order of ~100ppm. In short, your CIO is mistaken[*]. Warner [*] Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Oncore VP problem
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] In message: [EMAIL PROTECTED] Dr Bruce Griffiths [EMAIL PROTECTED] writes: : If one booted a FreeBSD machine with an active GPS timing receiver : connected to a serial port, the serial buffers would overflow. : This problem/feature appears to have since been fixed, at least for : FreeBSD6.1. Well, the warnings that told you that data was being thrown away were removed. They never were a problem other than to be noisy on the console for no good reason... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Cs stability
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] In message: [EMAIL PROTECTED] Tom Van Baak [EMAIL PROTECTED] writes: : ); SAEximRunCond expanded to false : Errors-To: [EMAIL PROTECTED] : : In the article OBSERVATIONS ON STABILITY MEASUREMENTS : OF COMMERCIAL ATOMIC CLOCKS, Pekka Eskelinen claims to : have measured a phase temperature coefficient of 100ns/degree : for commercial Cs clocks in 1999. : : Something is wrong with that claim. There's no way a modern : cesium standard exhibits a phase shift of 100 ns for a one : degree change in ambient temperature. I have Cs standards : that often change in temperature by several degrees and still : keep to nanoseconds. I guess I need to decode that paper : and see what's wrong. Does anyone have contact with the : authors (Finland)? We have HP5071A's that keep to about 5ns over the course of a typical heading/cooling cycle measured relative to GPS. This is over a range of maybe 15C in the summer... Warner ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] COMPASS
Anybody know anything about China's COMPASS system that is being deployed? Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] On Setting the Astronomical Time
In message: [EMAIL PROTECTED] Hal Murray [EMAIL PROTECTED] writes: : : Is there some way to get TT to better than a tenth of a second, or is : the earth just too sloppy of a time keeper? : : My guess... : : The earth is sloppy on this scale. If it wasn't, we could predict leap : seconds. UT1 is a smoothed function, not an instantaneous one, since it factors out seasonal variation that's in UT2. NIST doesn't publish DUT1 more accurately than milliseconds with a +/- 5ms caveat. So +/- 100ms is only 20x worse than data published at nist. Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Pendulums Atomic Clocks Gravity
In message: [EMAIL PROTECTED] Bill Beam [EMAIL PROTECTED] writes: : 'Free fall' implies that g is not zero! : : If g=0 was true, then the satellite would not be falling at all. : It is beacuse g is not zero, that the satellite is in 'orbit' rather : than moving off in a straight line. Einstein showed that the effects of gravity were indistinguishable from acceleration. People are confusing weightlessness, where the forces of gravity are balanced, with the absence of a gravitational field. Moving the GPS master clocks to the satellites would indeed bring in relativistic effects because they are accelerating continuously. Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] 15 ns vs. 15 nS
As Seconds are a fundamental unit of the SI system, shouldn't the S be upper case? SI units named after famous dead guys are capitalized (cf Farad (F), Hertz (Hz), etc). SI units that are something else aren't (cf meter (m), liter (l) and gram (g)). Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] NTP Synchronised Nixie Tube Clock
In message: [EMAIL PROTECTED] John Miles [EMAIL PROTECTED] writes: : No kidding. That clock would be equally at home in Blade Runner or : Triumph des Willens. Or add a Fresnel lens and pop that bad boy down inside of Brazil. Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] OT: eBay bidding question
In message: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : : In a message dated 4/26/2007 05:23:48 Pacific Daylight Time, [EMAIL PROTECTED] : writes: : : Can anyone propose a sequence of bids on dates that explains this list : of recorded bids and dates? I guess there must be one but it is evading : me. : : : *Bidder*Bid AmountDate of bid :Bidder 6US $4,000.00 Apr-22-07 05:14:15 : Bidder 8US $4,000.00 Apr-25-07 00:49:30 : : : Could this be because of bid retractions or simply revising a bid? : : Are the times/dates local time or Ebay UTC? All of them are UTC. This happens all the time. If bidder 6 bid $4000 before bidder 8, as is indicated here, then bidder 6 wins because his bid is first. Sort of a 'tie goes to the runner' sort of resolution. Warner ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
