[ntp:questions] Re: Reach error codes
cave.dnb at tiscali.fr
Wed Jan 25 18:51:39 UTC 2006
On Wednesday 25 January 2006 18:42, Danny Mayer wrote:
> Nigel Henry wrote:
> > Hi Richard. Thanks for the fine explanation as to how, "Reach" works. I
> > still have some problems with keeping the time synched on my 2 Linux
> > machines. I know that I am on dialup, and perhaps is not the best way to
> > go using NTP. The worst problem appears to be when I leave both machines
> > running, and connected to the Internet when I have to take a sleep. When
> > the dialup connection times out, the machine which retrieves time from
> > the Internet has problems. The system clock actually stops. The other
> > machine, which retrieves time across the LAN from this machine, has no
> > problems, and retains the correct time (as near as dammit). irrespective
> > to how much the time has slipped on the machine that retrieves time from
> > the Internet. There is no problem with the HWC on the machine connected
> > to the Internet for time retrieval, because, if I shut it down, and just
> > leave the other machine online, when I boot up this machine the following
> > day the time is ok, and is more or less in sync with the machine that has
> > been running all night. The problem strangely appears to be with the
> > mouse.
> > As an example. Two machines. The one retrieving time from the machine
> > retrieving time from NTP servers on the Internet is as good as correct.
> > The other machine which is using the 3 time servers as below, has a clock
> > which has stopped (several hours before). I move the mouse pointer, and
> > the clock starts. Weird ! Now I reset the clock on this machine, using
> > the reset time and date facility. I leave this open. After a few minutes
> > the clock stops again, but moving the mouse pointer the clock then
> > restarts. Very weird. The mice I am using on both machines are, A4 Tech
> > (Scrolltrack 4D) . Strangely again. I. From time to time used to
> > experience mouse pointer freeze-ups when using Kmail, but since using NTP
> > these have gone away. I know this is all a bit weird, but has anybody
> > else using these mice had problems like this?
> It sounds to me like you have a problem with the mouse, the mouse driver
> or the mouse hardware inside the machine. I don't think this has
> anything to do with NTP. Your description of your problem is there is
> some sort of interaction between the mouse and the clock. Nothing should
> be stopping the clock. Are you talking about the hardware clock or a GUI
> displaying the clock?
Hi Danny. This is the GUI for the clock. The HWC is fine. I can shutdown the
machine, then reboot the following day, and there are no time discrepancies.
(dammit, I changed a few vowels, but that word still looks wrong). I've since
reverted to the 2.6.5-1.358 kernel, which is the original kernel for FC2, and
the timeslips have disappeared. The kernel I was using was.
2.6.10-0.4.rdt.rhfc2.ccrma. For using music apps, this kernel uses the
packages rtirq & rtload. rtload had been causing problems as it was loaded
last, and had been causing the NTPd to die. Moving the load point of rtload
to before ntpd loaded fixed that problem. I'm still concerned that the
planetccrma kernel with realtime was responsible for these time slip
problems, although on my other machine that I use music apps on, and still is
using the planetccrma kernel with realtime, there are no time slips, even
when the machine retrieving time from the Internet has lost it's dialup
connection. I'm not too bothered about using the 2.6.5 kernel on the machine
retrieving time from the Internet, as the only sound stuff I use is Internet
radio. I know this isn't strictly NTP, but any ideas why using realtime would
cause these time slips? (same mouse on both machines).
BTW. Having read the following at.
I ran Ethereal (just feeling a bit paranoid) but thankfully my NTP requests
are many minutes apart.
Thanks for NTP. Apart from the odd glitch, it's just fine. Nigel.
More information about the questions