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.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
