problem with ntpd refclock and pps via parallel port

problem with ntpd refclock and pps via parallel port

Post by David Lor » Tue, 02 Feb 2010 08:37:01



problem with ntpd refclock and pps via parallel port

Hi

on system A I had type 22 pps working ok from pps at ttl
level to DCD of serial port. This was a bit erratic and
temperature sensitive possibly due to mismatch of ttl/rs232
levels.

on system B, rather than add complication of ttl=>rs232
conversion I've connected pps to parallel port and changed
symlink to be /dev/pps0 => /dev/lpt0

With same NetBSD-5-PPS kernel as on system A, I am getting following in
ntp.log at startup:
refclock_atom: /dev/pps0: Interrupted system call
configuration of 127.127.22.0 failed
No PPS shown by 'ntpq -p'

A google for above here gave some messages from suggesting
use of atppc* at isa?, ppbus* at atppc?, pps* at pps?
so now I have dmesg with
atppc0 at isa0 ......
atppc0: capabilities=3<INTR,DMA>
ppbus0 at atppc0
lpt0 at ppbus0
pps0 at ppbus0

System B, NetBSD-5, doesn't have a refclock, just other
ntp servers but ntp docs appear to state this as being ok.

On system C, NetBSD-4.0.1, which is working ntp server with
MSF clock on serial via DCD, I've just tried link
pps0 => lpt0 and have same output from ntpd as from system B.
I've since rewired system C with MSF to serial dsr and
pps to serial dcd, restarted and ntpq shows
SHM(0)/MSFa and PPS(0) and after a short while get +SHM(0)
then oPPS(0) with system having drifted > 10ms whilst
rewiring and restarting but now back at < 1ms.

So does pps really need a refclock and/or does pps via
parallel work ok or not on NetBSD-5?


Tomorrow I'll rewire gps that just about works ok out of
bedroom window and give that a try on system A, NetBSD-5,
with both serial and parallel.


cheers

David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Tue, 02 Feb 2010 10:44:14


Local TV = no signal so missed film I'd intended watching

so instead:

GPS + nmea driver + pps0 => tty0 ok
then after relinking to pps0 => lpt0 that's also ok.

only difference between that and non working setup is lack
of refclock for timecode and using one of servers on lan
set as preferred.

I'd intended just running ttl => lpt for pps but looks like
I'll also need rs232 with timecode signal.

cheers

David

 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Tue, 02 Feb 2010 12:30:31

avid Lord wrote:

Took parallel cable back to try on the pool server and on
swapping to use lpt0 I had original error that 127.127.22.0
refclock config failed. MSFa was still listed but no PPS.

Thinks!

Tried again with both serial dcd and parallel NACK connected to
pps output same as by chance when using breakout adaptor
upstairs. Restarted ntpd. Now have PPS(0) again. Will it sync?
YES. Is this a bug or feature of my hardware?

Anyway 5 minutes later and "+SHM", "oPPS(0)" and offset < 1ms.
Plus jitter possibly lower with the parallel port connection,
certainly no worse from this soon after restart.

1 Feb 02:20:24 ntpd[2136]: ntpd exiting on signal 15
1 Feb 02:20:27 ntpd[5808]: clock SHM(0) event 'clk_noreply' (0x01)
1 Feb 02:20:28 ntpd[5808]: clock PPS(0) event 'clk_noreply' (0x01)
1 Feb 02:25:55 ntpd[5808]: synchronised to ........., stratum 2
1 Feb 02:25:55 ntpd[5808]: kernel time sync status change 2001
1 Feb 02:29:01 ntpd[5808]: synchronised to SHM(0), stratum 0
1 Feb 02:32:19 ntpd[5808]: synchronised to PPS(0), stratum 0

st t poll reach delay offset jitter
+SHM(0)/.MSFa. 0 l 128 377 0.000 1.414 4.028
oPPS(0) 0 l 64 377 0.000 -0.520 0.595
LOCALPEER2 2 u 256 376 0.641 -0.102 0.072
LOCALPEER3 3 u 256 376 0.385 -0.052 0.451
+PUBSERVER1 2 u 1024 77 24.038 -0.262 0.106
-PUBSERVER2 2 u 1024 77 27.644 -1.099 0.086
-PUBSERVER3 2 u 1024 77 20.870 8.630 0.279
-PUBSERVER4 2 u 1024 377 19.243 -0.799 0.238


cheers

David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by hal-usene » Tue, 02 Feb 2010 16:53:25

In article < XXXX@XXXXX.COM >,
David Lord < XXXX@XXXXX.COM > writes:


Anything close to a TTL level should work OK into a RS232
reveiver port.

I wonder if you are on a wild goose chase.

What sort of toys do you have available?

The simplest solution would be a scope.

You can probably rig up something with a comparator chip
and a pot. Feed your PPS signal into one side of the comparator
and use the pot to adjust the other side. Put a LED on the output.
Twiddle the pot until it stutters. Then measure the voltage
on the pot. If you have a narrow PPS, you will have to rig the
LED up differently to measure the other voltage. Mumble.
I'm pretty sure something like that will work.

--
These are my opinions, not necessarily my employer's. I hate spam.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Tue, 02 Feb 2010 20:48:23


Some rs232 receivers I've checked datasheets for are not ttl
compatible. Different versions have different thresholds, some
versions can have threshold changed by external resistor.

Either using parallel port or serial with proper rs232 levels
is probably easier than experimenting with levels vs
temperature on all my different hardware.

