On Dec 5, 6:56 UTC, "David J Taylor" wrote:
> It sounds as if your application - like some of mine - would benefit if
> NTP were able to provide a new function where you could call it on your
> local PC to get the time, rather than having to use a call via a network
> packet, with all those overheads.  The function would be really simple,
> taking no arguments:
>
>   ntpGetTime
>
> and returning a 64-bit timestamp value (as 
> perhttp://www.ietf.org/rfc/rfc2030.txt).
>
> Would some kind soul like Dave Hart care to provide a small DLL which
> could do this - perhaps even as part of his serial kernel-mode PPS support
> DLL?
>
> Perhaps there is some fundamental point I'm missing which makes this
> difficult, though?

I am guessing you're actually in a better position than me to provide
a DLL exposing a function to get the time from ntpd.  There is no way
other than a NTP packet to request a timestamp from ntpd.
Additionally, if ntpd is busy, it may take some time for ntpd to send
its response.  You'll get a very good idea of the time when you
receive the response, but not necessarily of the time you requested
the time.  Since waiting on ntpd is involved, such a function could be
provided with a nonblocking option where the caller is given a socket
to select for readability while awaiting the response, and calls back
after its readable to retrieve the time.

Cheers,
Dave Hart

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

Reply via email to