There are sometimes delays up to 30 minutes or so due to processing of sensor data till it makes it into my system which is also way out in the field. Imagine a shipping pallet full of equipment that gets air dropped into the middle of nowhere. That IS my network, and it has no connection to anything but the sensors deployed with it. Maybe on a good day I'll have a wireless or satellite connection back to another network that may or may not have a time server on it. I can't ever assume this will be the case. I will, however, be rotating hard disks full of collected sensor data for off-line analysis (forensic stuff) at a less remote location. I will have spare parts (including NTP servers) at this location that will be visited daily.
I really only need time to one second. Most file systems don't have any finer granularity and we're not making scientific measurements. We have a system to display transient events inside of a time window that can be arbitrarily set, but typically no wider than 15 minutes. If the data is 15 minutes old, it's not important anymore. If the data is 40,000 years in the future due to a bad time stamp like when it's marked in miliseconds since the epoch (unix time) instead of seconds, we won't ever see it since it too is outside of my window. If it's 4 seconds old, that's okay. I'll see it inside of my time window. The problem with arrival times is that things I'm looking for don't happen the instant I get alerted. I may want to go back and look at when events happened and compare that with when I was notified so I can see where the bottle necks are. If I have a 5 second delay and 5 seconds of clock drift in the same direction, I don't see any bottleneck which is why I need to know roughly what time it is at each sensor, computer, and server at least to one second. It's rare when something I'm looking for comes directly into one of my systems. Almost always there is some processing going on by other teams on the project that are working independently from my team trying to make use of some of the data in different ways. They would then generate the alert message into my system. One of these teams that created data used a TAI reference clock and the folks using this data used UTC (as do I) and it really caused problems since one set of sensors is saying some event happened at a particular time and yet, there was nothing there at that time according to other sensors. I think in this case it was cars driving down a street (I have no idea how they actually determine this since I just ingest data) and another group took video data to generate tracks for vehicles that were not there at the time the vehicle detectors said they were. 34 second delay (TAI vs UTC) means I'm more than a half mile away from the sensor if I'm going about 60mph. If I'm trying to predict when a car will be near another sensor based on bad data, we'll never be looking at the right time. -Bob On Wed, Dec 1, 2010 at 12:08 AM, Hal Murray <hmur...@megapathdsl.net> wrote: > > rdarling...@gmail.com said: > > That's exactly what we've done in the past (setting it when on the > network > > and letting the clock do what it wants) and that's fine. The actual time > > isn't as important as the agreement on what time it is. This is > certainly > > the cheaper way to go and is becoming a viable option. > > How long does it take for data to get from way out in the field to your > system? > > Earlier, you said that you only needed time to within a second. That's a > long time for networking. > > If it's only 100 ms (pulled out of the air) for the data to get from the > sensor to your system, then forget all the timestamps as the local system > and > just use the arrival time at your system. > > If a significant part of the delay is things like RS-232 baud rates, you > can > correct for that constant offset. (or semi-constant if the length of a > message varies, but maybe you can record the length of the message and do > the > right correction) > > > > -- > 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.
