First of all, sorry for the formatting issues. I will follow your
recommendations and try to avoid this in the future. Answers to mike
cook's and William Unruh's mails are below.
mike cook wrote:
The time_t stamps are available as the transmit time in all ntp
packets coming from the peer. One way you could get them is to run
ntpdate -d against the peers. You could do that in your program in a
pipe and parse the stdout.
I am still confused as to the current status.
If I am following ,you are collecting timestamps (which are
offsets from the moment of boot of a remote system) and with which you
are populating shared memory attached to the shared memory refclock
driver. At the moment these are absolute offsets (say with a base of 0
, or 00h00m00s 1 jan 1970 in the unix epoch), and you are saying that
your system clock is synchronizing correctly by NTP with reference to
that epoch . So your system should be now showing dates well in the
past.
Is that the case?
Now you want to add a network ntp server to the config to get your
system clock UTC sync'd. If that is the case, before starting NTP
normally, you can set the system clock to that of a bunch of servers
with either ntpdate, or ntpd -g. If you have no network at this point
you will be able to detect it and take further action such as
requesting that the date be set manually. That will give you a
reasonable starting value sync'd to UTC. Then you can "normalize" your
refclock timestamps by computing the offset with the now correct
system clock value and adding that fixed delta to each of the new raw
timestamps before populating the shared memory.
Is that the plan? Or have I lost my paddle.
Almost, if I understand you correctly. Here is a problem description
that clarifies it hopefully:
Let's assume in a simple setup we have 3 systems A, B, and C. A is a
NTP server (stratum 1 or 2) on the internet, B is a local server with a
standard oscillator, and C is a system in the same network as A with a
temperature-stable oscillator (and a known frequency offset in ppm). C
does not provide absolute timestamps but only timestamps relative to an
unspecific epoch (e.g. its starting time). C sends B those timestamps
and on arrival they may be passed to NTP or another program via a
sufficient interface (e.g. shared memory). The system clock of B is
synchronized via NTP with A as server.
The accuracy (difference compared to UTC, under 1ms and lower even in
the initial phase of NTP would be ideal) and stability (how closely the
clock maintains its frequency) of the clock in B is to be improved. The
initial idea was to use the relative timestamps of C in B (a) via PPS
or (b) as a refclock via the shared memory interface. I have not
figured out a way to approach (a) but am working (b). As the timestamps
from C are likely relative to another epoch than 1. January 1900 and
the clock in C drifts, before the timestamps are passed to NTP in B, an
offset has to be determined. This offset has to be adjusted (each
timestamp or frequently when out of a specific threshold) as the
oscillator in C has a drift. For example: A simplified procedure works
when I do not use an external NTP server but synchronize to the local
clock via clock_gettime with CLOCK_REALTIME and an offset (to simulate
another clock than the system clock). That is, determine the epoch
offset by using two timestamps that were approximately generated at the
same time (this should approximately be the difference of 1. January
1970 plus offset to the epoch used in C). The frequency drift in C I
havn't respected in this setup. The quality of this solution I havn't
determined.
For receiving the timestamps of A I implemented a call to 'ntpq -c "rv
0 clock"'. What do 0, &1, &2, and so on for rv actually reference? When
I look at the output of 'ntpq -c "association"' I get assid's with 5
digits. When using multiple servers in NTP, this procedure has to be
adjusted, of course.
Do you think (a) or (b) may be actually working? Do you have other
ideas? I guess another option would be to buy a cheap GPS clock for B
and use it as refclock and PPS source but that would be just too easy
(and a little more expensive).
William Unruh wrote:
It is very unclear what your mean (and I do not just mean the
formatting). Is this an external clock to the computer? Do you at least
know that the clock starts on the second, or is the start time unknown
even to the microsecond level? Why do you want to use that clock?
"It works well when setting its offset to the system clock"
What works well? Are you trying to get that relative clock to have the
correct time, or is it providing the time?
Yes, ntpd would find it very very difficult to use that clock as a
reference. A PPS signal which has not seconds marker, at least is know
to be accurate to the ms, and it can be used to discipline the system
clock to the ms, if something else disciplines the seconds. Your give
nothing except the rate, and ntpd uses only the offset to determine the
rate.
Thanks for your patience with me and my imprecise descriptions. I hope
the above answer clarifies what I actually mean.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
