Re: Reach error codes

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?
>
> Danny

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.
http://www.cs.wisc.edu/~plonka/netgear-sntp/
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.

_______________________________________________
questions mailing list
questions@xxxxxxxxxxxxxxxxx
https://lists.ntp.isc.org/mailman/listinfo/questions

.

Relevant Pages

  • Time Drift Compensation on Linux Clusters
    ... While working on a Linux cluster with kernel version 2.4.27 we've ... for this problem which is based on the Pentium's TSC clock. ... Following is a detailed description of the problem and the fix, ... The number of interrupt per second is defined by ...
    (Linux-Kernel)
  • Re: ntp discipline of local time?
    ... The kernel discipline is almost identical to the daemon discipline with the exception that the fancy code to combine the PLL and FLL near the Allan intercept is absent. ... like the clock state machine and poll-adjust algorithm continue in the daemon. ... The phase error is probably being filtered using an IIR filter, and that is what you are seeing, and also the mechanism ntpd uses to stop wandering off if it stops receiving updates (the frequency measurement error can produce unbounded phase errors, but the phase error correction is bounded). ...
    (comp.protocols.time.ntp)
  • CLOCK_TICK_RATE for slowing down the system clock?
    ... the Linux kernel. ... The idea is to slow down 10 times the clock maintained by the Linux ... running 10 times slower. ...
    (Linux-Kernel)
  • Re: ntp and hwclock
    ... I have set up clock in my Ericsson mobile phone more than 3 years ... Maybe the new RTC class lets one change ... |kernel will write the time back to the CMOS clock every 11 minutes. ...
    (Debian-User)
  • Re: clock_gettime CLOCK_MONOTONIC replacing
    ... clock to work' and this is going to solve the problem. ... internet isn't exactly a new phenomenon. ... "Simple fix, when the car is low on gas, fill the tank up. ...
    (comp.os.linux.development.apps)