[LEAPSECS] Embedded software
The olson database updates will take care of that. One of the problems with leap-seconds is that they aren't predictable and the software in embedded gear doesn't get updated. That also means the time zone data doesn't get updated. What sort of embedded gear uses time but not time zones? Or are people willing to gamble that Congress won't mess with DST anytime soon? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
On Jan 19, 2014, at 2:12 PM, Hal Murray wrote: The olson database updates will take care of that. One of the problems with leap-seconds is that they aren't predictable and the software in embedded gear doesn't get updated. That also means the time zone data doesn't get updated. What sort of embedded gear uses time but not time zones? Or are people willing to gamble that Congress won't mess with DST anytime soon? All the embedded gear I've done runs on UTC. But it also has requirements for 'cold start' that are incompatible with GPS and couldn't be met if the system had been off across a leap second. It didn't deal with localtime, so DST insanity didn't matter so much... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
On Sun, 19 Jan 2014 16:02:54 -0700, Warner Losh wrote: On Jan 19, 2014, at 2:12 PM, Hal Murray wrote: The olson database updates will take care of that. One of the problems with leap-seconds is that they aren't predictable and the software in embedded gear doesn't get updated. That also means the time zone data doesn't get updated. What sort of embedded gear uses time but not time zones? Or are people willing to gamble that Congress won't mess with DST anytime soon? All the embedded gear I've done runs on UTC. But it also has requirements for 'cold start' that are incompatible with GPS and couldn't be met if the system had been off across a leap second. It didn't deal with localtime, so DST insanity didn't matter so much... Many Air Traffic Control (ATC) radars run on UTC (not local time) in a loose sort of way. What saves them is that most ATC radars are mechanically rotated, with a typical rotation period of 12 to 15 seconds (precision approach radars can be 2 seconds, but that's a different discussion). The effect is one full circle of detections that appear to be out of position by one second's travel time, which causes a disturbance in the tracks, which disturbance soon dies out. Full-scale tests have been done on operational hardware and software in simulation, where a leap second was emulated by manually stepping the clock. For positive leaps (insert a second), there was no visible disturbance to the crawling-worm displays. For negative leaps (omit a second), there were quite visible disturbances, but these also settled out. The percentage error for omission of a second is larger than that for adding a second, and the difference in visible effect may be partly due to detections missing the coarse gate and being dropped in the rotation following the jump. In later rotations, the fractional error is smaller, and the tracker picks up where it left of. This is the bounding case. ATC systems typically do not jump at the leap, they slide over 10 seconds or so. Joe Gwinn ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
In message 20140119182454462945.77293...@comcast.net, Joseph Gwinn writes: This is the bounding case. ATC systems typically do not jump at the leap, they slide over 10 seconds or so. In Denmark they go hands off until stuff look normal again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
On Sun, 19 Jan 2014 23:31:00 +, Poul-Henning Kamp wrote: In message 20140119182454462945.77293...@comcast.net, Joseph Gwinn writes: This is the bounding case. ATC systems typically do not jump at the leap, they slide over 10 seconds or so. In Denmark they go hands off until stuff look normal again. So, they step the clock (versus sliding smoothly), and just wait for the gyrations to subside? Joe Gwinn ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
All the embedded gear I've done runs on UTC. But it also has requirements for 'cold start' that are incompatible with GPS and couldn't be met if the system had been off across a leap second. It didn't deal with localtime, so DST insanity didn't matter so much... I can't quite figure out what that means. Where did it get leap-seconds info in the normal case? Was there a battery backed TOY/RTC? They typically have some (battery backed) RAM on the same chip. Could you have stored the leap info there? -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
On Jan 19, 2014, at 9:00 PM, Hal Murray wrote: All the embedded gear I've done runs on UTC. But it also has requirements for 'cold start' that are incompatible with GPS and couldn't be met if the system had been off across a leap second. It didn't deal with localtime, so DST insanity didn't matter so much... I can't quite figure out what that means. Where did it get leap-seconds info in the normal case? In the normal case, we stored leap seconds in a file on the filesystem. This allowed us to program the value into the GPS so it didn't have to wait for the entire almanac to download before it could produce UTC time (old firmware). Newer firmware came out that stored this value such that we didn't have to download it to the GPS. But it was valid only as long as leap seconds are known, so if they were off for more than 6 months, we'd have no way of knowing the now-current value. Also, these systems were not on the internet, so downloading one of the many sources of TAI-UTC differences wasn't an option. Was there a battery backed TOY/RTC? They typically have some (battery backed) RAM on the same chip. Could you have stored the leap info there? It wasn't so much the inability to store the leap info that's current. We had a requirement that cold spares had to sit on the shelf for up to 5 years, and come up in a new system with the correct UTC time within 3 minutes of power being applied. If we'd been off 6 months (not across a leap second opportunity we didn't have leap data for), we could be sure we knew the leap offset was. Otherwise, we had to wait for 25 minutes (old firmware) or 12.5 minutes (new firmware) for the almanac to be downloaded. Both of these figures was significantly longer than the 3 minutes we had to get up and running with the correct UTC time. The CPU and GPS were co-located in one module. Since we had a redundant system, we could meet this requirement if only one of the two systems was replaced, which helped make the customer much happier. But if we had a failure of both CPUs at the same time, we couldn't meet the requirement. This was eventually deemed acceptable to the customer given other issues that would be required to happen before a double failure like this was likely, and the time it would take to replace both CPUs, etc. Sorry if I was less than clear about these things. Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
Warner Losh i...@bsdimp.com wrote: Also, these systems were not on the internet, so downloading one of the many sources of TAI-UTC differences wasn't an option. OK, obviously asking every system to be connected to the Internet would be a non-starter, for security etc reasons, but what's wrong with dedicated, special-purpose narrowband non-Internet channels? Why not have an old-fashioned modem (as in 9600 baud or slower) dial a service such as ACTS that would provide the necessary Earth Correction information? (I realize that ACTS in its present form does not provide this information - I'm referring to a hypothetical ACTS-like service here.) There is a huge difference in terms of security etc exposure between a full-blown general purpose TCP/IP stack connected to the public Internet and a special-purpose low baud rate serial line. If you have a serial port in your system, and the only piece of code that touches this serial port (and even knows about its existence) is the single- purpose code that retrieves Earth Correction information, expecting just one specific (hard-coded) data format and accepting nothing else, where is the risk? We had a requirement that cold spares had to sit on the shelf for up to 5 years, and come up in a new system with the correct UTC time within 3 minutes of power being applied. It seems to me that the correct solution to a problem like this one is that whoever came up with such an unreasonable requirement should be removed from office, and replaced with someone who would be more reasonable. Why was this solution not considered? In other words, was there any true, genuine justification for the requirement you have stated, other than someone's whimsical say-so? Why did it have to produce UTC time, and not something like TAI or GPS? UTC should be for displaying *civil* times only, i.e., a user interface or presentation issue, with all internal things done on a timescale like TAI instead. And if the correct *civil* time is only for the convenience of human operators, why is it so critical to get it right within 3 minutes of powering up a cold spare? Surely the world won't come to an end because of some LCD on some control panel showing the wrong time for 25 min instead of 3 min after a technician swapped out a module. VLR, SF ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Embedded software
On Jan 19, 2014, at 10:15 PM, Michael Spacefalcon wrote: Warner Losh i...@bsdimp.com wrote: Also, these systems were not on the internet, so downloading one of the many sources of TAI-UTC differences wasn't an option. OK, obviously asking every system to be connected to the Internet would be a non-starter, for security etc reasons, but what's wrong with dedicated, special-purpose narrowband non-Internet channels? Why not have an old-fashioned modem (as in 9600 baud or slower) dial a service such as ACTS that would provide the necessary Earth Correction information? (I realize that ACTS in its present form does not provide this information - I'm referring to a hypothetical ACTS-like service here.) There is a huge difference in terms of security etc exposure between a full-blown general purpose TCP/IP stack connected to the public Internet and a special-purpose low baud rate serial line. If you have a serial port in your system, and the only piece of code that touches this serial port (and even knows about its existence) is the single- purpose code that retrieves Earth Correction information, expecting just one specific (hard-coded) data format and accepting nothing else, where is the risk? That's why we had redundant CPUs that could cache this data, as well as some other tricks that would sometimes allow us to recover the current TAI-UTC offset. Some, but not all, failure modes were covered this way. We did failure analysis for the customer to show the frequency of the non-compliance to show that it wouldn't interfere with their '9's uptime requirement for the entire system. These systems weren't really located where reliable phone lines would be free enough of noise to get a good modem connection. We had a requirement that cold spares had to sit on the shelf for up to 5 years, and come up in a new system with the correct UTC time within 3 minutes of power being applied. It seems to me that the correct solution to a problem like this one is that whoever came up with such an unreasonable requirement should be removed from office, and replaced with someone who would be more reasonable. Why was this solution not considered? It was dictated by the up times of the system that this was a component of. That solution was considered, but regulations prevented it. In other words, was there any true, genuine justification for the requirement you have stated, other than someone's whimsical say-so? Why did it have to produce UTC time, and not something like TAI or GPS? UTC should be for displaying *civil* times only, i.e., a user interface or presentation issue, with all internal things done on a timescale like TAI instead. And if the correct *civil* time is only for the convenience of human operators, why is it so critical to get it right within 3 minutes of powering up a cold spare? Surely the world won't come to an end because of some LCD on some control panel showing the wrong time for 25 min instead of 3 min after a technician swapped out a module. All internal timing was done in a TAI-like time scale. This is how we could get the timing system tuned within a few minutes, even when we've had a number of different failures. However, it was more complicated than LCD displays. There were regulatory requirements to produce logs in UTC time for other timing elements in the system, and to ensure compliance errors in the system. Those had to be produced in real-time and couldn't be wrong, even for 10-20 minutes at startup. Believe me, we spent a great deal of time going over the requirements, the dependencies, the reasons for them, etc. And little could be done about it, since regulations that governed this system weren't able to be changed easily, quickly or consistently... Warner ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
