[nSLUG] Re: Clock drifts badly even when machine is up
mspencer at tallships.ca
Sun Jul 3 02:33:30 ADT 2016
mds> I played a DVD movie around midnight. Is there any known problem
mds> with mplayer or video interfering with the kernel's clock
Which may have sounded like wild speculation.
Apparently not. I've found a partial answer.
I wrote a little script that compared, at 60 sec intervals:
rsh [my-laptop] date %+T
which (after resetting the desktop clock with ntpdate) differed by 4
seconds (+/- 1 second due to the impresicion of date(1)'s report.)
The laptop's clock has been very stable in the past.
The script ran all day an didn't report any change. In the evening,
we watched another DVD on the desktop. During that time, the desktop
fell behind the laptop by 13 minutes -- varying from 6 to 10 sec/min.
After the DVD ended and mplayer terminated, the difference between the
2 hosts has remained 787 +/- 1 sec., unchanged, for nearly an hour.
So it's pretty clearly mplayer or the DVD drive hardware that's the
problem. Less likely a kernel bug that mplayer innocently triggers.
So I'm still looking for the technical answer. I'll try the mplayer
mailing list but not with pleasure. Last time I did, I was upbraided
rather um.. incivilly for not having the very latest version.
Dave Flogeras <dflogeras2 at gmail.com> wrote:
df> ...it seems that ntpdate is known to be problematic. From the
df> 4.2.8_p8 manpage:
df> "Disclaimer: This program has known bugs and deficiencies and
df> nobody has volunteered to fix them in a long time. The good news
df> is the functionality originally intended for this program is
df> available in the ntpd and sntp programs....."
df> ...it is also my understanding that the RTC is consulted at boot,
df> and in at least my case (Gentoo) written during shutdown.
df> Otherwise, it is left alone. Other distros may do the writing
df> part differently, or not at all.
I didn't know about that. I'll see if I can find out what Slackware
df> Last, ntpd does have a default "panic time" which is typically
df> 1000s (just over the 13m mark you have). It will not adjust the
df> clock more than 1000s (this can also be overridden with -g).
The rc.ntpd script from Slackware runs ntpd with -g.
"George N. White III" <gnwiii at gmail.com> wrote:
gnw> ntpd can get confused when used on intermittent connections. For
gnw> dailup or laptops that move around, use chrony
gnw> <https://chrony.tuxfamily.org/>. It should be available as a
gnw> package for many distros. It is not hard to install from source.
I had and ran chrony a couple of upgrades (sevreal years) ago. It got
lost somewhere. I should get a newer release
gnw> The chrony download page lists distros that have packages.
Oliver Doepner <odoepner at gmail.com> wrote:
od> Are you sure your new button battery is actually new?
Well, not absolutely, but I got it from The Source in a Packaging
Rage-quality package. :-)
od> Does the clock adjust every time you go online?
It was hard to tell, probably because it wasn't drifting
significantly. No excuse for not to run ntpd or chrony, though.
od> I read here that ntp server might have to be *restarted* not just
od> separately started or stopped:
The setup I was using (before I confirmed the mplayer connection) was
a pair of scripts that pppd ran after the ppp net connection was up
and before it went down. Those scripts called /etc/rc.d/rc.ntpd with
args "start" and "stop" which launch ntpd and kill it, respectively.
I verified that ntpd was no longer a process after the rc.ntpd stop
It would be different for a laptop and wifi because it doesn't have a
"wifid" that starts and stops the connection. I suppose there's a
possible hack if network manager or wicd have hooks like pppd does.
Probably easier to run chrony as George suggests.
Thanks for the pointers,
Michael Spencer Nova Scotia, Canada .~.
mspencer at tallships.ca /( )\
More information about the nSLUG