Re: [chrony-users] NTP v4 header

[Harald Krammer <Harald.Krammer@xxxxxx>]

On Tue, 3 May 2011 13:54:33 +0200, Miroslav Lichvar
<mlichvar@xxxxxxxxxx> wrote:

> On Mon, May 02, 2011 at 09:23:30PM +0200, Harald Krammer wrote:
[...]
> 
>> I am not sure if it usable or not. That are small fixes/workarounds to
>> support substation embedded devices.
> 
> I think the patch to accept NTPv4 replies could be enabled by default,
> no need for a new option. I'll look into it more after 1.25 is
> released.
> 
> But I'm not sure about the other two options, they really seem
> dangerous. Lowering stratum may break loop detection and accepting
> time from a packet which says it's unsynchronized looks like a
> horrible hack, why is it needed only in the acquire module?
> 
> I assume there is no chance to fix the other software instead?
> 

Lowering stratum is needed for a special case. In the field we have
time sources with Stratum 4 and higher and special equipment needs at
least Stratum 3.
A local GPS time source is not set up the customer (costs aspects)
and the firmware from special equipment is not changeable.
That's why I made this solution.

The other hack has a similar cause. It exists a device that marks
the time as invalied in case of a missing ntp sources. The behavior
is fine but still we should take the time from a "bad device" on
the boot-up phase.  Synchronization itself isn't allowed.
The customer should see, something is wrong.

I have full understanding of a rejection of my patches, because
they are really strange. Or exists cleaner solutions for my hacks?


>> BTW, the NTP server from one device is still broken and does not work
>> properly.  The reason is a failure of test6.
>> 
>> Source: ntp_core.c
>>   /* Test 6 checks that (i) the remote clock is synchronised (ii) the
>>      transmit timestamp is not before the time it was synchronized
>>      (clearly bogus if it is), and (iii) that it was not synchronised
>>      too long ago
>>   */
> 
> Which of the three conditions fails? Perhaps it's the same problem as
> in the acquire module?

It is the second condition.
(UTI_CompareTimevals(&remote_reference_tv, &remote_transmit_tv) is 1

Trace-Output:
source_is_synchronized is 1
(UTI_CompareTimevals(&remote_reference_tv, &remote_transmit_tv) is 1
(remote_reference_tv.tv_sec + NTP_MAXAGE - remote_transmit_tv.tv_sec) is
781577307

ntp_core.c:1055:(receive_packet)[04-05:39:49] lvm=34 stratum=8 poll=6
prec=-11
ntp_core.c:1057:(receive_packet)[04-05:39:49] Root delay=00000000
(0.000000), dispersion=00000000 (0.000000)
ntp_core.c:1059:(receive_packet)[04-05:39:49] Ref id=[a0108f9],
ref_time=00000000.00000000 [Thu 02/07/36 06:28:16.000000]
ntp_core.c:1063:(receive_packet)[04-05:39:49] Originate=25656bd1.5be10535
[Wed 05/04/11 05:39:49.207121]
ntp_core.c:1066:(receive_packet)[04-05:39:49] Message
receive=25656bd1.5d981135 [Wed 05/04/11 05:39:49.207300]
ntp_core.c:1070:(receive_packet)[04-05:39:49] Transmit=25656bd1.17fc2536
[Wed 05/04/11 05:39:49.211517]
ntp_core.c:1074:(receive_packet)[04-05:39:49] theta=-0.000166
delta=0.000697 epsilon=0.000021 root_delay=0.000697
root_dispersion=0.000021
ntp_core.c:1077:(receive_packet)[04-05:39:49] test1=1 test2=1 test3=1
test4=1 valid_data=1 good_data=1
ntp_core.c:1080:(receive_packet)[04-05:39:49] test5=1 test6=0 test7=1
test8=1 valid_header=0 good_header=0
ntp_core.c:1083:(receive_packet)[04-05:39:49] kod_rate=0 valid_kod=1

When I force test6 to true, then the synchronization seems to work. I
made an extra option to support that behavior and will put it into my
git-tree.

Nice greetings,
Harald

---
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx 
with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.