Michael_J_Ward@cup.portal.com (12/22/88)
There was a feature on San Francisco channel 7 last night about PSTI, a compan which makes a WWV receiver for synchronizing traffic lights and also for computer systems. How many systems would need such precise time-stamping? Do they put one one of these on each server, or somewhere in the middle of a network? Is anyone using one of these?
johnl@n3dmc.UU.NET (John Limpert) (12/23/88)
In article <12812@cup.portal.com> Michael_J_Ward@cup.portal.com writes: >There was a feature on San Francisco channel 7 last night about PSTI, a >company which makes a WWV receiver for synchronizing traffic lights and >also for computer systems. How many systems would need such precise >time-stamping? Do they put one one of these on each server, or somewhere >in the middle of a network? Is anyone using one of these? Many data acquisition/recording systems need high precision timing systems. I work with spacecraft telemetry processing systems that typically tag received data with a millisecond precision time stamp. There are some applications that require microsecond precision (Synthetic Aperature Radar). Typically the timing data is read from a parallel interface that is connected to a timing distribution system. You can't put the timing data through a network without losing alot of precision. WWV is fine for many systems, but it is inadequate for a high precision timing system. We use atomic standards (Hewlett-Packard Cesium Beam) and a special LORAN receiver as our timing source. Accurate timing systems are important for situations where independently recorded data needs to be correlated with small allowances for error. Some examples are VLBI (very long baseline interferometry), orbit determination and seismic monitoring. Time codes are widely used in music recording studios, TV stations and motion picture production. -- John A. Limpert UUCP: johnl@n3dmc.UUCP, johnl@n3dmc.UU.NET, uunet!n3dmc!johnl
mo@prisma (12/26/88)
Dave Mills has done a lot of work developing network time synchronization protocols. It turns out the limiting factor is the variance of the transmission delays - the not the size of the delay itself. There are several RFC's and some code for 4.3BSD implementing the Network Time Protocol. The scheme is based on a heirarchy of clocks with the assumption that some hosts will have WWV time code receivers. The current system has both "professional" receivers and Heathkit "Most Accurate Clocks". They work well and on a local network you can keep the time between machines synced to microsecond timescales, while millisecond accuracy is possible across some Internet paths. Most interstingly, monitoring the time drifts are spectacular ways of doing remote measurement. For instance, if your local clock is crystal-based and not in an oven, Dave can, over a period of weeks, calibrate your machine room and tell you the temperature by watching the temp-induced time drift. He has also looked at the synchronization of the national power grid. Once it was all commonly synced, but not any more. There are regional grids which drift relative to one another. Further, he discovered that by watching line-time clocks that 10 minutes before the evening half hours, in Britian everyone goes and puts the electric kettle on for tea. THhe sudden surge dips the line frequency and the clocks drift faster. He finally asked someone about it and it turns out that is when the commercials come on... SO if you are interested in distributed timing, become a clock ticker yourself and read Dave's stuff before setting out on your own... Yours for reinventing flat tires, -Mike O'Dell
david@daisy.UUCP (David Schachter) (12/28/88)
In article <12812@cup.portal.com> Michael_J_Ward@cup.portal.com writes: >[...] PSTI, a company >which makes a WWV receiver for synchronizing traffic lights and also for >computer systems. > >How many systems would need such precise time-stamping? Do they put one one >of these on each server, or somewhere in the middle of a network? Is anyone >using one of these? I wrote the software and helped design the hardware for the PSTI clock, so I'm qualified to answer Mr. Ward's questions, I hope! 1. How many systems need precise time-stamping? The PSTI clock provides a specified accuracy of 10 milliseconds and a typical accuracy of 3 milliseconds. This means the time you get is within 3 milliseconds of the WWV/WWVH time. WWV/WWVH are within a few nanoseconds of official world-wide time, as determined by the BIH (International Time Bureau) in France. Accuracy to the tens of milliseconds level is overkill for traffic light control. For synchronizing computer networks, it is just right: it is accurate enough to be used for synchronization of distributed databases and filesystems. A radio-controlled clock has advantages besides accuracy. It is reliable: there are no batteries to change, no problems with daylight savings time, no change of being set incorrectly. If the power fails, the clock resets itself when power returns, by receiving the radio broadcasts. Radio-controlled clocks are traceable: you can trace the timing in your system back to the BIH, and have a good level of confidence that your timestamps are accurate. This can be important in legal affairs, e.g. lawsuits over police response speed. If you must prove in court that an event occurred at a partic- ular time, or that two events were separated by a particular interval, a radio- controlled clock can be useful. Radio-controlled clocks are more secure: the signal is not easy to forge and PSTI clocks have further security features I won't discuss here. Such clocks can impede computer crime, and this is a Good Thing. 2. Where do radio-controlled clocks go? For traffic-light control, the alternative to radio-controlled clocks is to trench the streets, connecting all the intersection controllers to some central location. This is not cheap, nor is it reliable. Cables break, get waterlogged, or accidentally dug up and ripped. Central sites go down. WWV and WWVH never go down. Each transmitter site is triply redundant. Moreover, the PSTI clocks maintain accurate time in the absence of radio signals by digitally trimming the local crystal timebase. Several transportation districts now use a PSTI clock at each intersection, installed in the traffic light controller box. For computer applications, PSTI clocks can be installed in the computer. They are tolerant of high levels of RFI and EMI. PSTI clocks maintain higher accuracy if they are operated at a stable temperature. The clocks need a 15 volt DC power supply and they consume only a few watts. One application I'm proud of is to use PSTI clocks for earthquake measurement. This application requires low power, high reliability, and high accuracy. The PSTI clock was the only device which met the requirements. PSTI has software to connect PSTI clocks into VAXen and some other computers. On the VAX, the software permits one VAX to serve as a time master for other VAXen on a network or in a cluster. I didn't do the software so I don't know what levels of time-transfer accuracy is achieved. For higher accuracy, one could put a clock on each node. An RS-232 port is required, and money. 3. Who uses them? Digital Equipment Corporation, Los Angeles County, and The White House are three PSTI customers. Contact PSTI for a more complete list. Precision Standard Time, Inc. is at 105 Fourier Avenue, Fremont, CA 94539. Their phone number is (415) 656-4447. There is a nationwide 800 number, but I don't know what it is. Disclaimers: I used to work for them. I have stock in the company. I like the product a lot. (It fulfills a childhood dream of always having the correct time.) -- David Schachter ...!ucbvax!imagen!atari--\ ...!uunet-----------------!daisy!david ...!pyramid--------------/
mac3n@babbage.acc.virginia.edu (Alex Colvin) (01/03/89)
I'm looking for a real-time (sub-millisecond) clock that can be shared by several machines (mostly pc's) for network measurements. It has to have lower latency and variance than the network. Also looking for the same for Multibus I. Something that can be read off a serial port could do both jobs.