Re: [chrony-dev] Issue with version 1.25 and GPRS/GSM connections

[Harald Krammer <Harald.Krammer@xxxxxx>]

On Thu, 11 Aug 2011 17:26:46 +0200, Miroslav Lichvar wrote:
> On Wed, Aug 10, 2011 at 12:31:16PM +0200, Harald Krammer wrote:
>> Hello,
>> I am using Chrony 1.25 and got a strange problem in the field. 
>> So it can happen that the time synchronisations stops after few 
>> hours. A restart of Chrony helps to get the synchronisations working 
>> again, but the reason for that behaviour isn't clear to me. I can not 
>> reproduce it, but I'm assuming this issue exists only on  
>> GPRS/GSM connections (->high jitter).
>> 
>> Wireshark-Capture in case of the problem:
>> http://hkr.at/ntp.pcap
> 
> The dump shows that the network jitter is in tenths of second and the
> total roundtrip time can be over second. The reference ID changes
> after the third iburst sample, but there are 8 iburst requests total,
> which means at least samples number 4-7 were ignored. (it would be
> useful to see the measurements and tracking log to confirm that)
> 

I made logs of measurements, tracking and statistic of the device. 
http://hkr.at/log.tar.bz2

A new record after a reboot.
http://hkr.at/log2.tar.bz2 
I think that could be interesting (High skew).

My error event is not there. Unfortunately I have not really access 
to the device and that makes recording a bit difficult for me.


> I think I'm able to reproduce the problem in clknetsim. What happens
> is that skew after the third sample is so high that the NTP test4
> (peer dispersion < 16 seconds) fails even for the minimum delay on
> your network and the source is stuck with the three samples. In the
> simulations I see skews over 100 (not ppm!), so the roundtrip time
> would have to be at most ~15 ms to pass the dispersion test.
> 
> Limiting the skew to some reasonable maximum value should fix this
> problem. A workaround is to not use the iburst flag.
> 

I'll remove the option iburst.

> But you said it can happen after few hours, that would probably be a
> different problem. Is it possible that you only noticed it after few
> hours?
> 

I don't think so. I monitor the time with the command 
"chronyc tracking" in my application. So it happens that the time will
not be synchronized any more after hours or days. It seems for me 
chrony remains in this unknown case. A reboot of chrony helps.
But I can not exclude an error in my application.

The problem is is not reproducible for me, so I will create a network 
simulation with a similar behaviour and hope to get more information's. 

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.