| Re: [chrony-dev] Issue with version 1.25 and GPRS/GSM connections |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Mon, 22 Aug 2011 15:28:36 +0200, Miroslav Lichvar <mlichvar@xxxxxxxxxx>
wrote:
> On Mon, Aug 22, 2011 at 12:25:42PM +0200, Harald Krammer wrote:
>> Result 3:
>> #########
>> Version: Chrony 1.26-git (without test6, with iburst)
>>
>> It looks interesting. The offset is 6651.414062500s.
>> Normally my application monitors the offet with the
>> tracking command and if the offset gets to high,
>> chrony will be restarted.
>
>> System time : 6651.414062500 seconds fast of NTP time
>> Frequency : 73.729 ppm fast
>> Residual freq : -0.001 ppm
>> Skew : 0.097 ppm
>
> This looks like chrony wasn't configured to step the clock
> (initstepslew or makestep). The value should be going down by
> 0.083 second per second (~22 hours to reach zero).
>
initstepslew was used, but the external time server did start
later than chrony.
I was confused of the values of the command 'sources'.
e.g. estimated error with 509us
typical values of this time source are 2000...6000us.
>> Result 4:
>> #########
>> My "Chrony hang problem" looks to me, that the time server gets
>> into state non-synchronizes.
>> In 'command sources' a non-synchronizes server entry looks like
>> an entry with '?', but all other fields are shown with valid
>> entries. Detection of 'timer source unsynchronized' may help.
>> What do you think?
>
> Is this the problem that was supposed to be fixed in current git or
> something else? Do you have the logs from this test?
I am desperately searching the error. In the field there was again
a report that the time server isn't working properly.
For diagnostic purposes I made the output of the command 'tracking'
and 'sources' available. Here you got the information that the source
is in state '?' unreachable and nothing more.
Other devices in my environment (devices with very simple
NTP implementation) did not report any troubles.
-> suspicion happens > NTP in our device buggy
I've now discovered, if such a problem occurs that the time source
is in error state (e.g. Error state on Meinberg NTP clock
-> Problem with antenna ). The users have noticed this problem
only with our system, because I am using Chrony.
Chrony responded correctly, but my interface of chrony did
not shown the cause of the problem. and so a false suspicions
did happen. During troubleshooting I got an additional problem
with high Jitter and iburst. That issue seems fixed for me.
My conclusion is, I need a better diagnostics.
How? I am unsure at this time. I have to look into.
Nice greetings,
Harald
---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.