[ntp:hackers] Problems with Oncore???

[Terje Mathisen]

Hello, I have just received 4 Synergy G-SynQ evaluation kits with the
combined antenna/Oncore M12+ timing receiver, and I'm currently setting
them up on a set of new servers.

I have several problems though and I wonder if any of you have seen
something similar:

The three units I have tried so far all seem to behave perfectly nice
using the included SynTAC sw, and I've used that to perform a manual
site survey to get good location data for the ntp.oncore.N files.

However, when I move the unit that's been mounted on top of the roof,
using a special-order 30-m cable, from the Windows laptop to the actual
server, I get some _really_ strange errors:

refclock_oncore.c complains about missing CR/LF message terminators on
several messages, when I comment out this test I got checksum errors
instead, so I modified the source code to dump both the packets and a
manually calculated checksum (XOR) of all the bytes, including the
checksum byte. This XOR should then always be zero, right?

When I find is that three different packets are always terminated by 012
012 octal, i.e. LF/LF instead of CR/LF, and the checksum is off by 7,
i.e. the manual checksum result is 007 instead of 000.

The packets where this happens is @@Ha, @@Hn and @@Bb, these messages
are initialized by SynTAC, then I used MODE 0 to avoid all
re-initialization.

I am currently wondering if there could be a problem with the serial
port on the HP DL140 server I'm using...

----------

Timing results:

When I install one of the new clocks alongside my original UT+, I get a
fixed offset of 13-14 us, i.e. the new unit reports -13 or -14 when the
old one (which is PREFERed) is in sync.

It would seem that 13-14 us is a horribly long processing latency in the
interface unit?

Poul-Henning, did you see anything like these numbers when you tested 8
or 10 of these units in parallel?

Terje
-- 
- <Terje.Mathisen at hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"