problem with Time in Dapper

Daniel Pittman daniel at rimspace.net
Thu Oct 26 06:01:06 UTC 2006


"Howard Coles Jr." <dhcolesj at gmail.com> writes:
> On Tuesday 24 October 2006 11:30 pm, Daniel Pittman wrote:
>> "Howard Coles Jr." <dhcolesj at gmail.com> writes:
>> > On Tuesday 24 October 2006 1:05 am, Daniel Pittman wrote:
>> >> "Howard Coles Jr." <dhcolesj at gmail.com> writes:
>
>> >> > Well, I'm kinda stumped.  I would have thought that the ntp daemon
>> >     remote           refid      st t when poll reach   delay   offset 
>> > jitter
>> > =========================================================================
>> >===== *time.nist.gov   .ACTS.   1 u   24   64  377  121.646  -1800.5  
>> > 390.095 +fiordland.ubunt 192.36.133.17    2 u   20   64  377  113.241 
>> > -1950.7 512.593 +Time1.Stupi.SE  192.36.143.152   2 u   28   64  177 
>> > 146.240  -1690.7 352.934
>>
>> Which shows that your NTP server has achieved synchronisation.

[...]

>> Do you get messages about time source or clock errors in the kernel log?
>
> Not that I can find or have noticed.

[...]

> There must have been an update to the ntpd package, because since I
> updated the ntpd script file and last restarted the daemon, it looks
> like time is staying in sync.

OK, good.  It could be that all it took was that one-shot reset, or it
could be that whatever was causing problems with timekeeping is not an
issue right now.

> I forget what it had, basically just some load lines calling the
> "stop" then "start" sectons with "sleep 2" in between.  The
> interesting thing is that this daemon runs as "ntp" could that have
> something to do with it?

No, running as a non-privileged user is a security feature with no real
bearing on the stability of the NTP software.[1]


The one last thing that could be responsible is your time keeping
hardware.  If you are running a multi-CPU AMD64 system, especially with
an NVIDIA chipset on the motherboard, you could be running into one of
the semi-regular bugs that seem to bedevel that hardware.

Routine advice on the linux-kernel mailing list includes:

  use idle=poll  (ouch!)
  turn off ACPI
  force use of the PIT/PM timer/HPET
  buy a better motherboard

I can't go into much more detail on that specific issue as I am not hurt
by it[2] so I never learned the details of resolving it.


Anyway, if your time continues to drift or you find that NTP is not able
to keep up you might consider investigating that and possibly taking
your issue to the kernel mailing list for help from some real experts on
that front.

Regards,
        Daniel

Footnotes: 
[1]  Unless you did this yourself, in which case you would need check
     that you had granted access to all the resources ntpd needed. :)

[2]  Thankfully.  I have a single core AMD64/NVIDIA system and am now
     not a happy camper, but seem to be OK. :/

-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707        email: contact at digital-infrastructure.com.au
                 http://digital-infrastructure.com.au/





More information about the kubuntu-users mailing list