[email protected] 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.
David
Marcin Adamski
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
