[ntp:questions] help with setting up NTP on windows with a USB GPS

David J Taylor david-taylor at blueyonder.not-this-bit.nor-this-part.co.uk.invalid
Thu Dec 3 14:22:48 UTC 2009


"Dave Baxter" <spam at goes.nowhere.com> wrote in message 
news:MPG.2581b3818527b329989695 at news.btopenworld.com...
[]
> Hi..
>
> Back after getting diverted by my central heating system going on the
> blink...
>
> Re Faros.  Good question, well presented, unknown (exactly) at this
> time!
>
> It does run it's own internal software clock, that I do know having
> asked Alex (VE3NEA) questions about it in the past.   That in turn is
> synched to a reference by NTP (not SNTP) it does not (AFIK) use
> "Windows" time in any way.
>
> (Sadly, he's totally uninterested in making it able to use a local GPS
> receiver with PPS, or a radio time code RX.)
>
> It's own internal timekeeping routines use a Kalman Filter (Think that's
> what it's called) to determine "true" time from a number of NTP sources.
> It is also quite "chatty" I expect compared to a true NTP client, as it
> will poll the NTP server (or selected collection of servers in rotation)
> about every 10 seconds!  Another reason I think a local server would be
> best :-)
>
> Generally it keeps good time, to within a mS or so, as it can reliably
> tell if a received signal comes the short or long way round the globe,
> even from New Zealand!  (A close call that one though.)
>
> However, it (for whatever reason) is not good at handling variable
> network latency, especially if the flight times to/from the server are
> different, as seems to be the case at odd times of day at present.
>
> With the Meinberg NTP server in the path now, doing the synchronization
> to the outside world's NTP boxes (for now) things are a little better.
> At least, it takes longer for the variable latency problem to screw
> things up, but it also takes longer to recover too.   Extra "filtering"
> in the overall path I guess.  (Software algorithms etc in the Meinberg
> software.)
>
> Anyway.  After reading all the info here, I now think I know how to do
> it correctly, setting up the Meinberg program, and overlaying Dave Harts
> binaries on it, also doing the registry thing pointing at the PPS
> supporting serial driver, so when I get enough of the right sort of time
> next time, I'll try again.
>
> One thing I picked up on, is the parameters in the NTP config file,
> regarding poll times.  The units of measure are not mS, but 2^n mS, I
> think?
>
> By the time I get my head round all this, we'll have probably lost HF to
> PLT anyway.
>
> Regards to All.
>
> Dave Baxter.

Dave, quite a few points there!

Polling external NTP servers every ten seconds is /very/ unfriendly, and 
some servers are likely to return the kiss-of-death to such a client, and 
may also deliberately return you an incorrect time value.  Using a short 
poll against your own server on your own LAN is a different matter, of 
course.

It sounds as if the best arrangement would be to have one PC as a 
stratum-1 NTP server (and it could be Windows- or FreeBSD-based), and get 
your Faros PC syncing to it.  Having that server on your LAN should 
greatly reduce the variable network latency.  You shouldn't need any extra 
filtering with a LAN poll time of 32 seconds (maxpoll 5).

I don't know Faros, but perhaps you could manage on a single PC by 
selecting the NTP server for Faros as 127.0.0.1 - the localhost - and 
having that same PC as a stratum-1 server from the GPS/PPS arrangement we 
have discussed.  This would provide a GPS or radio-clock time source, but 
with some additional control and filtering.

Poll times in the ntpq -p display are in seconds, as are the "when" times. 
You should see the "when" increasing by one per second until it reaches 
(or just exceeds) the "poll" value.

73,
David 




More information about the questions mailing list