Re: Post processing of NTP data...



I've embedded some further questions below.

By the way, thanks for the insight.

On Sep 27, 2005, at 5:05 AM, Brad Knowles wrote:

At 5:08 PM -0400 2005-09-26, Val Schmidt wrote:


I want to log several things with time stamps on the order of ~ . 1ms -
maybe less.



Most modern OSes don't allow you to directly achieve better than 10-20ms accuracy at the level of an individual event. Some real-time operating systems (RTOSes) may allow you to achieve finer resolution at that level, but I don't know if any of them are going to let you get down to the level you want.

Can you help me understand why?

Setting aside for a moment the issue of ntp itself and the roping in of the system clock, is the crux of the problem that the processing of interrupts is too unpredictable?

In my simplistic way of thinking of things, assuming the clock is sufficiently accurate, it seems to me the ability to time-stamp an event appropriately should be directly proportional to the time it takes to recognize that the event has occurred and retrieve a time stamp. When an event occurs and an interrupt is registered, the speed of the processor or more accurately, the speed in which it can be preempted seems to me to be the limiting factor. Is this the correct way to think about things?

Then returning to the system clock, would making data logging system itself a stratum 1 server provide sufficient stability for ~.1ms stable long-term time-keeping? It occurs to me that even a stratum 1 server is at the mercy of interrupt processing when the reference clock registers a new signal of some kind. I don't suppose ntp does any kind of benchmarking of the system on which it's running in some attempt to determine and correct for the interrupt latency of the OS.

-Val

------------------------------------------------------
Val Schmidt
CCOM/JHC
University of New Hampshire
Chase Ocean Engineering Lab
24 Colovos Road
Durham, NH 03824
e: vschmidt [AT] ccom.unh.edu
m: 614.286.3726


_______________________________________________ questions mailing list questions@xxxxxxxxxxxxxxxxx https://lists.ntp.isc.org/mailman/listinfo/questions

.



Relevant Pages

  • Re: utc date set back to cdt by ntpd
    ... > with the trimble driver setting the system clock and using that 1pps time ... correctly on your local server. ... another factor is that you shouldn't set your stratum within the NTP ... > UTC and the system clock advances by the 5 hours as it should. ...
    (linux.redhat.misc)
  • Re: DateTime Ticks/Milliseconds Question (possibly Thread.Sleep () related - ?)
    ... The resolution of the system clock isn't 1/1000 second, but rathter something like 1/62 second. ... There is an interrupt that increases an integer value 62 times a second, this integer value is then converted to a time value when you use DateTime.Now. ... I am asking my thread to sleep for 1 millisecond). ... encountered before to do with thread scheduling (ie: ...
    (microsoft.public.dotnet.framework)
  • H8S timer configuration problem
    ... I am having a problem generating a period interrupt on an H8S2329. ... System clock is 22.1184MHz throughout. ... any difference what I set TGR1A to, the interrupt is as if it is set to its ...
    (comp.arch.embedded)
  • Re: getutcdate() issues
    ... If your server has incorrect local time, ... I still fail to understand why this is the database engine's fault. ... them with the correct system clock. ...
    (microsoft.public.sqlserver.programming)
  • Reference Clock / shared memory driver
    ... I have a server 127.127.28.2 prefer minpoll 4 entry in my ntp.conf ... entry creates a shared memory segment on startup with a defined shared ... I use a system clock time from another application via a 1553 bus from ... The problem is do NOT see my system clock being updated after the ntpd ...
    (comp.protocols.time.ntp)