Re: [chrony-users] NTP v4 header

[ Thread Index | Date Index | More Archives ]

On Thu, 5 May 2011 13:07:32 +0200, Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> On Wed, May 04, 2011 at 07:25:20PM +0200, Harald Krammer wrote:
>> I have full understanding of a rejection of my patches, because
>> they are really strange. Or exists cleaner solutions for my hacks?
> A workaround for the stratum problem could be running two chronyd
> instances, one as a client and one as a server with "local stratum".
> They'd have to be configured to use different port, cmdport and
> pidfile. The server should be started before the client as it will
> reset clock frequency to 0 or the drift value. (starting without
> driftfile shouldn't reset the frequency though, I'll see if it can be
> fixed easily)
> But it you need to patch the sources for the other hacks, adding
> another patch will be probably easier than running two daemons.

In my work I'm going to use the patches. Two demons were really an 
interesting idea, but the memory consumption is also an important
topic for me. One target is an ARM720T (EP7312) with 16 MByte RAM.

>> It is the second condition.
>> (UTI_CompareTimevals(&remote_reference_tv, &remote_transmit_tv) is 1
>> ref_time=00000000.00000000 [Thu 02/07/36 06:28:16.000000]
>> 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.
> The problem is that ref_time is 0, which after converting to Unix time
> is 25 years in future and the check fails. If the timestamps were
> compared in NTP timestamps, the NTP_MAXAGE check would fail instead.
> RFC 5905 doesn't have the NTP_MAXAGE check. Interestingly, in ntpd it
> seems there is no reftime checking at all, I'll have to ask on the ntp
> list which is correct.

I had until now only one serie of devices (Hirschmann Switches) 
with this behavior. 

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.

Mail converted by MHonArc 2.6.19+