[ntp:questions] Palisade Reference Clock

Chris H ntp at archnetnz.com
Wed Sep 1 21:50:50 UTC 2010


If I do this while running ntpd

while true = '1'; do echo " " > /dev/ttyS0 sleep 10; done

I get:

addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call
refclock_transmit: at 31241 127.127.29.0
palisade_poll: unit 0: polling event
poll_update: at 31241 127.127.29.0 flags 1061 poll 4 burst 0 last 31241
next 31256
TSIP_decode: unit 0: AD #46172 21:42:23.744922011 09/01/2010 UTC 01
Overdet Clock
palisade_receive: unit 0: 2010 244 21:42:23.744922011
palisade_receive: unit 0: d029473f.bfa906dc  Wed, Sep  1 2010
17:42:23.748
refclock_receive: at 31241 127.127.29.0
refclock_sample: n 1 offset -0.003751 disp 0.000000 jitter 0.000001
clock_filter: n 8 off -0.003751 del 0.000000 dsp 0.000239 jit 0.011053,
age 0
select: endpoint -1 -0.017543
select: endpoint  0 -0.003751
select: endpoint  1 0.010041
cluster: survivor 127.127.29.0 metric 0.013792
select: combine offset -0.003751
poll_update: at 31241 127.127.29.0 flags 1061 poll 4 burst 0 last 31241
next 31257
clock_update: at 31241 assoc 1 
local_clock: assocID 30926 offset -0.003750883 freq -19.662 state 4
local_clock: time 31241 offset -0.003751 freq -19.662 state 4
local_clock: mu 17 jitr 0.019875 freq -19.905 stab 0.754067 poll 5 count
30
addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call

And from what ntp says, its now the sys.peer and reachable.
event is clk_ok

Without the echo into /dev/ttyS0 I get the following:

ddto_syslog: select(): nfound=-1, error: Interrupted system call
refclock_transmit: at 367 127.127.29.0
palisade_poll: unit 0: polling event
poll_update: at 367 127.127.29.0 flags 1061 poll 4 burst 0 last 367 next 382
addto_syslog: select(): nfound=-1, error: Interrupted system call
addto_syslog: select(): nfound=-1, error: Interrupted system call


and it never either brings the RTS or CTS line up, and so the packet is never
sent back to the ntp server.

I am not the worlds best coder, so I am not really sure what I am doing
to the driver.

Another machine is syncing to this server, and I notice I am getting
'falsetick' is reported in ntpq associations on the remote computer.

Thanks in advance :)


On Wed, 2010-09-01 at 12:54 -0400, Marc Leclerc wrote:
> Have you looked at both firmware docs to insure that there is no 
> changes in the packet data.
> 
> I had to play with this driver to talk to a resolution SMT and just a 
> few changes in bits definition gave me
> the same error. the driver will fail even if the error is from another 
> packet (secondary time or such)
> 
> hth
> 
> 
> 
> On 2010-08-31 06:17, Chris H wrote:
> >> We have an Acutime 2000, which has pretty much just worked since we bought
> >> it in 2005.  We haven't felt the urge to do anything to the firmware, and
> >> I've no idea what it's running -- whatever was current at the time.
> > Just looking at the bug fixes between 7.02 and 7.12, I thought it was a
> > good idea to upgrade... now I regret it :( hence my request from anyone
> > to get 7.10 firmware again.
> >
> >
> >> Have you tried running the (Windows-only?) configuration tool?  What does it
> >> say about the acutime?  Remember to run it on the *other* RS232 port on the
> >> bottom-end converter box from the one you normally connect ntpd to.
> > Yeha -- everything is working correctly, both ports are giving data.
> >
> >> Have you tried running the daemon in debugging mode, per the driver29.html
> >> page?  What does that say?  We found that quite useful on the one occasion
> >> where we had any problem with our unit.
> > I still get clk_noreply... :(
> >
> >> The only occasion that I recall having any problems at all was when we
> >> replaced the linux host with a faster machine, and we came to the
> >> conclusion that either the serial hardware was "different" or the new box
> >> was simply now pulsing the timestamp-me line too quickly.  As a quick hack
> >> workaround I simply duplicated the two ioctl()s in the driver which toggled
> >> the relevant control line.  It might be worth checking whether there's
> >> anything in the code like that...
> >
> > I have been leant a Serial Port Analyser..
> > HP4925A
> >
> > I can see the pulse per second coming into the unit, and I can see the
> > data on the screen.
> >
> > When I run palisade_monitor or tsipchat or anything, the whole thing
> > comes to life, both DTE and DCE all go green, and I can see packet flow
> > in both directions... however when ntp is running, it appears the comm
> > port does not 'become active' like it does when running tsipchat or
> > palisade_monitor, or anything like that..
> >
> > And all I can see in inbound RD light blink green.
> >
> > When I run palisade_monitor.exe and select Port A and select
> > View/Diagnostics and click Update, I can see RTS (on DTE side) and CTS
> > (On DCE side) go from green to red. When I click up the update button, I
> > can see the green link blink, but cant see the output packets on the
> > analyser..
> >
> > I will keep looking, but if anyone else has experience with the HP
> > analyser, and used one to diagnose problems, please let me know too :)
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > questions mailing list
> > questions at lists.ntp.org
> > http://lists.ntp.org/listinfo/questions
> >
> >
> >
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 






More information about the questions mailing list