[ntp:questions] Re: questions on msf (via shm) clock
ntp-200203 at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk
Thu Dec 30 05:54:23 UTC 2004
On Thu, 30 Dec 2004 00:47:51 +0100, mike wrote:
> dave morgan wrote:
> > resistor connected to wrong pins :-/ ) I have got my MSF refclock
> > working. This has raised the following questions -
> > a) will its jitter figure never go below 1?
> you may be able to get better a bit better. I have a homemade
> DCF refclock that get around 1 aswell. For the $15 it cost to make
> I consider it OK.
> remote refid st t when poll reach delay offset jitter
> 127.127.1.0 LOCAL(0) 10 l 32 64 377 0.000 0.000 0.001
> *127.127.28.0 .DCF. 0 l 34 64 377 0.000 -3.387 1.115
I'd say it depends on the quality of your clock hardware and the
way your OS handles things. It also depends on what version of the
software you're running (the latest software internally filters
away some samples to reduce the jitter figure).
Here's how my ten-year-old machine that's 100% busy, with FreeBSD as
OS, and customized radioclkd/shm software, but a hardware clock that
is not as good as others I have available, looks right now (early
morning, several hundred km away from the transmitter, just to the
south of the german border):
remote refid st t when poll reach delay offset jitter
+GENERIC(1) .DCFa. 0 ? 1 16 377 0.000 -0.010 0.827
-PPS(2) .PPS. 0 ? 9 16 377 0.000 0.344 0.254
LOCAL(2) LOCAL(2) 9 ? 6 64 377 0.000 0.000 0.015
*SHM(0) .DCFa. 0 ? 3 16 377 0.000 -0.234 0.797
+SHM(1) .DCFa. 0 ? 5 64 377 0.000 -0.029 0.068
BROADCAST.netsc .BCST. 16 u - 16 0 0.000 0.000 4000.00
+Cabal-GW 22.214.171.124 3 u 38 64 377 7.547 -0.104 0.833
All refclock lines except the last are derived from this one DCF77
hardware clock. GENERIC and PPS are from ntpd itself -- GENERIC
tuned with pps, so it's better than without. ntpd itself is probably
a couple years out-of-date, but it works for me.
SHM(0) is older radioclkd code, adapted so that it updates the shared
memory segment with every DCF77 pulse (thus the poll interval as low
as possible, plus whatever burst option allows me to grab samples pretty
much every second).
SHM(1) is based on the latest radioclkd code and how it filters away
timestamps that would result in higher jitter, but the drawback that
it only updates the shared memory segment at the top of each minute.
This probably compares to the code that you're running.
It's quite possible that the typical <100 microsecond jitter figures
I see from SHM(1) are due to use of the burst options that grab several
samples at every interval, when the actual data gets updated no more
than once per minute. Note that at the time of the above ntpq
snapshot, I'm not synced to the PPS signal which is the normal
reference to which ntpd is locked (as it is now). This consumer
clock is really bad compared to another one I have, so I'm surprised
the numbers don't look worse.
> > b) why does the refid for this clock show SHM(0), even though the
> > lines for it in the ntp.conf file is as follows?
> > fudge 127.127.28.0 stratum 2 time1 0.022 refid MSF
> .0 is shm(0) .1 (1) etc
The refid, based on my observations, is set (or not) according to
the stratum of the refclock. As you've set the stratum to be non-
zero, that changes the default behaviour so that it doesn't show
the ID of the desired refid. Remove your forced stratum and let
it be the default of 0, and you'll see it appear as you wish. I
think you can set stratum 1 and see the refid properly, but at 2
and worse, you don't.
At least, that's my observation.
More information about the questions