On 2011-11-24, David Lord <sn...@lordynet.org> wrote: > mas...@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. > > In my case with rtt of 10s the difference between the paths > could result in the hw clock being wrongly set. > > You seem to have a different problem. > >> 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? > > That is what the drift file is for after you have an initial > calibration. You should not need to continuously recalibrate.
Which drift file? Not ntpd's. That is the drift of the system clock, not the rtc. > > > David > > >> Marcin Adamski _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
