Re: [time-nuts] Leap Quirks
[Linux systems hanging] >> None of mine (many dozens) hung.This is typical: >> [844362.415072] Clock: inserting leap second 23:59:60 UTC > Jan 1 12:59:59 willow kernel: Clock: inserting leap second 23:59:60 UTC It got slashdotted: http://ask.slashdot.org/article.pl?sid=09/01/01/1930202 I got bored before I found anything interesting. It's a locking bug in the kernel. That message gets printed with a lock held and sometimes that calls a routine that needs the lock... If you feed >linux hang ntp leap-second< to google-groups, the top hit is a thread in fa.linux.kernel with all the details. http://tinyurl.com/8juphd http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/474eef5d80898411?q=linux+hang+ntp+leap-second#f3fc957cad4d3001 -- 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 Quirks
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. -Chuck Harris ___ 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
Chuck Harris skrev:
> 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.
I just checked. Two of my linux machines happilly chewed on and they
both display the same thing
magda-gw:/etc# dmesg | grep leap
[3672744.988878] Clock: inserting leap second 23:59:60 UTC
mag...@heaven:~$ dmesg | grep leap
[2382608.682165] Clock: inserting leap second 23:59:60 UTC
I have not heard any screems of terror from my neck of the woods either.
So what ever it is, few was actually affected.
I am actually curious about where this happens and the answer is found
in /usr/src/linux-source-2.6.26/kernel/time/ntp.c:
/*
* Leap second processing. If in leap-insert state at the end of the
* day, the system clock is set back one second; if in leap-delete
* state, the system clock is set ahead one second.
*/
static enum hrtimer_restart ntp_leap_second(struct hrtimer *timer)
{
enum hrtimer_restart res = HRTIMER_NORESTART;
write_seqlock_irq(&xtime_lock);
switch (time_state) {
case TIME_OK:
break;
case TIME_INS:
xtime.tv_sec--;
wall_to_monotonic.tv_sec++;
time_state = TIME_OOP;
printk(KERN_NOTICE "Clock: "
"inserting leap second 23:59:60 UTC\n");
leap_timer.expires = ktime_add_ns(leap_timer.expires,
NSEC_PER_SEC);
res = HRTIMER_RESTART;
break;
case TIME_DEL:
xtime.tv_sec++;
time_tai--;
wall_to_monotonic.tv_sec--;
time_state = TIME_WAIT;
printk(KERN_NOTICE "Clock: "
"deleting leap second 23:59:59 UTC\n");
break;
case TIME_OOP:
time_tai++;
time_state = TIME_WAIT;
/* fall through */
case TIME_WAIT:
if (!(time_status & (STA_INS | STA_DEL)))
time_state = TIME_OK;
break;
}
update_vsyscall(&xtime, clock);
write_sequnlock_irq(&xtime_lock);
return res;
}
So the log message 23:59:60 is actually static value. This mechanism is
what Dave Mills describes on his NTP page. The time calculations
otherwise follow POSIX.
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.
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 Quirks
> "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.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ 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
> "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. 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. 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. 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. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ 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
M. Warner Losh wrote: > 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 Which is what my message was saying. If linux does count 58..59..60..0 instead of 58..59..59..0, then it isn't following POSIX. [I have no interest in getting into an argument over whether linux, or POSIX should count that way.] 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. 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. -Chuck Harris ___ 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
Chuck Harris skrev: > M. Warner Losh wrote: >> 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 > > Which is what my message was saying. If linux does count 58..59..60..0 > instead of 58..59..59..0, then it isn't following POSIX. [I have no > interest in getting into an argument over whether linux, or POSIX > should count that way.] > > 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. > 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, since that is what POSIX says and Linux honours unless running NTP. 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.
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.
[time-nuts] QUALCOMM Q3036I-16N Info Needed
Does anyone have or know a source for a datasheet on a Qualcomm Q3036I-16N Synthesizer chip ? I picked up two "things" from "over there". They looked interesting and were rather cheap. These "things" had 4 SMA connectors, marked: 10 MHz 72.5 MHz 725 MHz 7.975 GHz and had three wires going to a power connector. I applied +15vdc to 2 of the three wires and got an output on one connector (72.5 MHz) around 71 MHz. When I applied a 10 MHz reference from one of my GPSDO's, the frequency shifted to 72.5 MHz and was quite stable. Similarly the outputs at 725 MHz and 7.975 GHz were also quite stable. More precise measurements to come. Now, if I can get the pinout of the Qualcomm chip, perhaps I can figure out how to move the output freq's. Who says there are no bargains "over there". 73, Dick, W1KSZ ___ 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 <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... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
> "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. 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. ;^) 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.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ 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
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? 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. I was of the understanding that the problem was in how the UTC time was calculated from time_t, and the converse. Do tell! -Chuck Harris ___ 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: >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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: <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.
[time-nuts] opto coupler isolation?
Hi, An opto coupler seems good idea for an isolation amplifier but maybe not for the phase noise. Any experience? regards, henk ___ 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] opto coupler isolation?
Henk ten Pierick wrote: > Hi, > > An opto coupler seems good idea for an isolation amplifier but maybe > not for the phase noise. > Any experience? > > regards, > > henk > > ___ > 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. > > Henk The better optoisolators typically have a random jitter on the order of 50-100ps rms. This is considerably more than that for ACMOS logic (~1ps rms). Consequently the phase noise floor will be about 34 to 40dB higher than that when using ACMOS logic. Thus for low phase noise OCXOs using an optical isolator will significantly degrade the phase noise. An RF transformer is a lower phase noise solution to providing low frequency ground isolation. Achieving a reverse isolation of more than 140dB isnt too difficult with a few cascaded CB stages and a good layout combined with apprpriate shielding. Bruce ___ 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] opto coupler isolation?
In message <494882eb-d714-49b4-a7e2-bef04509d...@deriesp.demon.nl>, Henk ten Pi erick writes: >Hi, > >An opto coupler seems good idea for an isolation amplifier but maybe >not for the phase noise. Optocouplers have lousy dV/dt performance, so the jitter is horrible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] opto coupler isolation?
Poul-Henning Kamp wrote: > In message <494882eb-d714-49b4-a7e2-bef04509d...@deriesp.demon.nl>, Henk ten > Pi > erick writes: > >> Hi, >> >> An opto coupler seems good idea for an isolation amplifier but maybe >> not for the phase noise. >> > > Optocouplers have lousy dV/dt performance, so the jitter is > horrible. > > Not true for the higher speed optoisolators (eg Avago's HCPL9000 series) In any case its more a matter of noise to slew rate ratio. The issue is really that the signal to noise ratio of the internal optical signal is relatively low. For better performance you need to use a higher power optical signal such as that from a single mode laser. However by the time you factor in the cost of the modulator etc its usually better to revert to a conventional design. Bruce ___ 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] opto coupler isolation?
Poul-Henning Kamp skrev: > In message <494882eb-d714-49b4-a7e2-bef04509d...@deriesp.demon.nl>, Henk ten > Pi > erick writes: >> Hi, >> >> An opto coupler seems good idea for an isolation amplifier but maybe >> not for the phase noise. > > Optocouplers have lousy dV/dt performance, so the jitter is > horrible. > Some optocouplers can be pretty good. Some even have 10s of km of pulled silica glas between the two sides. Some even have 1000s of km of pulled silica glas between them, and still have pretty OK dV/dt and noise. The cheap onces are really lousy thought. Cheers, Magnus - using several opto-couplers to get the message through ___ 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] opto coupler isolation?
Hi, Thanks for the response, I did expect this. It saves me the experiment. henk On Jan 3, 2009, at 23:33, Bruce Griffiths wrote: > Poul-Henning Kamp wrote: >> In message <494882EB-D714-49B4-A7E2- >> bef04509d...@deriesp.demon.nl>, Henk ten Pi >> erick writes: >> >>> Hi, >>> >>> An opto coupler seems good idea for an isolation amplifier but >>> maybe >>> not for the phase noise. >>> >> >> Optocouplers have lousy dV/dt performance, so the jitter is >> horrible. >> >> > Not true for the higher speed optoisolators (eg Avago's HCPL9000 > series) > In any case its more a matter of noise to slew rate ratio. > > The issue is really that the signal to noise ratio of the internal > optical signal is relatively low. > For better performance you need to use a higher power optical signal > such as that from a single mode laser. > However by the time you factor in the cost of the modulator etc its > usually better to revert to a conventional design. > > Bruce > > ___ > 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 Quirks
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"? 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.
Re: [time-nuts] Leap Quirks
In message <495ff91c.60...@rubidium.dyndns.org>, Magnus Danielson writes: >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"? Strictly speaking none of them. Instead of thinking of POSIX "wall-clock" facilities as a timekeeping mechanism, think of them as asking the next stranger you meet what time it is. POSIX only offers you the ability to get an estimate of "wall-clock" time, it does not guarantee that the such estimates will not represent time going backwards, or that the amount of time between the two requests will correspond to the difference between them. The trouble is, obviously, that people pressume these properties. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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
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. When did this change? -Chuck Harris ___ 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
Poul-Henning Kamp skrev: > In message <495ff91c.60...@rubidium.dyndns.org>, Magnus Danielson writes: > >> 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"? > > Strictly speaking none of them. > > Instead of thinking of POSIX "wall-clock" facilities as a timekeeping > mechanism, think of them as asking the next stranger you meet what > time it is. > > POSIX only offers you the ability to get an estimate of "wall-clock" > time, it does not guarantee that the such estimates will not represent > time going backwards, or that the amount of time between the two > requests will correspond to the difference between them. > > The trouble is, obviously, that people pressume these properties. > Which is more or less what I also think nowdays. The trouble is that it looks like time, feels like time and people try to make it behave like time, but isn't that. The monotonicity increasing aspect comes to mind as well, as you indicated. Do you agree with my possible interpretations by the way? 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.
Re: [time-nuts] Leap Quirks
Chuck Harris skrev: > 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. > > When did this change? Depends on which interpretation of POSIX you are making... how you "fit" your UTC time onto the POSIX scale. This page can serve as some aid in that puzzle: http://www.cis.udel.edu/~mills/leap.html If you want POSIX midnight to fit UTC midnight, then a piece-wise mapping must be maintained. Another way would be to just keep POSIX time as SI seconds (or UTC rubber until 1972 and SI from there on, which is more practical if you care about details) and solve the UTC issue "outside" the core. Which is fine too. 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.
Re: [time-nuts] Leap Quirks
> "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. 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. Thanks for the reminder. I had forgotten that entirely. (And am only just vaguely remembering that I used to know that fact. [SIGH]) 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. 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. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ 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
On 1/3/09 1:34 PM, "James Cloos" wrote: > 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. > And, now, add in trying to synchronize clocks on moving platforms where the platforms move fast enough (or the relative timing requirements) are such that relativistic effects are important. I'm working with developing a "standard" for timekeeping for spacecraft radios (since the radio receives the sync signal (e.g. GPS, TDRSS, or DSN), and often has a very good oscillator (e.g. A USO) connected to it, it makes sense to do time keeping there..) You'd think that you could just do something like TAI, but there's a long, long heritage of using other time scales of one sort or another, referenced to various things. All well and good for situations where you can dereference the difference between spacecraft time and "whatever" time after the fact (e.g. When you're looking at radar returns, or radio science data), but kind of a pain when you're looking to do things in real time. Jim ___ 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: <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.
