Subject: clock losing time

From: Bob Slawson <[email-masked]>

From: [email-masked] (Tero Manninen)
   Date: Mon, 7 Feb 1994 23:19:33 +0200 (EET)

   Ok, this must be something that others have noted too.
   The NetBSD clock really seems to loose some time. The
   drifting is around 10 minutes per day, at least.
		         ???????
			seconds perhaps

I've never seen anything this large although I have noticed a loss of
time after being up for a week or so.

BobS

---

From: [email-masked] (Tero Manninen)

> time after being up for a week or so.

No, this is minutes. I'll put the clock into right time now
and check it after 12 to 24 hours. I'll let you know the accurate
results then.

++Tero

---

From: Zik Saleeba <[email-masked]>

> No, this is minutes. I'll put the clock into right time now

I can verify this. My A3000 seems to lose quite a few minutes each day
- sometimes it's nearly an hour behind by the time the system crashes
after a few days :-)

(And there I was thinking that it was my A2232 driver causing the problem :-)

+-----------------------------------+------------------------------------+
|      [email-masked]      | "People who like quotations        |
|     [email-masked]    |  love meaningless generalisations" |
|            Zik Saleeba            |               - Graham Greene      |
+-----------------------------------+------------------------------------+

---

From: [email-masked] (Terje Normann Marthinussen)

> (And there I was thinking that it was my A2232 driver causing the problem :-)

I've experienced something similar on my A2000 also when running AmigaDOS.
I haven't really tried to check this out, but I'm pretty sure that the first
time I noticed was after I started to run the WB in NTSC mode...
(I am really a little confused about this thing, but... first time I noticed
was after I switched to running WB in NTSC interlaced and was running ncomm
on a PAL screen, well, it's the only thing that I can think of that got
different in my setup, either that has nothing to do with it, or I simply 
haven't noticed before...)

The fun thing is that the battery clock seems to stay right.
If you try a setclock load the time will be correct again.

I'll try (sometime after my exam tomorrow :) to check if I can find 
something that might do a difference.

Terje Marthinussen
[email-masked]

---

From: [email-masked]

> drifting is around 10 minutes per day, at least.

Measure it as good as you can (over a long enough period), than divide
the measured by the real amount of time passed, and adjust the constant
that is loaded in the CIA timer appropriatly.

-Markus
-- 
CHUUG/EUnet Switzerland				Markus Wild
Zweierstrasse 35	Tel: +41 1 291 45 80	[email-masked]
CH-8004 Zuerich		Fax: +41 1 291 46 42	S=mw;P=EUnet;A=EUnet;C=CH

---

From: "hamish (h.i.) macdonald" <[email-masked]>

>>>>> On Tue Feb  8 15:14:00 1994,
>>>>> Tero wrote:

tero> That's not strange, because battery backed clock runs its own
tero> life, totally separated of the CIA timers. Now in NetBSD we
tero> seem to use one interval timer for a 100Hz counter. Here is
tero> the catch:
tero> /usr/src/sys/arch/amiga/amiga/clock.c
tero> /* the clocks run at NTSC: 715.909kHz or PAL: 709.379kHz.
tero> We're using a 100 Hz clock. */

tero> #define CLK_INTERVAL (715909 / 100)

tero> and later..

tero> interval = CLK_INTERVAL - 1;

tero> ciab.talo = interval & 0xff;
tero> ciab.tahi = interval >> 8;

tero> BTW, could this be a configurable thing (PAL vs. NTSC) like many
tero> other things in system configuration file?

AmigaDOS knows the E clock frequency (the frequency of ticks that the
CIAs count).  This problem is solved in linux by having the linux
bootstrap loader pass this frequency indication to the kernel via the
"boot info" structure which contains all the other configuration
information.  The kernel then sets the number of CIA ticks in a 100Hz
tick appropriately.

---

From: [email-masked] (Markus Illenseer) "Re: clock losing time" (Feb 8, 5:35pm)

> something that might do a difference.

 I wonder what happens here, because i never encountered such
 problems on my machine (A3000/25), and I alwys run NTSC (though PAL
 is enabled on the motherboard).

-- 
Markus Illenseer

---

From: [email-masked] (Tero Manninen)

> on a PAL screen,

I have been using NTSC screens for Workbench, but the machine is
jumpered to PAL system. I have not experienced any time lossage
in AmigaOS, but only with ixemul.library using programs (there is
a same kind of bug in the ixemul like here (at least in older
ixemul versions) ;-)

> If you try a setclock load the time will be correct again.

That's not strange, because battery backed clock runs its own
life, totally separated of the CIA timers. Now in NetBSD we
seem to use one interval timer for a 100Hz counter. Here is
the catch:
/usr/src/sys/arch/amiga/amiga/clock.c
/* the clocks run at NTSC: 715.909kHz or PAL: 709.379kHz.
   We're using a 100 Hz clock. */

#define CLK_INTERVAL (715909 / 100)

and later..

  interval = CLK_INTERVAL - 1;

  ciab.talo = interval & 0xff;
  ciab.tahi = interval >> 8;

When calculating the difference of 709.3 and 715.9  (note
that the interval is divided by 100, thus losing accurary)
I get only about 13 minutes too slow clock per 24 hours.
As I promised yesterday, I have now calculated how much my
clock loses time. Well.. it is: 17 minutes during a period of
21 hours!! So, the 17-13 minutes difference is still a mystery
after CLK_INTERVAL adjustment.. BTW, could this be a configurable
thing (PAL vs. NTSC) like many other things in system configuration
file?

++Tero

---

From: [email-masked] (Terje Normann Marthinussen)

> a same kind of bug in the ixemul like here (at least in older

You are right, tried it out today. No differnce whatever I did. Lost a lot 
of time anyway.

> thing (PAL vs. NTSC) like many other things in system configuration

He, I lost approx 5 minutes during a 30 minute period!!!!!
Or.. after 30 minutes the difference between the battery clock and the 
CIA clock was approx 5 minutes...
(Using AmigaOS...)

Terje Marthinussen
[email-masked]