I've just installed the latest release of Mandrake Linux on a
new machine (Fujitsu-Siemens, with an AMD 5200 dual core
processor). Regretfully, the real time clock runs fast---what
looks to be twice as fast as it should. This also affects
films, etc., which run too fast as well. (Just speculating, but
maybe the timer interrupt is being handled by both cores,
incrementing the real time clock twice for each tick.) I've
tried playing around with adjtimex, but it won't allow such
radical modification.

A priori, there's a configuration parameter somewhere that I'm
unaware of; if anyone could point me in the right direction, or
to the relevant documentation, I'd be much obliged. (FWIW: I've
removed Windows entirely from the machine, so dual boot
considerations, and synchronizing with the Windows clock, aren't
issues.)

Also, ntpd doesn't seem to resynchronize automatically. I can
resynchronize manually, from the Mandrake GUI interface, but I
don't know what command it invokes, so I can't set up a cron job
to do this either. (Obviously, being able to correctly
synchronize won't really help in my case, but I'd like to
resynchronize automatically periodically once things are
working.)

--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:

> Also, ntpd doesn't seem to resynchronize automatically.

Thought so. If you haven't got your timezones set correctly, ntp
will try to adjust the time by a a factor of at least a an hour,
rather than
the usual fraction of a second, leading to massive drift.

On Sep 4, 11:31 am, Gremnebulin <peterdjo...@yahoo.com> wrote:
> On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:

> > Also, ntpd doesn't seem to resynchronize automatically.

> Thought so. If you haven't got your timezones set correctly, ntp
> will try to adjust the time by a a factor of at least a an hour,
> rather than
> the usual fraction of a second, leading to massive drift.

In which case, the time would synchronize for some other time
zone. Which it doesn't. The clock just runs about twice the
speed it should, and never resynchronizes with anything.

--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Gremnebulin <peterdjones@yahoo.com> writes:

>On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:

>> Also, ntpd doesn't seem to resynchronize automatically.

>Thought so. If you haven't got your timezones set correctly, ntp
>will try to adjust the time by a a factor of at least a an hour,
>rather than
>the usual fraction of a second, leading to massive drift.

Under Linux the system time is ALWAYS UTC. There is no timezone information
there or needed.

On Sep 4, 4:08 pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
> Gremnebulin <peterdjo...@yahoo.com> writes:
> >On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:
> >> Also, ntpd doesn't seem to resynchronize automatically.
> >Thought so. If you haven't got your timezones set correctly, ntp
> >will try to adjust the time by a a factor of at least a an hour,
> >rather than
> >the usual fraction of a second, leading to massive drift.

> Under Linux the system time is ALWAYS UTC. There is no
> timezone information there or needed.

Quite. To be very clear, I am talking about the system time.
The hardware realtime clock seems more or less correct; if I
synchronize the time, then shut the system down, the clock is
more or less correct when I reboot. On the other hand, if I
leave the system running for several days, the date is off as
well.

--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Tue, 04 Sep 2007, in the Usenet newsgroup comp.os.linux.setup, in article
<1188897241.747805.172730@r29g2000hsg.googlegroups .com>, James Kanze wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>I've just installed the latest release of Mandrake Linux on a
>new machine (Fujitsu-Siemens, with an AMD 5200 dual core
>processor). Regretfully, the real time clock runs fast---what
>looks to be twice as fast as it should.

Get your watch or a wall clock with a second hand. Run this command
as close to ten seconds apart ACCORDING TO THE WATCH as you can

[compton ~]$ grep ' 0:' /proc/interrupts
0: 75772989 timer
[compton ~]$

Ten seconds later

[compton ~]$ grep ' 0:' /proc/interrupts
0: 75774014 timer
[compton ~]$

75774014 - 75772989 == 1025

or about 1000 counts in ten seconds (you may see 10000 counts in ten
seconds, depending on how your kernel was compiled). Is this what you
see, or is it 2000 (or 20000) counts in ten seconds? If the later,
you've been caught with a well known problem - Configure your boot
loader to pass the parameter "noapic" as a kernel boot parameter.

>A priori, there's a configuration parameter somewhere that I'm
>unaware of; if anyone could point me in the right direction, or
>to the relevant documentation, I'd be much obliged.

-rw-rw-r-- 1 gferg ldp 80763 Mar 21 2003 BootPrompt-HOWTO

