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@lists.ntp.org > > http://lists.ntp.org/listinfo/questions > > > > > > > > _______________________________________________ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions