| Re: [chrony-users] NTP v4 header |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 4 May 2011, Harald Krammer wrote:
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.
Why on both items? If the special equipment is demanding stratum 3 or lower it
is presumably an attempt( a bad and misguided one) at making sure that the
time it gets is close to correct. You are saying "I do not give a damn about
that and want to know how to lie to the machine to get around that stupid
restriction". While I agree that the restriction is stupid, I also think that
lying will get you into trouble.
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.
Cost? A GPS time source can be had for well under $100. That is trivial
compared to the rest of the costs. And a GPS would give a stratum 1, not 3.
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.
Again the problem seems to lie in the device manufacturer. Not sure what you
mean by a "bad device" since in the previous sentence you referred to a
missing source. If it is missing you cannot get time from it.
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
Do a tcpdump and see if that receipt time minus transmit time is really 20
years, or if there is some problem in the definition of NTP_MAXAGE.
Certainly from below, the transmit and receipt do not seem to be so far out.
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.
Something is seriously wrong if an remote device claims it received an ntp
packet after it sent out the response to that packet. That remote device is
completely broken.
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.
--
William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273
Physics&Astronomy | Advanced Research | Fax: +1(604)822-5324
UBC, Vancouver,BC | Program in Cosmology | unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/
---
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.