On 2/26/2012 2:30 PM, A C wrote:
On 2/26/2012 10:20, David J Taylor wrote:
"A C" <agcarver+...@acarver.net> wrote in message
news:4f4a6e79.3010...@acarver.net...
[]
It's the latest dev version on NetBSD using five network servers plus
the SHM refclock plus the ATOM refclock. The SHM is not very stable
with its offset so I don't use it right now which leaves me ATOM plus
network (one of the network servers is marked prefer). (Don't ask
about using NMEA with PPS enabled, it doesn't work due to the serial
drivers on NetBSD/sparc so PPS has to be separate via a second serial
port).
If I set minpoll to 8 or 9 to be nice to the network servers, it takes
six or eight polling periods before ATOM turns on and becomes the
system peer. If I leave out minpoll, ATOM clamps the polling period to
64 seconds. It still takes six to eight polling periods to activate
ATOM but 8 * 64 is much less than 8 * 256 or 8 * 512.
Thanks for that summary, there are so many systems being discussed that
it's easy to lose touch!
Leaving aside the question of when the ATOM driver becomes selected,
isn't the time accurate enough for your purposes simply by using the
five networks servers within a minute or two? I take it that you have
"iburst" against all the servers, and that you have one of them marked
"prefer"? Can you accept a reduced accuracy until the ATOM kicks in?
I've done it before so it's entirely possible to let it go for the
total cycle time until ATOM is selected, it just means that the system
then takes a while to slew into position after it has been on the
Internet servers for a while. I was just hoping to have the best of
both, faster convergence and then a kinder polling period afterwards.
In the discussions I had with Dave Mills here some time back, I recall
that it was a requirement that is the ref clock was at 16s intervals,
the Internet servers shouldn't be at 1024s, although that does seem to
work correctly here. I have at the back of my mind a feeling that it's
tied in with the NMEA not working, i.e. the ATOM driver is somehow
working on its own (as an edge of second reference) without a "time of
day" source being polled at a similar interval.
Anyway, all I can suggest is trying FreeBSD and seeing whether its
serial drivers will work for you. I don't feel I can help further.
FreeBSD's serial drivers are also very broken (in fact, even more
broken than NetBSD because FreeBSD can't even see the DCD line).
I'll just experiment with the keys and ntpq commands that Dave Hart
suggested. That will probably get me what I'm looking for though I
may have to stagger the drops and re-adds if it is truly a drop and
re-add rather than just updating the parameters.
I just had a thought that I wanted to share. Now, I know just enough
about Linux to be really dangerous, and nothing about any form of BSD.
So, people who do know about such things may laugh at this idea. But,
what if you could do this:
Write your own special script to start up NTPD. Have two versions of
ntp.conf, say, ntp.conf-fast and ntp.conf-slow. When the script starts,
first copy ntp.conf-fast over to /etc/ntp.conf (or wherever it lives).
Then, the script starts NTPD. Then the script goes to sleep. During
this time, NTPD will be running with a version of ntp.conf which sets
polling intervals very fast to get quick convergence. After NTPD has
been running, and the script has been sleeping for, say, 10 minutes,
let's suppose that the PC clock is very close to the GPS time or a
preferred internet server. (I realize the term "very close" can be
interpreted different ways.) Say it's within 10 ms. After 10 minutes,
the script wakes up again. It shuts down NTPD. Then, it copies
ntp.conf-slow over to /etc/ntp.conf. Then, it restarts NTPD. Now the
script terminates, but NPTD keeps running. Now, however, NTPD is
running with an ntp.conf file that has longer polling intervals that you
want after the system is stable. When NTPD is restarted, it SHOULD
maintain the close alignment of the PC clock to the preferred source, I
think. It should pick up running about where it left off, and then fine
tune the synchronization over the next few hours, perhaps. That way,
you could have your cake and eat it too. Short polling intervals at
first, then longer ones.
If, HOWEVER, you encounter the phenomenon (bug?) I've experienced in
Linux, you clock will jump to a large offset when NTPD starts up, and
that will foil the plan.
My approach of polling the GPS at very short minimum intervals and the
internet servers at longer minimum intervals seems to be working OK. As
long as my GPS time is normally not too far out from what the internet
servers are reporting, it should still fail over to the internet if the
GPS becomes unreliable.
Sincerely,
Ron
--
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
Ron Frazier
timekeepingdude AT c3energy.com
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
