Re: [time-nuts] Method for comparing oscillators
In message: "Lux, Jim (337C)" 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] Trivia
In message: <189c907750%ja...@jrmiller.demon.co.uk> James R Miller writes: : : > I'll wait to 2009-08-07T06:05:04.03Z. : : Perhaps 09-09-09 09:09:09 is non-divisive ... But is that 2009-09-09 09:09:09 or 09-09-2009 09:09:09. The difference matters you 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] Motorola M12+ or M12M questions
In message: <4a533c36.1030...@rubidium.dyndns.org> Magnus Danielson 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 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: <4813.1245444...@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20090619.143448.2102305600....@bsdimp.com>, "M. Warner Losh" writes : : : >In message: <4a3bf553.20...@rubidium.dyndns.org> : >Magnus Danielson 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] [Fwd: GPS 256 week rollover may be causing problems for some GPS receivers]
In message: <4a3bf553.20...@rubidium.dyndns.org> Magnus Danielson 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] Z3805 initial behaviour after power up revised
In message: "Francesco Ledda" 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
Re: [time-nuts] FE-5680A heat sink
In message: <4a2d60a2.3030...@erols.com> Chuck Harris 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: "Lux, James P" writes: : : : : On 5/24/09 8:32 AM, "Bob Paddock" 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] 5070B once more.... (actually 5370A fans)
In message: <20090522185851.4137db...@ip-64-139-1-69.sjc.megapath.net> Hal Murray writes: : : rich...@karlquist.com said: : > First of all, the 5071A has to be able to run on a battery, so you can : > do the flying clock experiment. : : Did you have any trouble convincing the airlines and/or FAA that it was safe : to take an atomic clock on a plane? : : I'd be more worried about the big batteries than the cesium. Most clock flying experiments are done on military aircraft 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: "Lux, James P" writes: : : : : On 5/19/09 1:15 PM, "Russell Rezaian" 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: <20090519095316.1e1f4b46.att...@kinali.ch> Attila Kinali writes: : On Sat, 16 May 2009 15:09:07 + : "Poul-Henning Kamp" 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] FreeBSD, NetBSD, or Minix-III?
In message: "Lux, James P" 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 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: Bob Paddock writes: : On Sat, May 16, 2009 at 9:21 AM, Chuck Harris 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: <20090515152610.gi2...@vanheusden.com> Folkert van Heusden 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: <20090515142600.gg2...@vanheusden.com> Folkert van Heusden 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: <4a0d0fa0.3020...@tiscali.co.uk> Dave Ackrill 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: <20090514223310.0d552b...@ip-64-139-1-69.sjc.megapath.net> Hal Murray 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] Linux time servers
In message: <20090514220030.68e47b...@ip-64-139-1-69.sjc.megapath.net> Hal Murray 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: <4a0c7a74.50...@tiscali.co.uk> Dave Ackrill 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] Certichron
In message: <4fdb424f0904281038n7ef92dc1j117ab1eca8735...@mail.gmail.com> Gretchen Baxter 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] NIST Time & Frequency Seminar
In message: Jim Palfreyman writes: : Damn I would love to go to that. But the US$1900 would be cheap bikkies : compared to my airfare and accommodation! Commuting down US-36 every day to go to the conference is no picknick either :) It is a good conference... Warner : 2009/4/10 Skip Withrow : : > : > Hello Time Nuts, : > : > I recently became aware of the NIST Time & Frequency Seminar coming up : > shortly and looked it up as it sounded interesting (to a time-nut) and is : > almost in my back yard (well, at least commuting distance). You can check : > out the web page at http://tf.nist.gov/timefreq/seminars/T&Foverview.html. : > : > It all sounds very cool, UNTIL YOU CHECK OUT THE PRICE! Sure, I could see : > $300-$400 (which would still be pretty rich for my budget), but $1900? : > Obviously our tax dollars are not subsidizing this function. : > : > If anyone knows how to procure a discounted registration I would be most : > interested in hearing from you. : > : > Regards, : > Skip Withrow : > : > ___ : > 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] Time offset
In message: <001c01c9a82e$4014b270$a101a...@officemail> "phil" 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] Loran-C & French Clocks
In message: <49c17d52.6050...@rubidium.dyndns.org> Magnus Danielson writes: : I am still wondering who would set up NTP servers that provides UT1 time : in order to realize GMT over NTP. It would not be all that difficult as : UTC-UT1R is published regularly with advance estimates which could be : smoothed out and interpolated properly. I've never heard of such a beast... At least there wouldn't be any leap seconds in that kind of setup :) 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: "Lux, James P" 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] French Time offset
In message: "Lux, James P" 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] Loran-C & French Clocks
In message: <000501c9a7b1$ef689bb0$a101a...@officemail> "phil" 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] Loran-C & French Clocks
In message: <49c033e3.2010...@rubidium.dyndns.org> Magnus Danielson 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
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: "Arnold Tibus" 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=temps&lang=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" : >To: "Discussion of precise time and frequency measurement" : > : >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] pi Day
In message: <49ae3360.4000...@tiscali.co.uk> Dave Ackrill writes: : Steve Rooke wrote: : > 2009/3/4 Dave Ackrill : : : >> 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 writes: : Steve Rooke skrev: : > 2009/3/2 Magnus Danielson : : >> 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" 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: <49825436.5090...@rubidium.dyndns.org> Magnus Danielson writes: : M. Warner Losh skrev: : > In message: <25630a120901291622l5cc165ecna06e01cc3de52...@mail.gmail.com> : > michael taylor 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] Canada's 5,000 year old calendar
In message: <25630a120901291622l5cc165ecna06e01cc3de52...@mail.gmail.com> michael taylor 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] GPS Time to Year?
In message: "Tom Van Baak" 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 date&time 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: <1232236533.26603.8.ca...@bg-desktop> Björn Gabrielsson writes: : Hi Warner, : : On Sat, 2009-01-17 at 16:30 -0700, M. Warner Losh wrote: : > In message: : > 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] Free programs to read NEMA data.
In message: 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] beryllium oxide
But what about the Beryllium Sphere? What happens when you activate that? Warner In message: Mark Sims writes: : Three other places one may encounter beryllium are: : : 1) Beryllium copper springs and contacts, usually around 2-3% beryllium. Not likely to cause a problem unless you get your jollies grinding up springy metal and snorting the powder. : : 2) Beryllium tools! Tools (particularly screwdrivers and pliers) can be made out of pure beryllium metal. They are not magnetic, very strong, very light. They were used a lot in aerospace and military applications. One thing that used to appear on the surplus market was an EOD toolkit used by bomb disposal techs. Even had a beryllium hammer. These were wonderful tools which you might just find when clearing out old uncle Bob's estate... : : 3) Nuclear reactors and weapons. Be careful when disassembling that surplus nuke you picked up on your last trip to eastern Europe... : : Beryllium was originally called glucinium becuase it and its salts tasted very sweet. In fact, tasting used to be a diagnostic test for the presence of beryllium. : _ : Windows Live�: Keep your life in sync. : http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 : ___ : 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] NTP API on Linux 2.6.26
In message: <4964340d.8030...@rubidium.dyndns.org> Magnus Danielson 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=165913&action=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 : //#include : #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 #include #include 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: James Cloos writes: : >>>>> "Warner" == M Warner Losh 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: <4960027e.1000...@erols.com> Chuck Harris 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 K&R 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 Quirks
In message: <495ff91c.60...@rubidium.dyndns.org> Magnus Danielson writes: : M. Warner Losh skrev: : > In message: : > James Cloos writes: : > : >>>>> "Warner" == M Warner Losh 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: <495fd637.5030...@erols.com> Chuck Harris 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: James Cloos writes: : >>>>> "Warner" == M Warner Losh 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: <26842.1231015...@critter.freebsd.dk> "Poul-Henning Kamp" 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
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: James Cloos writes: : >>>>> "Warner" == M Warner Losh 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: James Cloos writes: : >>>>> "Warner" == M Warner Losh 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
In message: James Cloos writes: : > "Chuck" == Chuck Harris 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: <495f7285.3040...@erols.com> Chuck Harris 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 seconds and POSIX
In message: <20090101.112803.179959520@bsdimp.com> "M. Warner Losh" 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.
Re: [time-nuts] Leap seconds and POSIX
In message: Joe Gwinn 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] FreeBSD 7 ntp server
In message: <1231b6a80812312047k5d2d702djcdd9610f47bc9...@mail.gmail.com> "Steve Rooke" writes: : 2009/1/1 M. Warner Losh : : > In message: : >Neon John writes: : > : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" : > : wrote: : > : : > : >In message: : > : >"Robert Darlington" 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] FreeBSD 7 ntp server
In message: Neon John writes: : On Wed, 31 Dec 2008 17:57:33 -0700 (MST), "M. Warner Losh" : wrote: : : >In message: : >"Robert Darlington" 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: "Robert Darlington" 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] Early leap second data
In message: <20090101000621.gd28...@mail.msys.ch> Marc Balmer 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.
[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] Leap-second happens when...??
In message: <4956d398.6060...@rubidium.dyndns.org> Magnus Danielson 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] Leap-second happens when...??
In message: <4955f456.8000...@rubidium.dyndns.org> Magnus Danielson 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] 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
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] 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] 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: : 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] 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] 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] 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] 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] 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
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] 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] Y2K again: Tuesday 03:14:07 GMT, January 19, 2038
In message: <[EMAIL PROTECTED]> Brooke Clarke <[EMAIL PROTECTED]> writes: : I should have mentioned the failures have just started. If you subtract 30 : years from the subject date you get: 03:14:07 GMT, January 19, 2008 : Financial institutions that do 30 year mortgage calculations are the ones who : were bitten. They are the ones that were bitten by y2k bug in 1970 and use sensible data types instead. 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: : It doesn't have full flow control. No DCD pin. I was thinking USB : serial dongle, but I don't think that would work. It doesn't : implement an a high priority interrupt like a traditional PC com : port. I think some of the antique versions of NTPD supported using : RD. The GPIO pin might be made to work, but you're off in to custom : refclock coding. Custom refclock coding isn't so bad... Usually it is just a second fd that you can get the pps info from... 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]> 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] 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]> "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]> "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] 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: "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.
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] 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: : 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.
[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] 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] Oncore VP problem
); SAEximRunCond expanded to false Errors-To: [EMAIL PROTECTED] In message: <[EMAIL PROTECTED]> "Tom Van Baak" <[EMAIL PROTECTED]> writes: : > How big would the sawtooth be for an m12+? : > : > Warner : : The M12+ has a 3x smaller sawtooth; about ア16 ns (9 ns rms) : vs. the VP sawtooth which is about ア 52 ns (31 ns rms). See: : : http://www.leapsecond.com/pages/m12/sawtooth.htm : http://www.leapsecond.com/pages/vp/sawtooth.htm Thanks Tom! 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] 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