[ntp:questions] timing issue with a HP 58534A

Dave Hart hart at ntp.org
Mon Feb 6 20:53:53 UTC 2012


On Mon, Feb 6, 2012 at 16:58, Mark C. Stephens <marks at non-stop.com.au> wrote:
> Concentrating on the freebsd box:
>
>  7 Feb 00:22:51 ntpd[5091]: ntpd exiting on signal 15
>  7 Feb 00:22:52 ntpd[5117]: proto: precision = 2.236 usec
>  7 Feb 00:22:52 ntpd[5117]: ntp_io: estimated max descriptors: 11095, initial socket boundary: 20
>  7 Feb 00:22:52 ntpd[5117]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
>  7 Feb 00:22:52 ntpd[5117]: Listen and drop on 1 v6wildcard :: UDP 123
>  7 Feb 00:22:52 ntpd[5117]: Listen normally on 2 em0 192.168.5.112 UDP 123
>  7 Feb 00:22:52 ntpd[5117]: Listen normally on 3 lo0 fe80::1 UDP 123
>  7 Feb 00:22:52 ntpd[5117]: Listen normally on 4 lo0 ::1 UDP 123
>  7 Feb 00:22:52 ntpd[5117]: Listen normally on 5 lo0 127.0.0.1 UDP 123
>  7 Feb 00:22:52 ntpd[5117]: peers refreshed
>  7 Feb 00:22:52 ntpd[5117]: Listening on routing socket on fd #26 for interface updates
>  7 Feb 00:22:52 ntpd[5117]: GPS_NMEA(0) serial /dev/gps0 open at 9600 bps
>  7 Feb 00:22:52 ntpd[5117]: GPS_NMEA(0) 8011 81 mobilize assoc 60778
>  7 Feb 00:22:52 ntpd[5117]: 192.168.5.8 8011 81 mobilize assoc 60779
>  7 Feb 00:22:52 ntpd[5117]: 0.0.0.0 c016 06 restart
>  7 Feb 00:22:52 ntpd[5117]: 0.0.0.0 c012 02 freq_set kernel 119.785 PPM
>  7 Feb 00:22:53 ntpd[5117]: GPS_NMEA(0) 8024 84 reachable
>  7 Feb 00:22:53 ntpd[5117]: GPS_NMEA(0) 903a 8a sys_peer
>  7 Feb 00:22:53 ntpd[5117]: 0.0.0.0 c415 05 clock_sync
>  7 Feb 00:23:19 ntpd[5117]: 192.168.5.8 8024 84 reachable
>  7 Feb 00:24:13 ntpd[5117]: GPS_NMEA(0) 931a 8a sys_peer
>
> I can't see any sign of a whinge?

Assuming I remember correctly that you're using 4.2.6p5 on the freebsd
box (I'm sorry, with multiple issues bouncing back and forth at the
same time, it would help to keep reminding of details like which ntpd
version on which OS with which ntp.conf), the code in 4.2.6p5 is:

	NLOG(NLOG_CLOCKINFO)
		msyslog(LOG_WARNING, "%s flag1 1 but PPSAPI fails",
			refnumtoa(&peer->srcadr));

This means the whinging is conditional on your logconfig -- with
logconfig =allall (or =clockall or =clockinfo) and fudge flag1 1 you
should see a message logged if PPSAPI fails.  On the latest ntp-dev
4.2.7, the same message is logged, but it's not conditionalized under
clockinfo (no NLOG).

On Windows PPSAPI will not work unless you install the
separately-distributed serialpps package, but as a booby prize you
have the nonstandard. low-performance, and finicky user-mode PPS
timestamping available on the first NMEA sentence after each PPS
event.

Cheers,
Dave Hart


More information about the questions mailing list