Section 3.4.23. The `noapic' Argument

Old guy

Moe Trin wrote:
> On Tue, 04 Sep 2007, in the Usenet newsgroup comp.os.linux.setup, in article
> <1188897241.747805.172730@r29g2000hsg.googlegroups .com>, James Kanze wrote:

> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen.

Why? I've not noticed any problems with propagation from
Google. Just that when sending an HTTP Post, the firewall where
I work seems to add some funny headers, or at least something
which ends up in the header of my postings. (This doesn't occur
when, like now, I post from home, without a firewall.) But as
far as I can tell, the headers are legal, and the only
newsreader which seems to have problems with them is Outlook.

> Find a real news server.

Most of the time, I post from work, behind a firewall which
won't pass NNTP. (That's the only reason I started using Google
to begin with.)

> >I've just installed the latest release of Mandrake Linux on a
> >new machine (Fujitsu-Siemens, with an AMD 5200 dual core
> >processor). Regretfully, the real time clock runs fast---what
> >looks to be twice as fast as it should.

> Get your watch or a wall clock with a second hand. Run this command
> as close to ten seconds apart ACCORDING TO THE WATCH as you can

> [compton ~]$ grep ' 0:' /proc/interrupts
> 0: 75772989 timer
> [compton ~]$

> Ten seconds later

> [compton ~]$ grep ' 0:' /proc/interrupts
> 0: 75774014 timer
> [compton ~]$

> 75774014 - 75772989 == 1025

> or about 1000 counts in ten seconds (you may see 10000 counts in ten
> seconds, depending on how your kernel was compiled). Is this what you
> see, or is it 2000 (or 20000) counts in ten seconds?

I've got two numeric fields between the 0: and the device name.
The first gave a difference of about 5000. Now that things are
fixed, I get:

Gabi (3): grep ' 0:' /proc/interrupts
0: 87715 4834 XT-PIC timer
Gabi (3): grep ' 0:' /proc/interrupts
0: 90159 4884 XT-PIC timer

With a difference of 2444 for the first, and 50 for the second.

> If the later,
> you've been caught with a well known problem - Configure your boot
> loader to pass the parameter "noapic" as a kernel boot parameter.

I'd played around with the boot parameters a little, more or
less randomly, but without success. I forget what I initially
wanted to change there (in fact, I'd forgotten that I'd changed
anything there), but apparently, that's where I'd screwed up.
Just adding noapic meant that the machine wouldn't even boot,
but luckily, I'd saved the original configuration: "noapic
nolapic acpi=off" seems to do the trick.

> >A priori, there's a configuration parameter somewhere that I'm
> >unaware of; if anyone could point me in the right direction, or
> >to the relevant documentation, I'd be much obliged.

> -rw-rw-r-- 1 gferg ldp 80763 Mar 21 2003 BootPrompt-HOWTO

> Section 3.4.23. The `noapic' Argument

Which doesn't really say much, and doesn't seem to describe my
version exactly. Still, just knowing that it has something to
do with something called "apic" should allow me to find out more
through Google.

In the meantime: I've now been running for about five minutes,
and the clock is exactly synchronous with my watch (which in
turn synchronizes automatically by radio with an atomic clock in
in Frankfurt). And a quick trial of a couple of seconds of a
film seems to work too.

So many, many thanks for the tip concerning apic. I don't think
I'd have ever hit on it myself.

--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze <james.kanze@gmail.com> writes:

>On Sep 4, 4:08 pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
>> Gremnebulin <peterdjo...@yahoo.com> writes:
>> >On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:
>> >> Also, ntpd doesn't seem to resynchronize automatically.
>> >Thought so. If you haven't got your timezones set correctly, ntp
>> >will try to adjust the time by a a factor of at least a an hour,
>> >rather than
>> >the usual fraction of a second, leading to massive drift.

>> Under Linux the system time is ALWAYS UTC. There is no
>> timezone information there or needed.

>Quite. To be very clear, I am talking about the system time.
>The hardware realtime clock seems more or less correct; if I
>synchronize the time, then shut the system down, the clock is
>more or less correct when I reboot. On the other hand, if I
>leave the system running for several days, the date is off as
>well.

This problem was much discussed about a year ago. Some motherboards would
run at double speed. I cannot remember the resolution however, but
upgrading the kernel might help.

The Natural Philosopher <a@b.c> writes:

>James Kanze wrote:
>> On Sep 4, 4:08 pm, Unruh <unruh-s...@physics.ubc.ca> wrote:
>>> Gremnebulin <peterdjo...@yahoo.com> writes:
>>>> On 4 Sep, 10:14, James Kanze <james.ka...@gmail.com> wrote:
>>>>> Also, ntpd doesn't seem to resynchronize automatically.
>>>> Thought so. If you haven't got your timezones set correctly, ntp
>>>> will try to adjust the time by a a factor of at least a an hour,
>>>> rather than
>>>> the usual fraction of a second, leading to massive drift.
>>
>>> Under Linux the system time is ALWAYS UTC. There is no
>>> timezone information there or needed.
>>
>> Quite. To be very clear, I am talking about the system time.
>> The hardware realtime clock seems more or less correct; if I
>> synchronize the time, then shut the system down, the clock is
>> more or less correct when I reboot. On the other hand, if I
>> leave the system running for several days, the date is off as
>> well.
>>
>get an ntp client. Simple_ntp springs to mind.

He did and said he did. ntp CANNOT correct a clock running at double time.

Two of my systems showed a similar problem but it was masked by NTP
polling.

Only after a router died did I notice the problem, I was picking up
five hours for every hour. In the BIOS I saw that the RTC was way
fast. The solution I found (on the net) was to power down, remove the
RTC clock battery and replace it, then power up. The RTC worked okay
after that.

NTP is driven by man:ntpd and uses the files in /etc/ntp. It will run
continuously unless the -q argument is given.

Dave