Hal, Many thanks for taking the time for that excellent reply.
A true data diode has no leakage. You can make one by clipping the receive wires in a switch. The control network sends predictable UDP messages with its data. No concern is taken for harm from the Internet, and it is not possible to do MS updates to the Windows operator consoles. If it worked during process startup, then no improvement is required. This is not a challenging application for time accuracy, unless a human (like the CIO) wants to have better accuracy than his (it's a testosterone thing) competition. Process valves have a 1 second time constant, for the most part. Programmable logic controllers and their actuators can't react faster than 1/2 of a power line cycle. Millisecond precision is adequate. Flakey? MS Windows may be used for human interfaces, where redundancy is economically possible as 1 for N rather than 1 for 1. Nobody uses Windows for the deterministic control calculations, which repeat at fixed intervals. The software genius who built the network software for the control system that I designed came up with a simple 256 step adjustment for the crystal clock that acted like the fast/slow adjustment on a watch. Double precision was not required. You simply added or subtracted a clock interrupt every n/256 interrupts. That didn't make him a genius, it was the tiny floating point package that beat anything else on the market. I had hoped for a line frequency clock like the PDP-11, but hardware gave me a crystal. Yes, the line frequency is within +/- 0.1% of true time, but that was enough in 1985. And it was always back in sync with WWV at 7 AM. My concern is with the facilities that don't have Internet connections and have to use satellite links. Do facilities that are far apart need to have one millisecond resolution? That's a testosterone question. How much am I willing to pay? I dunno, how much are you willing to offer? Bill Hawkins -----Original Message----- From: Hal Murray Sent: Monday, August 30, 2010 5:39 AM [email protected] said: > I'm involved with time synchronization of control system computers for > multi-national businesses. GPS springs to mind as a way to synchronize time > anywhere. Or is it? What about monsoon rains? > The Internet is available almost everywhere that control computers are used, > but many users prefer to use a data diode between them and the Internet. > Control computers are now essential for manufacturing processes. Some of the > processes run constantly for years without stopping for any kind of security > update. Some of the downtimes cost millions of dollars per day. How much does your "diode" leak? Can you get command packets (or acks) back to your control systems, or are they flying deaf? > A GPS time system allows the control systems to be synchronized in time, so > that messages sent periodically through the data diodes will have the > correct time stamp on various events that occur in the process. > But does that work everywhere all of the time? Where can I find answers? How accurate do you need your clocks to be? How reliable do you need/want them to be? How much are you willing to pay? How vulnerable/flaky is the OS on your control systems? (Are they running Windows?) Note that there are 2 dimensions to accuracy. One is RMS error, or something like that. The other is how often do you go outside some error bars, how long is the tail? ---------- The geeks I hang out with would put a firewall between the big bad internet and the system to be protected. If you are sufficiently paranoid (which doesn't take much) you don't allow marketing people or visitors to connect their likely-to-be-infected laptop to the subnet with the protected systems. (You can setup another subnet for them.) If you need sub-ms accuracy, you probably need a local GPS receiver/system. For 10s of ms accuracy, you can run ntp on the firewall, or on a separate system right behind the firewall. The accuracy depends on the network load. There isn't a simple answer. If all you need is to be within a second or three, you can probably get that by tweaking the timekeeping fudge factor, possibly by hand. This would take occasional monitoring and tuning. ----------- Consider timekeeping on a computer. They are all based on a crystal. It's either something like "every interrupt, bump the clock by 1 ms" or it's "that register ticks at 1 MHz". The problem is that the crystal usually doesn't tick at exactly the specified frequency. It's off by a few to hundreds of PPM. Low cost crystals are generally accurate to within 100 or 50 PPM. The watch crystal behind the CMOS/TOY clock is probably much better but it's hard to use for fine grained timing. There are 86400 seconds per day so 1 PPM is 1 second in 11.5 days, 10 PPM is (roughly) 1 second per day... If you monitor a system for a week or two, you can calculate how far off the crystal is. That's by hand, just looking at the printout from something like the date command, waiting a week and doing it again. If your OS cooperates, you can tell it the fudge factor so that it will keep (much) better time. (You probably need double-precision arithmetic deep inside the timekeeping routines.) That will get rid of most of the systematic error. You can tune things by watching it drift over following weeks/months. One complication is that the crystal frequency is slightly temperature dependent. Ballpark numbers are 1 PPM per 10 F. (or maybe 10C?) A system will keep better time if there is good air-conditioning and/or you don't prop open the door very often. Another possible complication is software bugs/quirks. Current Linux kernels get different answers each time they reboot and calibrate the TSC clock. The differences can be 200 PPM. A kernel patch would fix that, but that's a pain if you don't otherwise need to maintain your own kernel. I've been told it's been fixed. I haven't tested it yet. ------------ Story mode: Shortly after I got to Xerox in 1976, Ed Taft fixed a bug in the Alto timekeeping routines. http://en.wikipedia.org/wiki/Alto_%28computer%29 The Alto was designed to run at 170 ns. You buy crystals in MHz rather than ns. They got 5.88 MHz crystals. When the software guys wrote the timekeeping code, they used 170 ns rather than 170.068. That's off by about 400 PPM, enough to be annoying. Tweaking one constant was enough to fix that. (I forget if he had to rewrite that code to use double precision.) -- These are my opinions, not necessarily my employer's. I hate spam. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
