[ntp:questions] NTP on embedded Linux with GPRS connection

unruh unruh at invalid.ca
Thu Nov 24 13:38:21 UTC 2011

On 2011-11-24, mass85 at tlen.pl <mass85 at tlen.pl> wrote:
>> I've used gprs with usb dongle and on either Ubuntu or NetBSD.
>> The main problem was the gprs being very slow to respond until
>> it had adjusted to any significant level of traffic. I'm not
>> sure if Ubuntu uses ntpdate at startup or if it's redundant
>> with NetBSD but either way it wasn't possible to get a reliable
>> timesetting at startup until I used 'burst'. It might be that
>> iburst would have been sufficient by then but I had setup a pool
>> server so using that option was ok for me and I had also set a
>> long default poll interval.
> Ntpdate works pretty fast, I can get time set in 1 or 2 seconds. The
> problem is that connection setup can last long or even fail.
>> At startup rtt was sometimes around
>> 10 seconds and when connection was fully established the lowest
>> rtt was above 150ms. I would not rely on any timings being
>> useful for adjustment of hwclock.
> Why not? My NTP can synchronise in 15minutes and then keep control
> over system clock. I assume that when it synchronises time and adjusts
> system clock, it knows what it's doing and it is doing it quite
> accurately. RTC can be at least 1s off every 24h, so it is quite much.
> Is there any other ready to use way than "hwclock --adjust" to
> calibrate RTC? Could NTP do it?

There is an inherent difficulty in hwclock. When you determine its drift
rate, the computer is on and warm. When it is acually useful, to tell
the difference between the rtc time and true time, the drift rate is
different because the computer is off (cold). This has a few PPM (up to
10) effect on the drift rate. 

ntp has nothing to do with rtc. chrony, on the other hand, does
calculate the drift rate of the rtc and uses that in resetting the clock
on next turnon if you tell it to. (chrony works for linux and bsd, but
not windows.)

hwclock, at least one version of it . There are ( were?) two development
streams with the same name, but different behaviour. One  does try to do an rtc recalibration
as well. Again it has nothing to do with ntp. It sets the clock before
ntpd gets it. 

> Marcin Adamski

More information about the questions mailing list