Ntpd statsfiles will eventually show if there has been any
gain from parallel port connection. At moment it looks
worse but there's been a > 1C drop in temperature overnight
and frequency offset hasn't yet caught up. PPS(0) is still
in line with best of remote peers although all with offset
about -2ms.

Next two nights are forecast to have even lower early
morning temperatures. ie variation of server system clock
with temperature is the biggest factor just at moment. The
frequency offset of this pool server is around -50ppm which
ntpd still has great difficulty keeping under control vs
other pool server with frequency around -2.5ppm which shows
less temperature sensitivity.


cheers

David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by unru » Wed, 03 Feb 2010 00:07:34


Yes. Otherwise it has no idea what the seconds is. Ie, all pps does is
deliver a pulse at the exact second boundary, but that says nothing
about which second that is the boundary of. You need some other source
to give you the seconds.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by cmadam » Wed, 03 Feb 2010 00:27:27

Once upon a time, David Lord < XXXX@XXXXX.COM > said:

Just as an FYI: I'm using a GPS (SVeeSix) with PPS into a parallel port
under Linux (using user-mode SHMPPS instead of PPS kernel), and it works
fine. I typically see offsets from network clock sources under 1 ms.

--
Chris Adams < XXXX@XXXXX.COM >
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Wed, 03 Feb 2010 01:03:47


Sorry, I missed mention of the local ntp peers.

There were three local servers to give time to second, one being
a pool server with radioclock that I was attempting to distribute
pps from via parallel port. Docs I have indicate a server can be
used to get "second" in place of refclock,

I'm now thinking that might still be the case and parallel port
implementation on NetBSD isn't correct. I've not yet had time
to figure out where I'm currently getting my pps from, DCD on
serial, or NACK on lpt0.

I can try again on desktop but now I have present config working
will give that a week to get some reasonable stats.

cheers

David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by unru » Wed, 03 Feb 2010 02:52:49


Yes, it certainly can. However you should make sure that your system is
within a half second of the correct time before starting the PPS.
Otherwise the PPS will just take the current seconds, and lock you onto
a time which is out by seconds.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by unru » Wed, 03 Feb 2010 02:54:21


I use the parallel port as well ( my own interrupt service routine, and
shmpps to deliver the time to ntp) and get typically 1-10usec accuracy.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Wed, 03 Feb 2010 07:20:42


Now I han have another play with this I find that I must
have still been on serial DCD since disconnect of parallel
lead made no difference. Symlink was pps0 -> lpt0 and I
was sure I'd restarted ntpd ok before going to bed late
this morning. Now a restart gives the configuration failed
and no PPS.

I've moved symlink back to pps0 -> tty00 and ntpd restarted
this time with minpoll 4.

I'll go back to playing with lpt port for another day. I'd
just expected it to work.

David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by hal-usene » Wed, 03 Feb 2010 14:41:52


It doesn't need a refclock. A server on the net will work.


--
These are my opinions, not necessarily my employer's. I hate spam.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by hal-usene » Thu, 04 Feb 2010 09:31:05

>Some rs232 receivers I've checked datasheets for are not ttl

If anybody finds a data sheet for a modern chip that
doesn't work right with TTL signals, please let me know
about it.

--
These are my opinions, not necessarily my employer's. I hate spam.
 
 
 

problem with ntpd refclock and pps via parallel port

Post by David Lor » Fri, 05 Feb 2010 08:42:06


I've only mc1489 chips to play with here, on=1.25, off=1.0,
and mc1489A, on=1.95, off=0.8. Both those would be ok with
my bc337 pulldown ttl output. I'm pretty sure my old printer
required on=+3, off=-3. As for various pcs here they probably
have m/b from mid 90's to 2007 and I've no idea as to what
rs232 levels they switch at. Point is it's much easier to
add a 1488 to my circuit to eliminate rs232 threshold as
potential problem than to shutdown the web/mail/ntp server,
(now in pool), to do any experiments.

I also agree that "wild goose" chase may apply to possibility
that thresholds are relevant. However using ttl level direct
to lpt would have saved me the trouble of adding the 1488 chip
just to make sure.

Indication there is a problem, either in the interface or
the 60kHz MSF receiver is that reach doesn't remain at 377
when room is unheated.

There's also another problem I have to resolve and that is
ntpd possibly not keeping up with temperature changes, giving
a square wave variation of about +/- 1ms in offset, lately
during very cold spell, with main period of about 24 hr.
Otherwise with lesser temperature variation, the offsets ramp
up/down to around +/- 300us corresponding roughly to heating
system switching on/off. That's going to require experimenting
on a spare system with addition of heater to crystal, or if I
bring one of old 486dx back into life, possibly by swapping
jumpers to use an external clock source.


David
 
 
 

problem with ntpd refclock and pps via parallel port

Post by unru » Fri, 05 Feb 2010 09:39:38


..

ntpd has about a 1 hour half life (it takes an hour to correct the
error level by 1/2) for short polling intervals, longer for longer.
If you hav3 a refclock you are polling at about poll level 4 ( which has
the 1 hr time scale). the only way ntp knows something has happened is
that the drift changes the time slowly, and ntp then slowly changes the
drift rate to try to bring things back into line. that all takes a long
time.


Three possibilities.
a) if you run linux/bsd, run chrony. It corrects for temp drifts much
much faster.
b) put the computer into a temp controlled box or install a temp
controlled crystal.
c) get the "temp" patc hfor ntp, which uses an onboard temp sensor ( eg
the motherboard temp sensor) to correct for the temp variations ( does a
fit to the temp vs rate and then uses that to correct for the changes in
temp).