Re: [time-nuts] Leap second glitches on NTP using Z3801A
If you didn't submit it, I invite you to do so. I'll have one ready soon. It's http://bugs.ntp.org/1090 -- 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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
Thanks for the explanation everyone. Hopefully one of these days I'll have all my pennies saved at the same time that TAPR does another thunderbolt buy, and I can start playing around with this stuff. -Eric On Mon, Nov 17, 2008 at 12:02 AM, Hal Murray [EMAIL PROTECTED] wrote: If you didn't submit it, I invite you to do so. I'll have one ready soon. It's http://bugs.ntp.org/1090 -- 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] Leap second glitches on NTP using Z3801A
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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
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. -- --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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
Yes, I noticed this as well and modified the refclock driver to filter it as it does in the oncore refclock. Scott Hal Murray 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. ___ 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
Here's the diff based on 4.2.4p4
--- ntp-4.2.4p4.orig/ntpd/refclock_hpgps.c 2006-06-06 15:16:51.0
-0500
+++ ntp-4.2.4p4/ntpd/refclock_hpgps.c 2008-08-25 09:56:29.0 -0500
@@ -535,7 +535,8 @@
switch (leapchar) {
case '+':
- pp-leap = LEAP_ADDSECOND;
+ if ((month == 6) || (month == 12))
+ pp-leap = LEAP_ADDSECOND;
break;
case '0':
@@ -543,7 +544,8 @@
break;
case '-':
- pp-leap = LEAP_DELSECOND;
+ if ((month == 6) || (month == 12))
+ pp-leap = LEAP_DELSECOND;
break;
default:
Scott Mace wrote:
Yes, I noticed this as well and modified the refclock driver to filter
it as it does in the oncore refclock.
Scott
Hal Murray 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.
___
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
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? -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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
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, Does not account for maybe isn't quite what happens, but right, GPS time rolls along continuously without regard to variations in astronomical time. A leap second adjustment count is included in the GPS data stream so that receivers can output true UTC time stamps, if that conversion is required. Some level of advanced warning of a leap second is necessary so that when the moment arrives the receiver can either delete the UTC second called 23:59:59 (negative leap second) or insert an extra UTC second called 23:59:60 (positive leap second). Theoretically, a GPS receiver might only need one second of advanced warning to do the right thing in the last UTC second of the last day of the month, but for a variety of good reasons, a couple of days or even a couple of months of advanced notice is better for everyone involved. /tvb ___ 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
Hi Eric: The GPS time scale can not have any jumps or there would be corresponding position jumps. Have Fun, Brooke Clarke http://www.prc68.com Eric Garner wrote: 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? -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. ___ 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
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? You end up needing both with and without leap seconds. GPS time is without leap seconds. It also distributes the number of leap seconds that have been inserted since GPS started so you can translate GPS time into UTC. So then you need a warning if one is coming up soon. -- 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.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
In message: [EMAIL PROTECTED] Eric Garner [EMAIL PROTECTED] writes: : Ascending from Lurk Mode, I have a (possibly stupid) question: according to : : http://tycho.usno.navy.mil/leapsec.html : : and Tony Jones's book The Story of Atomic Time GPS time does not : account for leap seconds, So why does it alert you to them? GPS's almanac contains the GPS to UTC offset (current, and future). It is repeated every 20 minutes, which means it can take 20 minutes for a cold startup to learn the current number of leapseconds... Warner : -eric : : On Sun, Nov 16, 2008 at 7:21 PM, Hal Murray [EMAIL PROTECTED] wrote: : Is anybody running ntpd with their Z3801A? : : If so, please check your log files and tell me if you see a bogus leap second : at the end of the past several months. I've seen them for Aug, Sep, and Oct. : I think they are coming from my Z3801A, but it might be something else. : : The GPS satellites are now announcing a leap second that will happen at the : end of the year. The refclock driver passes that to ntpd and ntpd passes it : to the kernel and magic happens. : : I think the refclock-ntpd interface assumes the leap second will happen at : the end of the current month. NIST only announces leap seconds a month ahead : on WWVB and ACTS. : : The Oncore refclock driver has a filter to wait until the current month to : pass the info to ntpd. I'm working on something similar for the HP driver. : : -- : These are my opinions, not necessarily my employer's. I hate spam. : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : -- : --Eric : _ : Eric Garner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
In message: [EMAIL PROTECTED] Eric Garner [EMAIL PROTECTED] writes: : Sorry for not forming my question better. I guess what I wanted to : know is that given that the first leap second was in 1972 and that the : first GPS satellite was launched in 1993. why was it decided to not : incorporate leap seconds into how GPS tells time, but still alerts : you to the fact that they are coming up? Or why was the decision made : to have UTC-GPS different than UTC. My understanding is that they : tick simultaneously but tell different times.(sorry for the : overuse of quotes) Is there some navigational reason? Is it actually : intentional? Leap seconds suck. There's no reason to have them unless you need time to sync up with the way that the earth is pointing. GPS doesn't need to synchronize to the earth's directions to solve for location, so it saves a ton of hassles by just counting seconds since an arbitrary epoch. Since UTC is important, GPS's almanac gives the conversion from GPS to UTC. Warner : -eric : : On Sun, Nov 16, 2008 at 8:08 PM, Brooke Clarke [EMAIL PROTECTED] wrote: : Hi Eric: : : So that you can figure out UTC. But there's no DST bit on any of the : satellites so for that you need a local time broadcast. : : : Have Fun, : : Brooke Clarke : http://www.prc68.com : : Eric Garner wrote: : Ascending from Lurk Mode, I have a (possibly stupid) question: according to : : http://tycho.usno.navy.mil/leapsec.html : : and Tony Jones's book The Story of Atomic Time GPS time does not : account for leap seconds, So why does it alert you to them? : : -eric : : On Sun, Nov 16, 2008 at 7:21 PM, Hal Murray [EMAIL PROTECTED] wrote: : Is anybody running ntpd with their Z3801A? : : If so, please check your log files and tell me if you see a bogus leap second : at the end of the past several months. I've seen them for Aug, Sep, and Oct. : I think they are coming from my Z3801A, but it might be something else. : : The GPS satellites are now announcing a leap second that will happen at the : end of the year. The refclock driver passes that to ntpd and ntpd passes it : to the kernel and magic happens. : : I think the refclock-ntpd interface assumes the leap second will happen at : the end of the current month. NIST only announces leap seconds a month ahead : on WWVB and ACTS. : : The Oncore refclock driver has a filter to wait until the current month to : pass the info to ntpd. I'm working on something similar for the HP driver. : : -- : These are my opinions, not necessarily my employer's. I hate spam. : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : : : : -- : --Eric : _ : Eric Garner : : ___ : time-nuts mailing list -- time-nuts@febo.com : To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts : and follow the instructions there. : : ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Leap second glitches on NTP using Z3801A
Scott wrote: Yes, I noticed this as well and modified the refclock driver to filter it as it does in the oncore refclock. Scott If you submitted this patch to the NTP Project I didn't see it. If you didn't submit it, I invite you to do so. H ___ 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
OK, so thanks for posting this, and I sitll invite you to submit a patch via http://bug.ntp.org . H ___ 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.
