Hi there
Setup;
======
My NTP setup uses 4 remote and 3 local clocks. The local clocks are
GPS-NMEA, GPS-PPS and DCF77.
I never got the PPS (on DCD) to work with a default Debian kernel and
NTPD, so I use David J. Schwartz' shared memory driver. It is loaded
just after the first time after boot that the PPP link (my ISP provides
either PPPoA or PPPoE) has come up and the NTPD is synchronised within a
few ms. The NTPD then is restarted and starts using PPS. So far so good;
http://www.sput.nl/ntpstats/sput/
http://www.sput.nl/ntpstats/parents/
A problem that occurred earlier;
================================
Using DCF77 on a multi serial card doesn't quite work. After a while
NTPD will ignore DCF77 info. Restarting NTPD NTPS 'solves' the problem.
Using a regular serial card on the mother board prevents the problem.
I don't know if this is a serial-card problem, a motherboard problem, a
kernel problem, a NTPD problem or a combination thereof. I do know that
I'm not the only one with this problem.
I suspect the 200 ms pulses may have something to do with it;
Normal data; One startbit (0), 8 databits (0 or 1), one stopbit (1);
-----+ +---+---+---+---+---+---+---+---+---------
| S | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | S
+---+---+---+---+---+---+---+---+---+
. .
/|\ /|\
| |
Check; Is bit 0? Check; Is bit 1?
If not; Framing error If not; Framing error
Data from DCF77 receiver;
A '0' is coded as a 100 ms pulse (the ports reads 240 / 0xF0);
-----+ +-------------------------
| 100 ms |
+-------------------+
A '1' is coded as a 200 ms pulse (the port reads 0);
-----+ +---------
| 200 ms |
+---------------------------------------+
.
/|\
|
Framing error
If this is the case limiting the pulse length to 180 ms will solve the
problem; The port still reads 0, but without framing errors.
I didn't test this. I just use a regular serial port.
A more recent problem;
======================
This is since I upgraded to Wheezy;
After a PPP link restart, the remote clocks show large offsets and
delays. Sometimes more than a second. Restarting NTPD solves the
problem. So I edited /etc/ppp/ip-up to restart NTPD.
More weirdness;
===============
A thunderstorm messes up DCF77. After all, it's long wave radio.
What is new is, a completely flat line in the DCF77 graph;
http://www.sput.nl/ntpstats/parents/combi-offset-dcf-flat.png
It is as if the NTPD stops reading data for a few hours. Which is
inconsistent with the DCF77 errors reported in the syslog. There are
long periods where no errors are reported.
So again, NTPD ignores input.
Regards,
Rob
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/kq1pvm$6um$1...@ger.gmane.org
