On Fri, Nov 30, 2012 at 8:39 PM, David I. Emery <[email protected]>wrote:
> On Fri, Nov 30, 2012 at 09:58:29PM -0500, Bob Camp wrote: > > Hi > > > > > The problem just the clock it's also the operating system. If it's not > > designed with timing in mind (= it's an RTOS at some level) then you > > will have sloppy timing. What is "sloppy timing"? If about 10 microseconds of error is "sloppy" then you are right. None of the effects you describe need to cause a problem. Even on a non-RTOS the limiting factor is the uncertainty in the interrupt latency. The way it works is that the PPS interrupts the CPU and then inside the handler a hardware counter is sampled and stored and that is it. Nothing else needs to occur in real time. Quite a few people are able to run NTP serversand keep there system clocks for small (uSecs) error from UTC. But now the question is if an application program can us the clock .without some error I think it can. A simple example is a program that time stamps data. It waits for data then when it comes in reads the system clock then tags the data with the sampled clock. The problem is if the CPU is taken away. One way to detect a problem is to read the clock twice and check for a deta time of more than a few nanoseconds. Then if you read the data between those to clock samples you will know the clock was acuratly sampled. Chris Albertson Redondo Beach, California _______________________________________________ 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.
